From owner-ipng@sunroof.eng.sun.com Fri Oct 1 12:07:28 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) id d91J3aq05390 for ipng-dist; Fri, 1 Oct 1999 12:03:36 -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.10.0.Beta2+Sun/8.10.0.Beta2) with ESMTP id d91J3Ri05383 for ; Fri, 1 Oct 1999 12:03:28 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA02794 for ; Fri, 1 Oct 1999 12:03:26 -0700 (PDT) Received: from iol.unh.edu (mars.iol.unh.edu [132.177.121.222]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA03293 for ; Fri, 1 Oct 1999 13:03:25 -0600 (MDT) Received: from localhost (rglr@localhost) by iol.unh.edu (8.9.3/8.9.3) with ESMTP id PAA17069; Fri, 1 Oct 1999 15:04:16 -0400 (EDT) Date: Fri, 1 Oct 1999 15:04:16 -0400 From: Ray LaRocca To: ipng@sunroof.eng.sun.com cc: ipmembers@iol.unh.edu Subject: UNH IPv6 Group Test Period Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ****************** SECOND ANNOUNCEMENT ******************* The UNH - Interoperability Lab IP/Routing Consortium will be hosting an IPv6 test period on November 1-5, 1999. Information on location, hotels and travel info can be found at our Web site: http://www.iol.unh.edu On-line registration is also available on our Web site, for additional information you may contact, Carol Cooper (chc@iol.unh.edu), 603-862-0201 or me at the information below. Please Note: Currently there are only 2 companies registered. This event will be cancelled on Friday, October 15th if there is not enough interest expressed in attending. Regards, -Ray /* * Ray LaRocca Lead Engineer, IP/Routing Consortium * Manager, FDDI Consortium * Email: rglr@iol.unh.edu * Tel: (603) 862-2804 InterOperability Lab * Lab Tel: (603) 862-0090 University of New Hampshire * Fax: (603) 862-4181 7 Leavitt Lane, Room 106 * Web: http://www.iol.unh.edu Durham, NH 03824-3525 */ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Oct 2 01:50:06 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) id d928ZdS06206 for ipng-dist; Sat, 2 Oct 1999 01:35:39 -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.10.0.Beta2+Sun/8.10.0.Beta2) with ESMTP id d928ZUi06199 for ; Sat, 2 Oct 1999 01:35:31 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id BAA00305 for ; Sat, 2 Oct 1999 01:35:30 -0700 (PDT) Received: from hotmail.com (law2-f22.hotmail.com [216.32.181.22]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id CAA22355 for ; Sat, 2 Oct 1999 02:35:30 -0600 (MDT) Received: (qmail 54305 invoked by uid 0); 2 Oct 1999 08:35:29 -0000 Message-ID: <19991002083529.54304.qmail@hotmail.com> Received: from 130.102.2.60 by www.hotmail.com with HTTP; Sat, 02 Oct 1999 01:35:29 PDT X-Originating-IP: [130.102.2.60] From: "Susanne Egilstad" To: ipng@sunroof.eng.sun.com Date: Sat, 02 Oct 1999 08:35:29 GMT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk hello, can someone help me with this problem; if you have congestion in the corporate network, but not sure whether it is the LAN or the WAN which is congested, butth enetwork feels slow. the backbone of the network consists of one 8-port 10Base-T managed switch. of the eight switch ports, seven are connected to 10Base-T unmanaged hubs, while the eighth port on the switch connects to an ISDN BRI router. How can we measure congestion on the network in quantifiable terms.?? How can we reduce the amount of congestion on the network. ?? What extra hardware should we add?? I really hope you can help me out with this problem regards, susanne ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.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 Sat Oct 2 20:38:05 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) id d933ZZH06648 for ipng-dist; Sat, 2 Oct 1999 20:35: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.10.0.Beta2+Sun/8.10.0.Beta2) with ESMTP id d933ZQi06641 for ; Sat, 2 Oct 1999 20:35:27 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id UAA11346 for ; Sat, 2 Oct 1999 20:35:25 -0700 (PDT) Received: from hotmail.com (law2-f187.hotmail.com [216.32.181.187]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id UAA19937 for ; Sat, 2 Oct 1999 20:35:26 -0700 (PDT) Received: (qmail 77940 invoked by uid 0); 3 Oct 1999 03:35:25 -0000 Message-ID: <19991003033525.77939.qmail@hotmail.com> Received: from 130.102.2.61 by www.hotmail.com with HTTP; Sat, 02 Oct 1999 20:35:25 PDT X-Originating-IP: [130.102.2.61] From: "Susanne Egilstad" To: ipng@sunroof.eng.sun.com Subject: IPv6 and business effect Date: Sun, 03 Oct 1999 03:35:25 GMT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi there, can someone please help me with some links or information on what effect IPv6 will have on business today. Thank you Regards, Susanne ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.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 Sat Oct 2 21:06:51 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) id d93443n06676 for ipng-dist; Sat, 2 Oct 1999 21:04:03 -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.10.0.Beta2+Sun/8.10.0.Beta2) with ESMTP id d9343ti06669 for ; Sat, 2 Oct 1999 21:03:55 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id VAA18463 for ; Sat, 2 Oct 1999 21:03:55 -0700 (PDT) From: Volsinians@aol.com Received: from imo-d04.mx.aol.com (imo-d04.mx.aol.com [205.188.157.36]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA22569 for ; Sat, 2 Oct 1999 21:03:54 -0700 (PDT) Received: from Volsinians@aol.com by imo-d04.mx.aol.com (mail_out_v22.4.) id iMHZ0hayH0 (3976); Sun, 3 Oct 1999 00:03:44 -0400 (EDT) Message-ID: Date: Sun, 3 Oct 1999 00:03:44 EDT Subject: Re: IPv6 and business effect To: s_egilstad@hotmail.com, ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: AOL 4.0 for Windows 95 sub 26 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In a message dated 10/2/99 11:41:58 PM Eastern Daylight Time, s_egilstad@hotmail.com writes: > can someone please help me with some links or information on what effect > IPv6 will have on business today. > Since IPv6 will probably never be generally deployed, it will probably have about the same effect on business that MAP had. Joachim Martillo -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Oct 2 22:20:18 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) id d935H9106731 for ipng-dist; Sat, 2 Oct 1999 22:17:09 -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.10.0.Beta2+Sun/8.10.0.Beta2) with ESMTP id d935H0i06724 for ; Sat, 2 Oct 1999 22:17:00 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id WAA21297 for ; Sat, 2 Oct 1999 22:16:59 -0700 (PDT) Received: from dfw-ix7.ix.netcom.com (dfw-ix7.ix.netcom.com [206.214.98.7]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA29512 for ; Sat, 2 Oct 1999 22:16:59 -0700 (PDT) Received: (from smap@localhost) by dfw-ix7.ix.netcom.com (8.8.4/8.8.4) id AAA00582; Sun, 3 Oct 1999 00:16:56 -0500 (CDT) Received: from dal-tx8-46.ix.netcom.com(207.94.123.110) by dfw-ix7.ix.netcom.com via smap (V1.3) id rma000495; Sun Oct 3 00:16:16 1999 Message-ID: <37F676A2.9F74B270@ix.netcom.com> Date: Sat, 02 Oct 1999 22:18:28 +0100 From: Jeff Williams Organization: INEG. Inc. (Spokesman INEGroup) X-Mailer: Mozilla 4.08 [en] (Win16; I) MIME-Version: 1.0 To: Volsinians@aol.com CC: s_egilstad@hotmail.com, ipng@sunroof.eng.sun.com Subject: Re: IPv6 and business effect References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Susanne and all, I would tend to agree with this assessment, but I am sure that the IETF and ICANN would not. IPv8 is currently in deployment now, which we feel is a marked improvement over IPv6 in many ways. Susanne, if you would like some additional info here please feel free to contact me offline, or call (See sig file below) Volsinians@aol.com wrote: > In a message dated 10/2/99 11:41:58 PM Eastern Daylight Time, > s_egilstad@hotmail.com writes: > > > can someone please help me with some links or information on what effect > > IPv6 will have on business today. > > > Since IPv6 will probably never be generally deployed, it will > probably have about the same effect on business that MAP > had. > > Joachim Martillo > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- Regards, -- Jeffrey A. Williams Spokesman INEGroup (Over 95k members strong!) CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 972-447-1894 Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 4 12:59:22 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) id d94JteE08216 for ipng-dist; Mon, 4 Oct 1999 12:55:40 -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.81.144] (may be forged)) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) with ESMTP id d94JtTi08209 for ; Mon, 4 Oct 1999 12:55:29 -0700 (PDT) Received: from lillen (lillen.Eng.Sun.COM [129.146.86.161]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id MAA697102; Mon, 4 Oct 1999 12:55:26 -0700 (PDT) Date: Mon, 4 Oct 1999 12:46:55 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: draft-ietf-ipngwg-dns-lookups-04.txt To: Paul A Vixie Cc: Erik Nordmark , Jim Bound , Matt Crawford , ipng@sunroof.eng.sun.com, namedroppers@internic.net Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > On Jun 29th Paul A Vixie wrote: > if we want to specify a metaquery that can be satisfied by either AAAA > or A6 records (or A records for that matter) then by all means let's make > one. MAILA and MAILB are metaqueries. they have no corresponding RRTYPES; > they are examples of QTYPE being a subtype of RRTYPE in the DNS specs. Do we want to define a meta-query for AAAA and A6? What are the issues in doing so? (Trying to get the discussion restarted so we can get closure.) 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 4 13:38:33 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) id d94KZWF08287 for ipng-dist; Mon, 4 Oct 1999 13:35: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.10.0.Beta2+Sun/8.10.0.Beta2) with ESMTP id d94KZKi08280 for ; Mon, 4 Oct 1999 13:35:21 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA11100 for ; Mon, 4 Oct 1999 13:35:19 -0700 (PDT) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA01201 for ; Mon, 4 Oct 1999 14:35:07 -0600 (MDT) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id PAA27052; Mon, 4 Oct 1999 15:35:06 -0500 (CDT) Message-Id: <199910042035.PAA27052@gungnir.fnal.gov> To: ipng@sunroof.eng.sun.com, namedroppers@internic.net From: "Matt Crawford" Subject: Re: draft-ietf-ipngwg-dns-lookups-04.txt In-reply-to: Your message of Mon, 04 Oct 1999 12:46:55 PDT. Date: Mon, 04 Oct 1999 15:35:06 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > if we want to specify a metaquery that can be satisfied by either AAAA > > or A6 records (or A records for that matter) then by all means let's make > > one. MAILA and MAILB are metaqueries. they have no corresponding RRTYPES; > > they are examples of QTYPE being a subtype of RRTYPE in the DNS specs. > > Do we want to define a meta-query for AAAA and A6? > What are the issues in doing so? > > (Trying to get the discussion restarted so we can get closure.) IANA has already given me a type code and in my copious free time a new draft will be created, containing words like the following ... .IP o A new DNS query type "ADDRS" which requests A6, AAAA and A records. [...] .SC 1 IANA Considerations The A6 resource record has been assigned a Type value of 38 and the ADDRS query has been assigned a Qtype value of 248. And something in between to define it. My thinking right now is that QTYPE=ADDRS should get back A, AAAA and A6. Any differing opinions? Matt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 4 13:52:47 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) id d94KnXv08370 for ipng-dist; Mon, 4 Oct 1999 13:49:33 -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.10.0.Beta2+Sun/8.10.0.Beta2) with ESMTP id d94KnOi08363 for ; Mon, 4 Oct 1999 13:49:25 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA08666 for ; Mon, 4 Oct 1999 13:49:24 -0700 (PDT) Received: from orchard.arlington.ma.us (orchard.epilogue.com [128.224.138.4]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA07557 for ; Mon, 4 Oct 1999 14:49:22 -0600 (MDT) Received: from orchard.arlington.ma.us (localhost [[UNIX: localhost]]) by orchard.arlington.ma.us (8.8.8/1.34) with ESMTP id UAA25137; Mon, 4 Oct 1999 20:49:17 GMT Message-Id: <199910042049.UAA25137@orchard.arlington.ma.us> To: "Matt Crawford" cc: ipng@sunroof.eng.sun.com, namedroppers@internic.net Subject: Re: draft-ietf-ipngwg-dns-lookups-04.txt In-Reply-To: Message from "Matt Crawford" of "Mon, 04 Oct 1999 15:35:06 CDT." <199910042035.PAA27052@gungnir.fnal.gov> Date: Mon, 04 Oct 1999 16:49:16 -0400 From: Bill Sommerfeld Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > And something in between to define it. My thinking right now is that > QTYPE=ADDRS should get back A, AAAA and A6. Any differing opinions? What are the caching semantics for intermediate caching resolvers, where some hosts are doing ADDRS queries and others are just doing A queries? i.e., if an A is cached but A6 isn't, is an intermediate resolver required to do a new ADDRS query to retrieve the other data? What order are the records retrieved in? (in case there isn't room in the reply packet..) (I hope the answer is "yes"). - 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 Mon Oct 4 17:41:16 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) id d950caC08856 for ipng-dist; Mon, 4 Oct 1999 17:38:36 -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.10.0.Beta2+Sun/8.10.0.Beta2) with ESMTP id d950cPi08849 for ; Mon, 4 Oct 1999 17:38:27 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id RAA06590; Mon, 4 Oct 1999 17:38:25 -0700 (PDT) Received: from isrv3.pa.vix.com (isrv3.pa.vix.com [204.152.184.182]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA05442; Mon, 4 Oct 1999 18:38:25 -0600 (MDT) Received: from bb.rc.vix.com (bb.rc.vix.com [204.152.187.11]) by isrv3.pa.vix.com (8.9.1/8.9.1) via ESMTP id RAA02344; Mon, 4 Oct 1999 17:37:52 -0700 (PDT) env-from (Bob_Halley@iengines.net) Received: (from halley@localhost) by bb.rc.vix.com (8.9.1/8.9.1) id RAA29550; Mon, 4 Oct 1999 17:37:52 -0700 (PDT) env-from (Bob_Halley@iengines.net) To: Erik Nordmark Cc: Paul A Vixie , Jim Bound , Matt Crawford , ipng@sunroof.eng.sun.com, namedroppers@internic.net Subject: Re: draft-ietf-ipngwg-dns-lookups-04.txt References: From: Bob Halley Date: 04 Oct 1999 17:37:52 -0700 In-Reply-To: Erik Nordmark's message of "Mon, 4 Oct 1999 12:46:55 -0700 (PDT)" Message-ID: Lines: 102 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik Nordmark writes: > Do we want to define a meta-query for AAAA and A6? > What are the issues in doing so? There are some issues with metaqueries. Many sites are slow to deploy new versions of nameserver software, so we have to expect that servers that do not understand an address metaquery will be around for years to come. How do you tell if the server does not understand the metaquery, or does understand but is saying there are no matching records? E.g. here's the result of a "dig" for type 248 sent to a server: ; <<>> DiG 8.2 <<>> ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUERY SECTION: ;; vix.com, type = 248, class = IN ;; AUTHORITY SECTION: vix.com. 1H IN SOA ns-ext.vix.com. hostmaster.vix.com. ( 1999082900 ; serial 1H ; refresh 30M ; retry 1W ; expiry 1H ) ; minimum Is this server telling me that there are no A, AAAA, or A6 records at this node, or that there are no records of type 248? (The latter happens to be true, but how can you tell?) Also, does the address meta query apply only to A, AAAA, and A6, or does it apply to any present or future "address" type? Making an address metaquery part of some EDNS version would solve the meta/non-meta ambiguity. Caching, especially negative caching, also raises issues. RFC 1035 section 3.6 says The difficulty is that the presence of one RR type in a cache doesn't convey any information about the other because the query which acquired the cached information might have used a QTYPE of MF, MD, or MAILA (which matched both). Similar problems would apply with A, AAAA, A6, and ADDRS if ADDRS does not cause recursion. If doing an ADDRS meta query does cause recursion, do you recurse for the types you do not know about individually, or do you issue an ADDRS query? You must always be prepared to do individual queries, since the remote nameserver might not implement ADDRS. If you do the ADDRS query, do you cache it as a block (i.e. as if there were an ADDRS rrset), or do you cache the types individually? If you do cache as a block and someone issues a query for A6, do you realize you have an ADDRS block and extract what you need, or do you just issue the A6 query? Negative caching adds more fun, since you cannot necessarily construct a coherent negative cache response from negative cache entries created at different times. Assume that I've got a negative cache entry for www.example, type A, in my cache. The negative cache data includes the SOA that was in the negative response; say it was serial number 100. Assume I also have a negative cache entry for www.example, type A6, with SOA serial 101. If I get an ADDRS metaquery, I have to discard the cache data (at least the data with SOA serial 100) since the serial numbers are not the same -- maybe there are A RRs in version 101 of the zone. If I get negative replies with NXT records, I can infer more. Does an ADDRS response mix answers with negative caching? If www.example. has A and A6, but not AAAA, do I get an answer like the following? ; <<>> DiG 8.2 <<>> ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 0 ;; QUERY SECTION: ;; www.example, type = 248, class = IN ;; ANSWER SECTION: www.example. 1H IN A 10.0.0.1 www.example. 1H IN A6 64 ::1:2:3:4 ip6.example. ;; AUTHORITY SECTION: example. 1H IN SOA ns.example. hostmaster.example. ( 1999082900 ; serial 1H ; refresh 30M ; retry 1W ; expiry 1H ) ; minimum EDNS1-style multiple question queries have similar problems. I think things would be a lot simpler if we just did individual queries. /Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 4 18:34:18 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) id d951VTq08971 for ipng-dist; Mon, 4 Oct 1999 18:31:29 -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.88.31]) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) with ESMTP id d951VIi08964 for ; Mon, 4 Oct 1999 18:31:18 -0700 (PDT) Received: from bobo (bobo.Eng.Sun.COM [129.146.86.130]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id SAA764100; Mon, 4 Oct 1999 18:31:16 -0700 (PDT) Date: Mon, 4 Oct 1999 18:31:16 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: draft-ietf-ipngwg-dns-lookups-04.txt To: Bob Halley Cc: Erik Nordmark , Paul A Vixie , Jim Bound , Matt Crawford , ipng@sunroof.eng.sun.com, namedroppers@internic.net 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 > Many sites are slow to deploy new versions of nameserver software, so > we have to expect that servers that do not understand an address > metaquery will be around for years to come. > > How do you tell if the server does not understand the metaquery, or > does understand but is saying there are no matching records? > E.g. here's the result of a "dig" for type 248 sent to a server: Yes, the resolver would clearly need a fallback. I'm assuming we time things so that everything that supports A6 will support the meta-query, which makes the fallback simpler. Try meta-query If NOERROR && ANSWER == 0 try AAAA This is never any worse then Try A6; fallback to AAAA (which is one of the current proposals in the draft) I don't think there has (yet) been a discussion to include A records in the meta-query; it would make the fallback more complex. But once the servers understand the A6 and meta-query a single query would suffice, except when there are no A* records for the name. > I think things would be a lot simpler if we just did individual queries. Sounds like it. But that means we need to figure out what the correct order/choice is between A6 and AAAA in the resolver, and decide to what extent we need a knob to adjust that order/choice over time. 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 4 20:43:03 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) id d953eQq09045 for ipng-dist; Mon, 4 Oct 1999 20:40:26 -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.10.0.Beta2+Sun/8.10.0.Beta2) with ESMTP id d953eGi09038 for ; Mon, 4 Oct 1999 20:40:17 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id UAA03211 for ; Mon, 4 Oct 1999 20:40:15 -0700 (PDT) Received: from mailext12.compaq.com (mailext12.compaq.com [207.18.199.188]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA29351 for ; Mon, 4 Oct 1999 20:40:15 -0700 (PDT) Received: by mailext12.compaq.com (Postfix, from userid 60001) id 2EBA357903; Mon, 4 Oct 1999 22:39:12 -0500 (CDT) Received: from mailext12.compaq.com (localhost [127.0.0.1]) by mailext12.compaq.com (Postfix) with ESMTP id 2C49554602; Mon, 4 Oct 1999 22:39:12 -0500 (CDT) Received: from mailint02.im.hou.compaq.com([not looked up]) (peer mailint02.compaq.com[207.18.199.35]) by mailext12.compaq.com with ESMTP id rcv023734; Mon, 4 Oct 1999 22:39:08 -0500 (CDT) Received: by mailint02.im.hou.compaq.com (Postfix, from userid 60001) id B936DBC4CA; Mon, 4 Oct 1999 22:40:06 -0500 (CDT) Received: from mail.compaq.com (localhost [127.0.0.1]) by mailint02.im.hou.compaq.com (Postfix) with ESMTP id B2919B2A43; Mon, 4 Oct 1999 22:40:06 -0500 (CDT) Received: from quarry.zk3.dec.com([not looked up]) (peer bryquarry.zk3.dec.com[16.141.40.15]) by mail.compaq.com with ESMTP id rcv020747; Mon, 4 Oct 1999 22:40:05 -0500 (CDT) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id XAA0000006071; Mon, 4 Oct 1999 23:40:04 -0400 (EDT) From: Jim Bound Message-Id: <199910050340.XAA0000006071@quarry.zk3.dec.com> To: "Matt Crawford" Cc: ipng@sunroof.eng.sun.com, namedroppers@internic.net Subject: Re: draft-ietf-ipngwg-dns-lookups-04.txt In-reply-to: Your message of "Mon, 04 Oct 1999 15:35:06 CDT." <199910042035.PAA27052@gungnir.fnal.gov> Date: Mon, 04 Oct 1999 23:40:04 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I don't think we should mix A records in the query. Just AAAA or A6. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 6 22:49:02 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) id d975kFw11830 for ipng-dist; Wed, 6 Oct 1999 22:46:15 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) with ESMTP id d975k5R11823 for ; Wed, 6 Oct 1999 22:46:06 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id WAA02393 for ; Wed, 6 Oct 1999 22:46:05 -0700 (PDT) Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA22624 for ; Wed, 6 Oct 1999 22:46:03 -0700 (PDT) Received: from ns.iij.ad.jp (root@ns.iij.ad.jp [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id OAA14284 for ; Thu, 7 Oct 1999 14:45:59 +0900 (JST) Received: from fs.iij.ad.jp (root@fs.iij.ad.jp [192.168.2.9]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id OAA23687 for ; Thu, 7 Oct 1999 14:45:58 +0900 (JST) Received: from localhost (mine.iij.ad.jp [192.168.10.205]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id OAA25897 for ; Thu, 7 Oct 1999 14:45:58 +0900 (JST) To: ipng@sunroof.eng.sun.com Subject: Interim Meeting Report From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) X-Mailer: Mew version 1.95b1 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19991007144601D.kazu@iijlab.net> Date: Thu, 07 Oct 1999 14:46:01 +0900 X-Dispatcher: imput version 991005(IM131) Lines: 17 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The interim meeting held in Japan was finished successfully. The number of attendance is 91 (including 18 visitors). We have put the presentation materials of the Japan activity session and the statistics of RealAudio to the web. Archives of RealAudio is also available from the web. http://www.wide.ad.jp/events/199909.ipng-interim/ We thank those who made this event possible. P.S. Only attendances can get the KAME turtle T-shirts. Please don't ask its availability to me. --Kazu -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 7 12:19:22 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) id d97JE4412357 for ipng-dist; Thu, 7 Oct 1999 12:14:04 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) with ESMTP id d97JDsR12350 for ; Thu, 7 Oct 1999 12:13:56 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA24043 for ; Thu, 7 Oct 1999 12:13:54 -0700 (PDT) Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA20352 for ; Thu, 7 Oct 1999 12:13:54 -0700 (PDT) Received: (from bmanning@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id MAA26196; Thu, 7 Oct 1999 12:13:52 -0700 (PDT) From: Bill Manning Message-Id: <199910071913.MAA26196@zephyr.isi.edu> Subject: Re: draft-ietf-ipngwg-dns-lookups-04.txt To: crawdad@fnal.gov (Matt Crawford) Date: Thu, 7 Oct 1999 12:13:52 -0700 (PDT) Cc: ipng@sunroof.eng.sun.com, namedroppers@internic.net In-Reply-To: <199910042035.PAA27052@gungnir.fnal.gov> from "Matt Crawford" at Oct 4, 99 03:35:06 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > And something in between to define it. My thinking right now is that > QTYPE=ADDRS should get back A, AAAA and A6. Any differing opinions? > > Matt Well, thats a nice subset. Why not get back all ADDR types? -- --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 Thu Oct 7 15:06:51 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) id d97M1gx12635 for ipng-dist; Thu, 7 Oct 1999 15:01:42 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.87.31] (may be forged)) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) with ESMTP id d97M1IR12628 for ; Thu, 7 Oct 1999 15:01:19 -0700 (PDT) Received: from istanbul.eng.sun.com (istanbul.Eng.Sun.COM [129.146.86.247]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id PAA346407; Thu, 7 Oct 1999 15:01:19 -0700 (PDT) Message-Id: <199910072201.PAA346407@jurassic.eng.sun.com> Date: Thu, 7 Oct 1999 15:01:16 -0700 (PDT) From: Alper Yegin Reply-To: Alper Yegin Subject: IPv6 address privacy To: ipng@sunroof.eng.sun.com Cc: aey@jurassic.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 5zuuELOWXq6feDBsUJ5U/g== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4_32 SunOS 5.8 sun4u sparc Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Check this out: "Where's All The Outrage About The IPv6 Privacy Threat?" http://www.techweb.com/se/directlink.cgi?INW19991004S0052 The author is unaware of draft-ietf-ipngwg-addrconf-privacy-00.txt :) Alper Yegin Internet Engineering Sun Microsystems, Inc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 8 07:08:09 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) id d98E4iX13087 for ipng-dist; Fri, 8 Oct 1999 07:04:44 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) with ESMTP id d98E4XR13080 for ; Fri, 8 Oct 1999 07:04:35 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA11161 for ; Fri, 8 Oct 1999 07:04:34 -0700 (PDT) Received: from mailnfs0.tiac.net (mailnfs0.tiac.net [199.0.65.17]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA04580 for ; Fri, 8 Oct 1999 07:04:33 -0700 (PDT) Received: from rms (smiths.tiac.net [199.3.129.167]) by mailnfs0.tiac.net (8.8.8/8.8) with SMTP id KAA01921 for ; Fri, 8 Oct 1999 10:04:31 -0400 (EDT) From: "Richard M. Smith" To: Subject: Privacy problems in IPv6 Date: Fri, 8 Oct 1999 10:04:39 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, Is the attached article accurate in the technical details of the IPv6 addressing scheme? That is, an IPv6 address contains the Ethernet adapter address of a person's computer and the adapter address will be sent out to each and every Web site they visit? Thanks, Richard ========================================== Richard M. Smith Phone: (617) 962-8351 Internet consultant FAX: (617) 731-5572 Email: smiths@tiac.net http://www.tiac.net/users/smiths ========================================== ======================================================================= http://www.techweb.com/se/directlink.cgi?INW19991004S0052 October 04, 1999, Issue: 783 Section: Gray Matter ---------------------------------------------------------------------------- ---- Where's All The Outrage About The IPv6 Privacy Threat? Bill Frezza What happens when companies such as Intel or Microsoft are found to have embedded unique identifiers in their hardware or software that pose potential privacy problems for Internet users? As we know from experience with both the Pentium III Serial Number flap and the Microsoft Win98 Registration Wizard brouhaha, professional privacy advocates sound the alarm, the press launches a feeding frenzy, Wall Street shudders and the alleged corporate miscreants are flogged into backing off. Now, what happens when the Internet Engineering Task Force does the same thing, specifying an addressing structure in its next-generation Internet protocol, IPv6, such that every packet can be traced back to each user's unique network interface card ID? Apparently, nothing. It's a conundrum that makes one wonder about the motives of the reigning Internet digerati, who spend much of their time assuring us that they are protecting our interests as they quietly arrogate power in the new world order. IPv6 was initially proposed to solve the "problem" that IPv4 has with running out of addresses. You would think that the 32-bit address field of IPv4, supporting more than 4 billion unique addresses, would be sufficient to last quite some time. Unfortunately, the cabal that controlled the disposition of these addresses had a habit of handing out large blocks to their friends, who parlayed these into start-ups with multibillion- dollar market caps. Hence, the "shortage." IPv6, on the other hand, has 128 bits of address space, enough to provide a billion-billion addresses for each square meter of the earth's surface. How one could ever route that many addresses is an interesting question, but at least IPv6 will never run out. As you might expect, the address field is so huge that the IETF didn't know how to assign it. So, in a move to get buy-in from established industry standards bodies, the right-most 64 bits were designated to contain EUI-64 format information. This is used by the IEEE to assign Ethernet addresses, which are normally not transmitted outside a user's LAN. Included in EUI-64 are two interesting pieces of information: the registered manufacturer of your NIC card and your 48-bit Ethernet address. Surprise! Every packet you send out onto the public Internet using IPv6 has your fingerprints on it. And unlike your IP address under IPv4, which you can change, this address is embedded in your hardware. Permanently. The spooks and weirdos in Washington, ever eager to empower the surveillance state as they fight a rear-guard action against strong encryption, must be thrilled with such a gift. They appear so thrilled that the Institute for Information Sciences, heavily funded by the Defense Department, is writing a reference stack for IPv6 that it is quietly hoping to slip into Windows 2000. Where are the professional privacy advocates on this issue? Let's start with the Electronic Frontier Foundation (EFF), champions of freedom in cyberspace and cofounders of the TRUSTe initiative. TRUSTe's mission is to build "trust and confidence in the Internet" with a branded, online "trustmark" assuring users that their privacy will be respected. Go search EFF's site and see if you can find a single word about IPv6 and its privacy problems. The EFF's silence is matched by a similar lack of concern from the Center for Democracy and Technology and the Electronic Privacy Information Center, both of which are usually the first to man the barricades when Big Brother comes knocking. Could it be that this unusual averting of the collective gaze is just an embarrassing attempt to avoid airing the family's dirty laundry? With all the interlocking boards, directorates, subcommittees and associations that keep the digerati in sync, it's hard to know where responsibility for this snafu begins and ends. A new advocacy group called the IPv6 Forum, headed by honorary chairman Vint Cerf, is leading the charge for adoption, and the usual alphabet soup of geek groups appears to be falling into line. This may be the reason the press hasn't shown much interest. It's a lot more fun to kick Intel and Microsoft than to rail at the folk heroes credited with creating the Internet. It looks like the geeks screwed up this time, though. I hope they have the wisdom to fix things before it's too late. Bill Frezza is a general partner at Adams Capital Management. He can be reached at frezza@alum.MIT.EDU or www.acm.com. Copyright 1999 CMP Media Inc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 8 07:50:33 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) id d98Ellc13118 for ipng-dist; Fri, 8 Oct 1999 07:47:47 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) with ESMTP id d98ElYR13111 for ; Fri, 8 Oct 1999 07:47:35 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA21784 for ; Fri, 8 Oct 1999 07:47:34 -0700 (PDT) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA22729 for ; Fri, 8 Oct 1999 07:47:33 -0700 (PDT) Received: from hermes.research.att.com (hermes.research.att.com [135.207.16.38]) by mail-blue.research.att.com (Postfix) with ESMTP id C73574CE09; Fri, 8 Oct 1999 10:47:32 -0400 (EDT) Received: from SIGABA.research.att.com (sigaba.research.att.com [135.207.23.169]) by hermes.research.att.com (8.8.7/8.8.7) with ESMTP id KAA15278; Fri, 8 Oct 1999 10:47:35 -0400 (EDT) Received: by SIGABA.research.att.com (Postfix, from userid 54047) id 2E6E341F16; Fri, 8 Oct 1999 10:47:30 -0400 (EDT) Received: from roc (localhost [127.0.0.1]) by SIGABA.research.att.com (Postfix) with ESMTP id 1F6FC400B4; Fri, 8 Oct 1999 10:47:25 -0400 (EDT) X-Mailer: exmh version 2.0.2 2/24/98 From: "Steven M. Bellovin" To: "Richard M. Smith" Cc: ipng@sunroof.eng.sun.com Subject: Re: Privacy problems in IPv6 Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Date: Fri, 08 Oct 1999 10:47:24 -0400 Message-Id: <19991008144730.2E6E341F16@SIGABA.research.att.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id d98ElaR13112 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message , "Richard M. Smith" w rites: > Hi, > > Is the attached article accurate in the technical details of > the IPv6 addressing scheme? That is, an IPv6 address > contains the Ethernet adapter address of a person's > computer and the adapter address will be sent out to each > and every Web site they visit? Yes and no. Yes, that's one scheme that's been proposed, though the motivation was to permit easy autoconfiguration. But privacy is a concern, so there's an alternate mechanism being defined; see http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-addrconf-privacy-00.txt --Steve Bellovin -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 8 07:52:13 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) id d98Eoj213129 for ipng-dist; Fri, 8 Oct 1999 07:50:45 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) with ESMTP id d98EoTR13120 for ; Fri, 8 Oct 1999 07:50:30 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA15882 for ; Fri, 8 Oct 1999 07:50:26 -0700 (PDT) Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.211]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA24156 for ; Fri, 8 Oct 1999 07:50:11 -0700 (PDT) Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.9.1a/8.9.1) id QAA09429; Fri, 8 Oct 1999 16:49:16 +0200 (MET DST) Message-ID: <19991008164916.C8951@theory.cs.uni-bonn.de> Date: Fri, 8 Oct 1999 16:49:16 +0200 From: Ignatios Souvatzis To: "Richard M. Smith" , ipng@sunroof.eng.sun.com Subject: Re: Privacy problems in IPv6 References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from Richard M. Smith on Fri, Oct 08, 1999 at 10:04:39AM -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, Oct 08, 1999 at 10:04:39AM -0400, Richard M. Smith wrote: > Is the attached article accurate in the technical details of > the IPv6 addressing scheme? That is, an IPv6 address > contains the Ethernet adapter address of a person's > computer and the adapter address will be sent out to each > and every Web site they visit? The address will be sent to each and every web site they visit, so that the answer can be sent back to them. This happens unless they go through their companies', their school's, their ISP's proxy server. (And they should do that even for reasons not connected to privacy.) In that case, the proxy servers' address will be used instead. But let's assume they don't use a proxy server. 1) An IPv6 address consists of an address for the cable and an interface address. There are several methods to generate interface IDs. Stateless address autoconfiguration on Ethernet links uses an EUI-64 derived from the Ethernet address of the interface. Yes, this one is basically unique, and could be used to track the activity of this interface. You can, however, use automatic configuration using DHCP instead, or manual configuration, leading to addresses that don't associate globally uniquely identifiable addresses with interfaces. Or even use the technical solution described in 5) 2) A computer can have more than one interface. Interfaces can be put into different computers, a different interface can be put into your computer, so the Ethernet address of the interface that you are currently using does not identify the computer you are using. 3) A computer can have more than one user, (in fact, all computers I have access to have more than one user), so identifying the computer does not identify a user. 4) Of the computers used by single persons, most are used by people at home who connect through some dialup IP ISP, who in turn reuses addresses whenever somebody goes offline. Those computers most of the time do NOT have any Ethernet address, and even if they had, it would not be used for their dialup interface. I do not think this practice will change with IPv6. 5) Or you can use the method described in http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-addrconf-privacy-00.txt, which actively changes your address from time to time. As for the cited article: the author was clearly not aware of 5), and hadn't considered 1)..4) enough. I agree there is a privacy problem with Internet. It is already there, with IPv4 (and independent of it), created by the Cookie mechanism, which makes you identifiable even with changing addresses. IPv6 won't make the situation better or worse in this respect. The cookie mechanism was invented to make persons trackable even when they use proxy servers (see above). I suggest you switch cookies off. Regards, Ignatios Souvatzis -- * Progress (n.): The process through which Usenet has evolved from smart people in front of dumb terminals to dumb people in front of smart terminals. -- obs@burnout.demon.co.uk (obscurity) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 8 07:55:56 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) id d98EsXt13154 for ipng-dist; Fri, 8 Oct 1999 07:54:33 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) with ESMTP id d98EsNR13147 for ; Fri, 8 Oct 1999 07:54:25 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA22548 for ; Fri, 8 Oct 1999 07:54:24 -0700 (PDT) Received: from chmls05.mediaone.net (ne.mediaone.net [24.128.1.70]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA26901 for ; Fri, 8 Oct 1999 07:54:23 -0700 (PDT) Received: from gateway (loshin.ne.mediaone.net [24.128.200.158]) by chmls05.mediaone.net (8.8.7/8.8.7) with SMTP id KAA11852 for ; Fri, 8 Oct 1999 10:54:20 -0400 (EDT) Message-Id: <4.1.19991008101959.00c35cd0@pop.ne.mediaone.net> X-Sender: rapo@mail130.pair.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 08 Oct 1999 10:51:42 -0400 To: From: Pete Loshin Subject: Re: Privacy problems in IPv6 In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 10:04 AM 10/8/99 -0400, Richard M. Smith wrote: >Hi, > >Is the attached article accurate in the technical details of >the IPv6 addressing scheme? That is, an IPv6 address >contains the Ethernet adapter address of a person's >computer and the adapter address will be sent out to each >and every Web site they visit? There are large and small technical errors in this column (not article). Check RFC 2373, for example. Also, this paragraph, questioning how IPv6 could route so many addresses, points out the ignorance of this particular columnist (he obviously did not read RFC 2374): "IPv6, on the other hand, has 128 bits of address space.... How one could ever route that many addresses is an interesting question, but at least IPv6 will never run out." If you want to state your case and refute or rebut this kind of thing, the editors of the website should be very happy to have it; they may even pay you to write it up and submit it. In any case, anyone who wishes to stem the tide of FUD should get in touch with the editors who publish FUD. -pl +-------------------------------------------------------------+ | Pete Loshin http://Internet-Standard.com | | | | _IPv6 Clearly Explained_ Morgan Kaufmann January 1999 | | _TCP/IP Clearly Explained_ 3rd ed Morgan Kaufmann June 1999 | | | +-------------------------------------------------------------+ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 8 07:58:16 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) id d98Ev8h13172 for ipng-dist; Fri, 8 Oct 1999 07:57:08 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) with ESMTP id d98EuvR13165 for ; Fri, 8 Oct 1999 07:56:59 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA16745 for ; Fri, 8 Oct 1999 07:56:57 -0700 (PDT) Received: from mailnfs0.tiac.net (mailnfs0.tiac.net [199.0.65.17]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA03714 for ; Fri, 8 Oct 1999 08:56:56 -0600 (MDT) Received: from rms (smiths.tiac.net [199.3.129.167]) by mailnfs0.tiac.net (8.8.8/8.8) with SMTP id KAA11028; Fri, 8 Oct 1999 10:56:54 -0400 (EDT) From: "Richard M. Smith" To: Cc: Subject: RE: Privacy problems in IPv6 Date: Fri, 8 Oct 1999 10:57:04 -0400 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.2910.0) X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal In-Reply-To: <19991008144730.2E6E341F16@SIGABA.research.att.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Steve, Thanks for the link. Any idea what this alternative is not mandatory? That is, an Ethernet adapter address is never sent inside an IPv6 address. Richard > -----Original Message----- > From: smb@research.att.com [mailto:smb@research.att.com] > Sent: Friday, October 08, 1999 10:47 AM > To: Richard M. Smith > Cc: ipng@sunroof.eng.sun.com > Subject: Re: Privacy problems in IPv6 > > > In message , > "Richard M. Smith" w > rites: > > Hi, > > > > Is the attached article accurate in the technical details of > > the IPv6 addressing scheme? That is, an IPv6 address > > contains the Ethernet adapter address of a person's > > computer and the adapter address will be sent out to each > > and every Web site they visit? > > Yes and no. > > Yes, that's one scheme that's been proposed, though the motivation was to > permit easy autoconfiguration. But privacy is a concern, so there's an > alternate mechanism being defined; see > http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-addrconf-pri vacy-00.txt --Steve Bellovin -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 8 08:19:56 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) id d98FGKT13196 for ipng-dist; Fri, 8 Oct 1999 08:16:20 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) with ESMTP id d98FFjR13189 for ; Fri, 8 Oct 1999 08:15:51 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA12371 for ; Fri, 8 Oct 1999 08:15:44 -0700 (PDT) Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.211]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA05963 for ; Fri, 8 Oct 1999 08:15:30 -0700 (PDT) Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.9.1a/8.9.1) id RAA09816; Fri, 8 Oct 1999 17:13:31 +0200 (MET DST) Message-ID: <19991008171331.D8951@theory.cs.uni-bonn.de> Date: Fri, 8 Oct 1999 17:13:31 +0200 From: Ignatios Souvatzis To: "Richard M. Smith" , smb@research.att.com Cc: ipng@sunroof.eng.sun.com Subject: Re: Privacy problems in IPv6 References: <19991008144730.2E6E341F16@SIGABA.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from Richard M. Smith on Fri, Oct 08, 1999 at 10:57:04AM -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, Oct 08, 1999 at 10:57:04AM -0400, Richard M. Smith wrote: > Any idea what this alternative is not mandatory? > That is, an Ethernet adapter address is never > sent inside an IPv6 address. The latter does NOT make any difference. As long as your machine has an address that doesn't change, and you're the only user, and you use it for "surfing", and you don't use a proxy server, you are trackable, even with IPv4. This is no IPv6 problem. However, the people who want to track you have invented "cookies", and use them, today. So as long as you don't switch off cookies, switching your address, using a proxy server, etc. won't help you. -is -- * Progress (n.): The process through which Usenet has evolved from smart people in front of dumb terminals to dumb people in front of smart terminals. -- obs@burnout.demon.co.uk (obscurity) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 8 08:24:08 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) id d98FMmu13221 for ipng-dist; Fri, 8 Oct 1999 08:22:48 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) with ESMTP id d98FMcR13214 for ; Fri, 8 Oct 1999 08:22:39 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA17952 for ; Fri, 8 Oct 1999 08:22:38 -0700 (PDT) Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA08787 for ; Fri, 8 Oct 1999 08:22:37 -0700 (PDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id LAA24050; Fri, 8 Oct 1999 11:22:23 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.37.82.31]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id LAA20196; Fri, 8 Oct 1999 11:22:25 -0400 Received: from rotala.raleigh.ibm.com (localhost [127.0.0.1]) by rotala.raleigh.ibm.com (8.9.3/8.7/RTP-ral-1.0) with ESMTP id LAA06672; Fri, 8 Oct 1999 11:18:10 -0400 Message-Id: <199910081518.LAA06672@rotala.raleigh.ibm.com> To: "Richard M. Smith" cc: ipng@sunroof.eng.sun.com Subject: Re: Privacy problems in IPv6 In-Reply-To: Message from "Richard M. Smith" of "Fri, 08 Oct 1999 10:04:39 EDT." Date: Fri, 08 Oct 1999 11:18:10 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Richard, The article has a number of technical inaccuracies. > Now, what happens when the Internet Engineering Task Force does the same > thing, specifying an addressing structure in its next-generation Internet > protocol, IPv6, such that every packet can be traced back to each user's > unique network interface card ID? Apparently, nothing. IPv6 addresses contain MAC addresses only if they were created via stateless autoconfiguration. If one were to use DHCP instead, this wouldn't necessarily be the case. (I say necessarily because it would then be the policy of the server that determines what address you would get.) > IPv6 was initially proposed to solve the "problem" that IPv4 has with > running out of addresses. You would think that the 32-bit address field of > IPv4, supporting more than 4 billion unique addresses, would be sufficient > to last quite some time. Unfortunately, the cabal that controlled the > disposition of these addresses had a habit of handing out large blocks to > their friends, who parlayed these into start-ups with multibillion- > dollar market caps. Hence, the "shortage." The above is grossly innaccurate. I know few people that argue (convincingly) that we are not in danger of running out of globally unique IPv4 addresses. It is a question of when, not if. This has nothing to do with "cabals". It has to do with the exponential growth of the Internet, and the current/future trend of making every device (cell phones, consumer electronics, etc.) capable of connecting to the Internet. While it is true that some organizations have received seemingly huge and "wasteful" assignments, this was (for the most part) done long ago (e.g., in the 1980s) before anyone had an inkling that address space needed to be coserved. Also, only 1/4 of the total IPv4 address space is in use today, so the large blocks that have been handed out in the past cannot be considered the main problem today. The "shortage" today is more interesting, given that only 1/4 of the total address space is actually in use. In practice, however, address registries are being much more stringent about giving out addresses. Some folks (like those that can't get as many as they'd like) say too stringent. But the registries are motivated by the concern that IPv4 addresses are in fact a limited resource today that must be carefully managed. This is a complex issue with many differing opinions as to whether the current policies are in fact "right". > As you might expect, the address field is so huge that the IETF > didn't know how to assign it. So, in a move to get buy-in from > established industry standards bodies, the right-most 64 bits were > designated to contain EUI-64 format information. This is used by the > IEEE to assign Ethernet addresses, which are normally not > transmitted outside a user's LAN. The 64-bits contain the EUI-64 address for several reasons. For one thing, 128 bits *is* a lot, and splitting an address into 64 bits for routing & 64 for host identification does not appear to limit growth in any realistic sense. 64 bits for routing seems more than adequate and certainly won't limit future growth. Having the 64-bit EUI for the Interface Identifier keeps stateless address autoconfiguration simple and robust. Also, the 64-bit EUI was chosen to allow future flexibility with new architectures that might allow IP addresses to be cleanly separated into a locator and identifier portion. Again, the EUI-64 is (generally) globally unique, which appears to be a desirable property from the perspective of separating addrsses into locator/identifier portions. I don't understand the reference to "buy in from established industry standards bodies". We use EUI-64 identifiers because they already happen to exist and have the desired properties (globally unique and available on pretty much all hardware). The IETF in never contacted the IEEE about using them. We just use them. > Included in EUI-64 are two interesting pieces of information: the > registered manufacturer of your NIC card and your 48-bit Ethernet > address. Surprise! Every packet you send out onto the public > Internet using IPv6 has your fingerprints on it. And unlike your IP > address under IPv4, which you can change, this address is embedded > in your hardware. Permanently. Strictly speaking, not true. From the perspective of stateless address autoconfiguration, one can use an identifier other than the one in the hardware. This does require manual configuration by the end user. But it is specifically called out for in the design because it is needed to handle the case where duplicate addresses occur in hardware. > The spooks and weirdos in Washington, ever eager to empower the > surveillance state as they fight a rear-guard action against strong > encryption, must be thrilled with such a gift. They appear so > thrilled that the Institute for Information Sciences, heavily funded > by the Defense Department, is writing a reference stack for IPv6 > that it is quietly hoping to slip into Windows 2000. Well, if every research project that gets some dollars from govt. is in reality a nefarious plot run by the "spooks and weirdos" with a hidden agenda, I guess this might be true. (To be clear: I don't happen to subscribe to this particular school.) > It looks like the geeks screwed up this time, though. I hope they > have the wisdom to fix things before it's too late. The issue of EUI-64s in IPv6 addresses has been a known problem for a long time. But the community is certainly not in agreement about how serious a problem it really is in practice. It is important to distinguish here "reality" from "perception". You might take a look at draft-ietf-ipngwg-addrconf-privacy-00.txt. It attempts to discuss some of the issues and attempts to put them in perspective. The document also proposes a solution for those that believe the issue is significant. (The document also is a work-in-progress with another version coming, so it is certainly not the final word on the topic.) The document takes the view that this would be an optional approach precisely because it it is unclear that it is the best approach for all environments. Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Oct 8 09:27:30 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) id d98GOOL13304 for ipng-dist; Fri, 8 Oct 1999 09:24:24 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) with ESMTP id d98GOER13297 for ; Fri, 8 Oct 1999 09:24:15 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA07598 for ; Fri, 8 Oct 1999 09:24:14 -0700 (PDT) Received: from hotmail.com (f275.law3.hotmail.com [209.185.240.53]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id KAA21382 for ; Fri, 8 Oct 1999 10:24:12 -0600 (MDT) Received: (qmail 73814 invoked by uid 0); 8 Oct 1999 16:24:12 -0000 Message-ID: <19991008162412.73813.qmail@hotmail.com> Received: from 138.87.75.119 by www.hotmail.com with HTTP; Fri, 08 Oct 1999 09:24:11 PDT X-Originating-IP: [138.87.75.119] From: "Waraporn Viyanon" To: ipng@sunroof.eng.sun.com Subject: Quality of service. Date: Fri, 08 Oct 1999 23:24:11 ICT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, Do you know about the Quality of service of IPv6? I would like to know about the delay and the package loss. Regards, Waraporn. ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.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 8 10:17:11 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) id d98HBxF13379 for ipng-dist; Fri, 8 Oct 1999 10:11:59 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) with ESMTP id d98HBoR13372 for ; Fri, 8 Oct 1999 10:11:51 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA16740 for ; Fri, 8 Oct 1999 10:11:49 -0700 (PDT) Received: from dfw-ix16.ix.netcom.com (dfw-ix16.ix.netcom.com [206.214.98.16]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA24008 for ; Fri, 8 Oct 1999 10:11:48 -0700 (PDT) Received: (from smap@localhost) by dfw-ix16.ix.netcom.com (8.8.4/8.8.4) id MAA24695; Fri, 8 Oct 1999 12:11:12 -0500 (CDT) Received: from dal-tx46-46.ix.netcom.com(198.211.44.174) by dfw-ix16.ix.netcom.com via smap (V1.3) id rma024459; Fri Oct 8 12:08:58 1999 Message-ID: <37FDB4FE.B2173B39@ix.netcom.com> Date: Fri, 08 Oct 1999 10:10:24 +0100 From: Jeff Williams Organization: INEG. Inc. (Spokesman INEGroup) X-Mailer: Mozilla 4.08 [en] (Win16; I) MIME-Version: 1.0 To: "Richard M. Smith" CC: ipng@sunroof.eng.sun.com Subject: Re: Privacy problems in IPv6 References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Richard and all, I warned of this months ago. It was basicaly ignored. Richard M. Smith wrote: > Hi, > > Is the attached article accurate in the technical details of > the IPv6 addressing scheme? That is, an IPv6 address > contains the Ethernet adapter address of a person's > computer and the adapter address will be sent out to each > and every Web site they visit? > > Thanks, > Richard > > ========================================== > Richard M. Smith Phone: (617) 962-8351 > Internet consultant FAX: (617) 731-5572 > Email: smiths@tiac.net > http://www.tiac.net/users/smiths > ========================================== > > ======================================================================= > > http://www.techweb.com/se/directlink.cgi?INW19991004S0052 > > October 04, 1999, Issue: 783 > Section: Gray Matter > ---------------------------------------------------------------------------- > ---- > Where's All The Outrage About The IPv6 Privacy Threat? > Bill Frezza > > What happens when companies such as Intel or Microsoft are found to have > embedded unique identifiers in their hardware or software that pose > potential privacy problems for Internet users? As we know from experience > with both the Pentium III Serial Number flap and the Microsoft Win98 > Registration Wizard brouhaha, professional privacy advocates sound the > alarm, the press launches a feeding frenzy, Wall Street shudders and the > alleged corporate miscreants are flogged into backing off. > > Now, what happens when the Internet Engineering Task Force does the same > thing, specifying an addressing structure in its next-generation Internet > protocol, IPv6, such that every packet can be traced back to each user's > unique network interface card ID? Apparently, nothing. > > It's a conundrum that makes one wonder about the motives of the reigning > Internet digerati, who spend much of their time assuring us that they are > protecting our interests as they quietly arrogate power in the new world > order. > > IPv6 was initially proposed to solve the "problem" that IPv4 has with > running out of addresses. You would think that the 32-bit address field of > IPv4, supporting more than 4 billion unique addresses, would be sufficient > to last quite some time. Unfortunately, the cabal that controlled the > disposition of these addresses had a habit of handing out large blocks to > their friends, who parlayed these into start-ups with multibillion- > > dollar market caps. Hence, the "shortage." > > IPv6, on the other hand, has 128 bits of address space, enough to provide a > billion-billion addresses for each square meter of the earth's surface. How > one could ever route that many addresses is an interesting question, but at > least IPv6 will never run out. > > As you might expect, the address field is so huge that the IETF didn't know > how to assign it. So, in a move to get buy-in from established industry > standards bodies, the right-most 64 bits were designated to contain EUI-64 > format information. This is used by the IEEE to assign Ethernet addresses, > which are normally not transmitted outside a user's LAN. > > Included in EUI-64 are two interesting pieces of information: the registered > manufacturer of your NIC card and your 48-bit Ethernet address. Surprise! > Every packet you send out onto the public Internet using IPv6 has your > fingerprints on it. And unlike your IP address under IPv4, which you can > change, this address is embedded in your hardware. Permanently. > > The spooks and weirdos in Washington, ever eager to empower the surveillance > state as they fight a rear-guard action against strong encryption, must be > thrilled with such a gift. They appear so thrilled that the Institute for > Information Sciences, heavily funded by the Defense Department, is writing a > reference stack for IPv6 that it is quietly hoping to slip into Windows > 2000. > > Where are the professional privacy advocates on this issue? Let's start with > the Electronic Frontier Foundation (EFF), champions of freedom in cyberspace > and cofounders of the TRUSTe initiative. TRUSTe's mission is to build "trust > and confidence in the Internet" with a branded, online "trustmark" assuring > users that their privacy will be respected. Go search EFF's site and see if > you can find a single word about IPv6 and its privacy problems. The EFF's > silence is matched by a similar lack of concern from the Center for > Democracy and Technology and the Electronic Privacy Information Center, both > of which are usually the first to man the barricades when Big Brother comes > knocking. > > Could it be that this unusual averting of the collective gaze is just an > embarrassing attempt to avoid airing the family's dirty laundry? With all > the interlocking boards, directorates, subcommittees and associations that > keep the digerati in sync, it's hard to know where responsibility for this > snafu begins and ends. > > A new advocacy group called the IPv6 Forum, headed by honorary chairman Vint > Cerf, is leading the charge for adoption, and the usual alphabet soup of > geek groups appears to be falling into line. This may be the reason the > press hasn't shown much interest. It's a lot more fun to kick Intel and > Microsoft than to rail at the folk heroes credited with creating the > Internet. > > It looks like the geeks screwed up this time, though. I hope they have the > wisdom to fix things before it's too late. > > Bill Frezza is a general partner at Adams Capital Management. He can be > reached at frezza@alum.MIT.EDU or www.acm.com. > > Copyright 1999 CMP Media Inc. > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- Regards, -- Jeffrey A. Williams Spokesman INEGroup (Over 95k members strong!) CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 972-447-1894 Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 8 10:28:42 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) id d98HPNi13402 for ipng-dist; Fri, 8 Oct 1999 10:25:23 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) with ESMTP id d98HPDR13395 for ; Fri, 8 Oct 1999 10:25:14 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA19701 for ; Fri, 8 Oct 1999 10:25:13 -0700 (PDT) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id LAA25327 for ; Fri, 8 Oct 1999 11:25:06 -0600 (MDT) Received: from 157.54.9.108 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 08 Oct 1999 09:40:07 -0700 (Pacific Daylight Time) Received: by INET-IMC-05 with Internet Mail Service (5.5.2524.0) id <4MLNJNWA>; Fri, 8 Oct 1999 09:40:07 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D81014515B7B@RED-MSG-50> From: Richard Draves To: "'Thomas Narten'" , "Richard M. Smith" Cc: ipng@sunroof.eng.sun.com Subject: RE: Privacy problems in IPv6 Date: Fri, 8 Oct 1999 09:39:58 -0700 X-Mailer: Internet Mail Service (5.5.2524.0) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > The spooks and weirdos in Washington, ever eager to empower the > > surveillance state as they fight a rear-guard action against strong > > encryption, must be thrilled with such a gift. They appear so > > thrilled that the Institute for Information Sciences, heavily funded > > by the Defense Department, is writing a reference stack for IPv6 > > that it is quietly hoping to slip into Windows 2000. > > Well, if every research project that gets some dollars from govt. is > in reality a nefarious plot run by the "spooks and weirdos" with a > hidden agenda, I guess this might be true. (To be clear: I don't > happen to subscribe to this particular school.) The government is not funding ISI's work on MSR IPv6. 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 8 23:41:51 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) id d996dMk13982 for ipng-dist; Fri, 8 Oct 1999 23:39:22 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) with ESMTP id d996dBR13975 for ; Fri, 8 Oct 1999 23:39:12 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id XAA03435 for ; Fri, 8 Oct 1999 23:39:12 -0700 (PDT) Received: from hamper (relay.bt.net [194.72.6.60]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA17228 for ; Fri, 8 Oct 1999 23:39:11 -0700 (PDT) Received: from wstaalnt544731.ukcore.bt.net by hamper with SMTP (XT-PP); Sat, 9 Oct 1999 07:38:23 +0100 Received: by wstaalnt544731.ukcore.bt.net with Microsoft Mail id <01BF1228.DC8EC880@wstaalnt544731.ukcore.bt.net>; Sat, 9 Oct 1999 07:35:29 +0100 Message-ID: <01BF1228.DC8EC880@wstaalnt544731.ukcore.bt.net> From: Jim Dunn To: "'Thomas Narten'" , "Richard M. Smith" Cc: "ipng@sunroof.eng.sun.com" Subject: RE: Privacy problems in IPv6 Date: Sat, 9 Oct 1999 07:35:28 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id d996dDR13976 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk IMHO I believe it would be better to target our comments and responses to the author of the article who has made a number of incorrect (and possibly damaging) assumptions. The problem with these sorts of articles, is that they are usually written by people from an business/financial analyst's background, who lack the technical understanding or have not researched the subject enough to write an impartial report. (see below for author) Bill Frezza is a general partner at Adams Capital Management. He can be reached at frezza@alum.MIT.EDU or www.acm.com. This is potentially very damaging for us, due to the audience at which the article is directed. People will read the article and believe it (what ever happened to responsible journalism ;-> ) and consumer demand for IPv6 will decrease because of it. If you ask around, many people are vaguely aware that a new IP version is becoming available, but don't know much about it, I work with many IP engineers who know vast ammounts about v4 but little if anything of v6, and articles like this that do not help, because they do not give both sides of the argument and allow people to make a rational and informed decision especially when privacy is involved, a subject that most people can work themselves into a frenzy over, very easily. In many parts of the world, Privacy is a hard won right and people get very twitchy if they feel that right to privacy is being obused. We have to make sure that articles of this nature are technically accurate and portray the subject matter impartially, so that people don't jump to conclusions. IPv6 has been in development for a long time, with some extremely clever people contributing to it's continued development, the last thing we want is for deployment to stall because the user's do not have confidence in it. Jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -----Original Message----- From: Thomas Narten [SMTP:narten@raleigh.ibm.com] Sent: 08 October 1999 16:18 To: Richard M. Smith Cc: ipng@sunroof.eng.sun.com Subject: Re: Privacy problems in IPv6 Richard, The article has a number of technical inaccuracies. > Now, what happens when the Internet Engineering Task Force does the same > thing, specifying an addressing structure in its next-generation Internet > protocol, IPv6, such that every packet can be traced back to each user's > unique network interface card ID? Apparently, nothing. IPv6 addresses contain MAC addresses only if they were created via stateless autoconfiguration. If one were to use DHCP instead, this wouldn't necessarily be the case. (I say necessarily because it would then be the policy of the server that determines what address you would get.) > IPv6 was initially proposed to solve the "problem" that IPv4 has with > running out of addresses. You would think that the 32-bit address field of > IPv4, supporting more than 4 billion unique addresses, would be sufficient > to last quite some time. Unfortunately, the cabal that controlled the > disposition of these addresses had a habit of handing out large blocks to > their friends, who parlayed these into start-ups with multibillion- > dollar market caps. Hence, the "shortage." The above is grossly innaccurate. I know few people that argue (convincingly) that we are not in danger of running out of globally unique IPv4 addresses. It is a question of when, not if. This has nothing to do with "cabals". It has to do with the exponential growth of the Internet, and the current/future trend of making every device (cell phones, consumer electronics, etc.) capable of connecting to the Internet. While it is true that some organizations have received seemingly huge and "wasteful" assignments, this was (for the most part) done long ago (e.g., in the 1980s) before anyone had an inkling that address space needed to be coserved. Also, only 1/4 of the total IPv4 address space is in use today, so the large blocks that have been handed out in the past cannot be considered the main problem today. The "shortage" today is more interesting, given that only 1/4 of the total address space is actually in use. In practice, however, address registries are being much more stringent about giving out addresses. Some folks (like those that can't get as many as they'd like) say too stringent. But the registries are motivated by the concern that IPv4 addresses are in fact a limited resource today that must be carefully managed. This is a complex issue with many differing opinions as to whether the current policies are in fact "right". > As you might expect, the address field is so huge that the IETF > didn't know how to assign it. So, in a move to get buy-in from > established industry standards bodies, the right-most 64 bits were > designated to contain EUI-64 format information. This is used by the > IEEE to assign Ethernet addresses, which are normally not > transmitted outside a user's LAN. The 64-bits contain the EUI-64 address for several reasons. For one thing, 128 bits *is* a lot, and splitting an address into 64 bits for routing & 64 for host identification does not appear to limit growth in any realistic sense. 64 bits for routing seems more than adequate and certainly won't limit future growth. Having the 64-bit EUI for the Interface Identifier keeps stateless address autoconfiguration simple and robust. Also, the 64-bit EUI was chosen to allow future flexibility with new architectures that might allow IP addresses to be cleanly separated into a locator and identifier portion. Again, the EUI-64 is (generally) globally unique, which appears to be a desirable property from the perspective of separating addrsses into locator/identifier portions. I don't understand the reference to "buy in from established industry standards bodies". We use EUI-64 identifiers because they already happen to exist and have the desired properties (globally unique and available on pretty much all hardware). The IETF in never contacted the IEEE about using them. We just use them. > Included in EUI-64 are two interesting pieces of information: the > registered manufacturer of your NIC card and your 48-bit Ethernet > address. Surprise! Every packet you send out onto the public > Internet using IPv6 has your fingerprints on it. And unlike your IP > address under IPv4, which you can change, this address is embedded > in your hardware. Permanently. Strictly speaking, not true. From the perspective of stateless address autoconfiguration, one can use an identifier other than the one in the hardware. This does require manual configuration by the end user. But it is specifically called out for in the design because it is needed to handle the case where duplicate addresses occur in hardware. > The spooks and weirdos in Washington, ever eager to empower the > surveillance state as they fight a rear-guard action against strong > encryption, must be thrilled with such a gift. They appear so > thrilled that the Institute for Information Sciences, heavily funded > by the Defense Department, is writing a reference stack for IPv6 > that it is quietly hoping to slip into Windows 2000. Well, if every research project that gets some dollars from govt. is in reality a nefarious plot run by the "spooks and weirdos" with a hidden agenda, I guess this might be true. (To be clear: I don't happen to subscribe to this particular school.) > It looks like the geeks screwed up this time, though. I hope they > have the wisdom to fix things before it's too late. The issue of EUI-64s in IPv6 addresses has been a known problem for a long time. But the community is certainly not in agreement about how serious a problem it really is in practice. It is important to distinguish here "reality" from "perception". You might take a look at draft-ietf-ipngwg-addrconf-privacy-00.txt. It attempts to discuss some of the issues and attempts to put them in perspective. The document also proposes a solution for those that believe the issue is significant. (The document also is a work-in-progress with another version coming, so it is certainly not the final word on the topic.) The document takes the view that this would be an optional approach precisely because it it is unclear that it is the best approach for all environments. Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 11 00:30:57 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) id d9B7QVa14922 for ipng-dist; Mon, 11 Oct 1999 00:26:31 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) with ESMTP id d9B7QKR14915 for ; Mon, 11 Oct 1999 00:26:21 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id AAA10978 for ; Mon, 11 Oct 1999 00:26:19 -0700 (PDT) Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.211]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA26595 for ; Mon, 11 Oct 1999 00:25:32 -0700 (PDT) Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.9.1a/8.9.1) id JAA29206; Mon, 11 Oct 1999 09:24:06 +0200 (MET DST) Message-ID: <19991011092406.C29084@theory.cs.uni-bonn.de> Date: Mon, 11 Oct 1999 09:24:06 +0200 From: Ignatios Souvatzis To: Jim Dunn , "'Thomas Narten'" , "Richard M. Smith" Cc: "ipng@sunroof.eng.sun.com" Subject: Re: Privacy problems in IPv6 References: <01BF1228.DC8EC880@wstaalnt544731.ukcore.bt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <01BF1228.DC8EC880@wstaalnt544731.ukcore.bt.net>; from Jim Dunn on Sat, Oct 09, 1999 at 07:35:28AM +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sat, Oct 09, 1999 at 07:35:28AM +0100, Jim Dunn wrote: > IMHO I believe it would be better to target our comments and responses to the author of the article who has made a number of incorrect (and possibly damaging) assumptions. I did, and didn't get any reaction up to now. Well, its deep Sunday night where he lives, so this still might change. -is -- * Progress (n.): The process through which Usenet has evolved from smart people in front of dumb terminals to dumb people in front of smart terminals. -- obs@burnout.demon.co.uk (obscurity) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 11 00:53:41 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) id d9B7p9B14958 for ipng-dist; Mon, 11 Oct 1999 00:51:09 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) with ESMTP id d9B7oxR14951 for ; Mon, 11 Oct 1999 00:51:00 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id AAA07430 for ; Mon, 11 Oct 1999 00:50:58 -0700 (PDT) Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.211]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA01673 for ; Mon, 11 Oct 1999 00:50:57 -0700 (PDT) Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.9.1a/8.9.1) id JAA29352; Mon, 11 Oct 1999 09:50:24 +0200 (MET DST) Message-ID: <19991011095024.A29302@theory.cs.uni-bonn.de> Date: Mon, 11 Oct 1999 09:50:24 +0200 From: Ignatios Souvatzis To: Ignatios Souvatzis , Jim Dunn , "'Thomas Narten'" , "Richard M. Smith" Cc: "ipng@sunroof.eng.sun.com" Subject: Re: Privacy problems in IPv6 References: <01BF1228.DC8EC880@wstaalnt544731.ukcore.bt.net> <19991011092406.C29084@theory.cs.uni-bonn.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <19991011092406.C29084@theory.cs.uni-bonn.de>; from Ignatios Souvatzis on Mon, Oct 11, 1999 at 09:24:06AM +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, Oct 11, 1999 at 09:24:06AM +0200, Ignatios Souvatzis wrote: > On Sat, Oct 09, 1999 at 07:35:28AM +0100, Jim Dunn wrote: > > IMHO I believe it would be better to target our comments and responses to the author of the article who has made a number of incorrect (and possibly damaging) assumptions. > > I did, and didn't get any reaction up to now. Well, its deep Sunday night > where he lives, so this still might change. Actually, it just arrived. AFAICT, he pretends to acknowledge that dynamic IP addresses (at dialup providers) make this problem go away, but makes IPv6 responsible for the deployment of cable modems. -is -- * Progress (n.): The process through which Usenet has evolved from smart people in front of dumb terminals to dumb people in front of smart terminals. -- obs@burnout.demon.co.uk (obscurity) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 11 05:31:08 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) id d9BCSCr15095 for ipng-dist; Mon, 11 Oct 1999 05:28:12 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) with ESMTP id d9BCS2R15088 for ; Mon, 11 Oct 1999 05:28:04 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id FAA27876 for ; Mon, 11 Oct 1999 05:28:03 -0700 (PDT) Received: from warrior.mgc.peachnet.edu (warrior.mgc.peachnet.edu [168.16.224.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA07588 for ; Mon, 11 Oct 1999 06:28:02 -0600 (MDT) Received: from mlnt [168.16.224.2] by warrior.mgc.peachnet.edu (SMTPD32-5.05) id A7584970082; Mon, 11 Oct 1999 08:26:00 -0400 X-Sender: mlovett@warrior.mgc.peachnet.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Mon, 11 Oct 1999 08:26:14 -0400 To: ipng@sunroof.eng.sun.com From: "Melissa L. Lovett" Subject: Fwd: Re: My InternetWeek op-ed column on IPv6 privacy issues Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: <199910110826281.SM00258@mlnt> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >X-Sender: frezza@pop3.psinet.com >X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 >Date: Sun, 10 Oct 1999 18:27:39 -0400 >To: Address List Suppressed >From: Bill Frezza >Subject: Re: My InternetWeek op-ed column on IPv6 privacy issues >X-RCPT-TO: > >Gentle readers, > >Thank you for your feedback on my recent column "Where's All The Outrage >About The IPv6 Privacy Threat" > >http://www.internetwk.com/columns/frezz100499.htm > >Normally I respond to every letter I receive, but the volume of mail on >this one broke all records so I'm afraid I have to send out a group note. >(It seems that peeved IETF geeks are even more vociferous than peeved >Mac-heads. :) > >Let me, in particular, address some of the comments from the folks who >insist that there is no privacy problem with IPv6 or that the problem is >identical with IPv4 or that the problem has already been solved by the IETF >or that the use of EUI-64 addressing is optional and not mandatory, >therefore there's no problem. (I do not intend to reply to the folks who >just plain don't care about privacy as this is a philosophical issue beyond >the scope of this note. As for readers who don't like my inflammatory >writing style, feel free not to read my column. I write op-eds, not news >articles.) > >1) Yes, IPv4 has its own privacy problems. In fact, any time one uses a >static or long-lived IP address, the possibility exists for abusive >systematic surveillance. The fact that a central registry of addresses does >or does not exist has no bearing on the potential threat as such a data >base can be built over time, particularly for individuals or groups that >have been specifically targeted. In addition, countries like China or >Singapore could easily require registration. Why give them the tools in the >first place? > >2) Yes, dynamic assignment of IP addresses for dial-up users as well as >Network Address Translation (NAT) helps mitigate (though does not >eliminate) the privacy problem. As we move towards an "always connected" >Internet, with more and more users communicating via Cable Modems or DSL, >more IP addresses will become long lived, hence the problem will get worse. > >3) It's too late to change IPv4 while it is not too late to change IPv6. My >column was intended as a call to action to get the IETF off it's duff. A >fault in my column is that I did not specifically describe proposals being >circulated to address the issue, one of which is attached below. Mea culpa, >and my apologies to the good guys for ignoring their efforts. May the force >be with you. > >4) Be that as it may, draft-ietf-ipngwg-addrconf-privacy-00.txt is just a >proposal. It has not been and may not be adopted. Absent further action, it >will go away. If it is adopted, it may or may not be implemented by major >vendors, especially if the final standard offers a Chinese menu of choices. > >5) Note that the proposal ACKNOWLEDGES THE PROBLEM. In addition it points >out that > >> The desires of protecting individual privacy vs. the desire to >> effectively maintain and debug a network can conflict with each >> other. > >The same can be said across the board for many aspects of law enforcement >in a society that values liberty. Just think how much safer the streets >would be if we all walked around with electronic radio ID collars >registering our movements. Fortunately, we have chosen not to construct >such a society (although if you follow the development of the CALEA laws, >this is not for want of the FBI trying). > >6) The solutions proposed in draft-ietf-ipngwg-addrconf-privacy-00.txt >cause a a major problem with one of the other goals of IPv6 > >> The IPv6 addressing architecture goes to great lengths to ensure that >> interface identifiers are globally unique. During the IPng >> discussions of the GSE proposal [GSE], it was felt that keeping >> interface identifiers globally unique in practice might prove useful >> to future transport protocols. Usage of the algorithms in this >> document would eliminate that future flexibility. > >The random assignment algorithms look very promising. I hope they are >adopted, but no one knows yet how this conflict is going to be resolved. > >7) At the end of the day, what matters to the average netizen is not the >menu of possible alternatives described in IETF standards, but the actual >default implementation in popular products, e.g. Windows. Just because an >educated and motivated geek can get into the plumbing of his machine and >find a way to solve his own privacy problem doesn't mean the problem has >been solved for the bulk of average users. If the folks at Microsoft don't >properly address this in their future products, I can positively, >absolutely guarantee that it will blow up in their face. > >8) Readers who are interested in registering their concerns should contact >the CDT at www.CDT.org. I got a very nice note from them indicating that >they are now wading into the issue. One hopes that EPIC and the EFF will >follow suit. > >Cheers, > >Bill Frezza >InternetWeek >frezza@alum.MIT.edu > >PS Special thanks to Scott Bradner and Mike O'Dell for helping me >understand some of the technical nuances of this issue that I had >previously misunderstood. Notwithstanding, I stand by my column and hope >all you geeks do something about it. The opinions above are my own. > >------------ > >INTERNET-DRAFT Thomas Narten > IBM > June 1999 > > Privacy Extensions for Stateless Address Autoconfiguration in IPv6 > > > >Status of this Memo > > This document is an Internet-Draft and is in full conformance with > all provisions of Section 10 of RFC2026. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. Note that > other groups may also distribute working documents as Internet- > Drafts. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet- Drafts as reference > material or to cite them other than as "work in progress." > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt > > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > >Abstract > > Nodes use IPv6 stateless address autoconfiguration to generate > addresses without the necessity of a DHCP server. Addresses are > formed by combining network prefixes with a constant interface > identifier derived from the interface's IEEE Indentifier. This > document describes an optional extension to IPv6 stateless address > autoconfiguration that results in a node generating addresses from an > interface identifier that changes over time. Changing the interface > identifier over time makes it more difficult for eavesdroppers and > other information collectors to identify when different addresses > used in different transactions actually correspond to the same node. > >draft-ietf-ipngwg-addrconf-privacy-00.txt [Page 1] > >INTERNET-DRAFT June 24, 1999 > > Contents > > Status of this Memo.......................................... 1 > > 1. Introduction............................................. 2 > > 2. Background............................................... 3 > > 3. Protocol Description..................................... 5 > > 4. Implications of Changing Interface Identifiers........... 7 > > 5. Open Issues and Future Work.............................. 7 > > 6. Security Considerations.................................. 8 > > 7. References............................................... 8 > > 8. Authors' Addresses....................................... 9 > >1. Introduction > > Stateless address autoconfiguration [ADDRCONF] defines how an IPv6 > node generates addresses without the need for a DHCP server. Network > interfaces typically come with an embedded IEEE Identifier (i.e., a > link-layer MAC address), and stateless address autoconfiguration uses > the IEEE identifier to generate a 64-bit interface identifier > [ADDRARCH]. By design, the interface identifier will typically be > globally unique. The interface identifier is in turn appended to a > prefix to form a 128-bit IPv6 address. All nodes use this technique > to generate link-local addresses for their attached interfaces. > Additional addresses, including site-local and global-scope > addresses, are then created by combining prefixes advertised in > Router Advertisements via Neighbor Discovery [DISCOVERY] with the > interface identifier. > > As mobile devices (e.g., laptops, PDAs, etc.) move topologically, > they form new addresses for their current topological point of > attachment. While the node's address changes as it moves, however, > the interface identifier contained within the address remains the > same. Because the interface identifier associated with a node can > potentially remain fixed for a long period of time (e.g., months or > years) concern has been voiced that the interface identifier could in > some cases be used to track the movement and usage of a particular > machine. For example, a server that logs the source addresses of > incoming connections would simultaneously collect identical > information keyed on the interface id, allowing one to correlate > >draft-ietf-ipngwg-addrconf-privacy-00.txt [Page 2] > >INTERNET-DRAFT June 24, 1999 > > activities based on interface identifiers in addition to addresses. > This is of particular concern with the expected proliferation of > next-generation network-connected devices (e.g, PDAs, cell phones, > etc.) in which large numbers of devices are in practice associated > with a single user. Thus, the interface identifier embedded within an > address could be used to track activities of an individual. > > This document discusses concerns associated with the embedding of > interface identifiers within IPv6 addresses and describes optional > extensions to stateless address autoconfiguration that can help > mitigate those concerns in environments where such concerns are > significant. > >2. Background > > This section discusses the problem in more detail and provides > context for evaluating the significance of the concerns in specific > environments and makes comparisons with existing practices. > >2.1. Extended Use of the Same Identifier > > The use of a non-changing interface identifier to form addresses is a > specific instance of the more general case where a constant > identifier is reused over an extended period of time and in multiple > independent activities. Anytime the same identifier is used in > multiple contexts, it becomes possible for that identifier to be used > to correlate seemingly unrelated activity. For example, a network > sniffer placed strategically on a link across which all traffic > to/from a particular host crosses could keep track of which > destinations a node communicated with and at what times. Such > information can in some cases be used to infer things, such as what > hours an employee was active, when someone is at home, etc. > > One of the requirements for correlating seemingly unrelated > activities is the use (and reuse) of an identifier that is > recognizable over time within different contexts. IP addresses > provide one obvious example, but there are more. Many nodes also have > DNS names associated with their addresses, in which case the DNS name > serves as a similar identifier. Although the DNS name associated with > an address is more work to obtain (it may require a DNS query) the > information is often readily available. In such cases, changing the > address on a machine over time would do little to address the concern > raised in this document, as the DNS name would become the correlating > identifier. > > The use of a constant identifier within an address is of special > >draft-ietf-ipngwg-addrconf-privacy-00.txt [Page 3] > >INTERNET-DRAFT June 24, 1999 > > concern because addresses are a fundamental requirement of > communication and cannot easily be hidden from eavesdroppers and > other parties. Even when higher layers encrypt their payloads, > addresses in packet headers appear in the clear. Consequently, if a > mobile host (e.g., laptop) accessed the network from several > different locations, an eavesdropper might be able to track the > movement of that mobile host from place to place, even if the upper > layer payloads were encrypted [SERIALNUM]. > >2.2. Not a New Issue > > Although the topic of this document may at first appear to be an > issue new to IPv6, similar issues already exist in today's Internet > already. That is, addresses used in today's Internet are often > constant in practice for extended periods of time. In many sites, > addresses are assigned statically; such addresses typically change > infrequently. However, many sites are moving away from static > allocation to dynamic allocation via DHCP. In theory, the address a > client gets via DHCP can change over time, but in practice servers > return the same address to the same client (unless addresses are in > such short supply that they are reused immediately by a different > node when they become free). Thus, although many sites use DHCP, > clients end up using the same address for months at a time. > > Nodes that need a (non-changing) DNS name generally have static > addresses assigned to them to simplify the configuration of DNS > servers. Although Dynamic DNS [DDNS] can be used to update the DNS > dynamically, it is not widely deployed today. In addition, changing > an address but keeping the same DNS name does not really address the > underlying concern, since the DNS name becomes a non-changing > identifier. Servers generally require a DNS name (so clients can > connect to them), and clients often do as well (e.g., some servers > refuse to speak to a client whose address cannot be mapped into a DNS > name that also maps back into the same address). > > Many network services require that the client authenticate itself to > the server before gaining access to a resource. The authentication > step binds the activity (e.g., TCP connection) to a specific entity > (e.g., an end user). In such cases, a server already has the ability > to track usage by an individual, independent of the address they > happen to use. Indeed, such tracking is an important part of > accounting. > > Web browsers and servers typically exchange "cookies" with each > other. Such cookies allow web servers to correlate a current activity > with a previous activity. One common usage is to send back targeted > advertising to a browser by noting that a transaction that it is > >draft-ietf-ipngwg-addrconf-privacy-00.txt [Page 4] > >INTERNET-DRAFT June 24, 1999 > > performing was started by an entity that previously requested > information that had the side-effect of indicating the interest of > the querier. > >2.3. Possible Approaches > > One way to avoid some of the problems discussed above would be to use > DHCP for obtaining addresses. With DHCP, the DHCP server could > arrange to hand out addresses that change over time. > > Another approach, one compatible with the stateless address > autoconfiguration architecture would be to change the interface id > portion of an address over time. For example, upon each system > restart, select a new interface identifier different from the ones > used previously. Changing the interface identifier makes it more > difficult to look at the IP addresses in independent transactions and > identify which ones actually correspond to the same node. > > In order to make it difficult to make educated guesses as to whether > two different interface identifiers belong to the same node, the > algorithm for generating alternate identifiers must include input > that has an unpredictable component from the perspective of the > outside entity's collecting information. Picking identifiers from a > pseudorandom sequence suffices, so long as the specific sequence > cannot be determined by an outsider examining just the identifiers > that appear in addresses. This document proposes the use of an MD5 > hash, using a per-interface "key" that varies from one interface to > another. Specifically, we use the interface identifier generated > using the normal procedure [ADDRARCH] as the key. > >3. Protocol Description > > The goal of this section is to define procedures that: > > 1) Result in a different interface identifier being generated at each > system restart or attachment to a network. > > 2) Produce a sequence of interface identifiers that appear to be > random in the sense that it is difficult for an outside observer > to predict a future identifier based on a current one and it is > difficult to determine previous identifiers knowing only the > present one. > > We describe two approaches. The first assumes the presence of stable > storage that can be used to record state history for use as input > into the next iteration of the algorithm, i.e., after a system > >draft-ietf-ipngwg-addrconf-privacy-00.txt [Page 5] > >INTERNET-DRAFT June 24, 1999 > > restart. A second approach addresses the case where stable storage is > unavailable and the interface identifier must be generated at random. > >3.1. When Stable Storage is Present > > The following algorithm assumes the presence of a 64-bit "history > value" that is used as input in generating an interface identifier. > The very first time the system boots (i.e., out-of-the-box), any > value can be used including all zeros. Whenever a new interface > identifier is generated, its value is saved in the seed for the next > iteration of the process. > > Section 5.3 of [ADDRCONF] describes the steps for generating a link- > local address when an interface becomes enabled. This document > modifies that step in the following way. Rather than use interface > identifiers generated as described in [ADDRARCH], the identifier is > generated as follows: > > 1) Take the history value from the previous iteration (or 0 if there > is no previous value) and append to it the interface identifier > generated as described in [ADDRARCH]. > 2) Compute the MD5 message digest [MD5] over the quantity created in > step 1). > 3) Take the left-most 64-bits of the MD5 digest and set bit 6 (the > left-most bit is numbered 0) to zero. This creates an interface > identifier with the universal/local bit indicating local > significance only. Use the resultant identifier for generating > addresses as outlined in [ADDRCONF]. That is, use the interface > identifier to generate a link-local and other appropriate > addresses. > 4) Save the interface identifier created in step 3) in stable storage > as the history value to be used in the next iteration of the > algorithm. > > MD5 was chosen for convenience, not because of strict requirements. > IPv6 nodes are already required to implement MD5 as part of IPsec > [IPSEC], thus the code will already be present on IPv6 machines. > >3.2. In The Absence of Stable Storage > > In the absence of stable storage, no history information will be > available to generate a pseudo-random sequence of interface > identifiers. Consequently, identifiers will need to be generated at > random. A number of techniques might be appropriate. Consult [RANDOM] > for suggestions on good sources for obtaining random numbers. Note > that even though a machine may not have stable storage for storing > >draft-ietf-ipngwg-addrconf-privacy-00.txt [Page 6] > >INTERNET-DRAFT June 24, 1999 > > the previously using interface identifier, they will in many cases > have configuration information that differs from one machine to > another (e.g., user identity, security keys, etc.). One approach to > generating random interface identifiers in such cases is to use the > configuration information to generate some data bits (which may be > remain constant for the life of the machine, but will vary from one > machine to another), append some random data and compute the MD5 > digest as before. The remaining details for generating addresses > would be analogous to those of the previous section. > >4. Implications of Changing Interface Identifiers > > The IPv6 addressing architecture goes to great lengths to ensure that > interface identifiers are globally unique. During the IPng > discussions of the GSE proposal [GSE], it was felt that keeping > interface identifiers globally unique in practice might prove useful > to future transport protocols. Usage of the algorithms in this > document would eliminate that future flexibility. > > The desires of protecting individual privacy vs. the desire to > effectively maintain and debug a network can conflict with each > other. Having clients use addresses that change over time will make > it more difficult to track down and isolate operational problems. For > example, when looking at packet traces, it could become more > difficult to determine whether one is seeing behavior caused by a > single errant machine, or by a number of them. > >5. Open Issues and Future Work > > This document specifies that a node generate a new interface > identifier each time it autoconfigures an interface. The same > identifier is used to generate all addresses, including link-local, > site-local and global. However, the concerns this document addresses > are most likely relevant only to global-scope addresses. Thus, it may > make sense for a node to have two interface identifiers, the standard > one [ADDRCONF] used for link-local and site-local addresses, with a > changing one used only for global-scope addresses. This would appear > to require only small changes from the current specification. > > In some cases, one could imagine the need to change an address more > frequently than upon reboot or movement to a new location. For > example, for machines that do not restart for months at time, one > might change addresses every few days or weeks. In extreme cases, one > might even want to change addresses upon the initiation of each new > TCP connection. Doing frequent changes would appear to add > significant issues and possible implementation complications. For > >draft-ietf-ipngwg-addrconf-privacy-00.txt [Page 7] > >INTERNET-DRAFT June 24, 1999 > > example, an implementation might need to support a significant number > of address on an interface simultaneously. An implementation would > also need to keep track of which addresses were being used so as to > be able to stop using an address once no upper layer protocols are > using it (but not before). This is in contrast to current approaches > where addresses are removed from an interface when they become > invalid [ADDRCONF], independent of whether or not upper layer > protocols are still using them. > > Some machines server as both clients and servers. In such cases, the > server would need a DNS name. Whether the address stays fixed or > changes doesn't matter since the DNS name remains constant. > Simultaneously, when acting as a client (e.g., initiating > communication) it may want to vary the address it uses. In such > environments, one might need multiple addresses. Source address > selection rules would need to take into account the policy aspects of > which addresses would be acceptable for use when initiating > communication. > >6. Security Considerations > > The motivation for this document stems from privacy concerns for > individuals. This document does not appear to add any security issues > beyond those already associated with stateless address > autoconfiguration [ADDRCONF]. > >7. References > > [ADDRARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing > Architecture", RFC 2373, July 1998. > > [ADDRCONF] Thomson, S. and T. Narten, "IPv6 Address > Autoconfiguration", RFC 2462, December 1998. > > [DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, > March 1997. > > [DDNS] Vixie et. al., "Dynamic Updates in the Domain Name System (DNS > UPDATE)", RFC 2136, April 1997. > > [DISCOVERY] Narten, T., Nordmark, E. and W. Simpson, "Neighbor > Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. > > [GSE-ANALYSIS] Crawford et. al., "Separating Identifiers and Locators > in Addresses: An Analysis of the GSE Proposal for IPv6 ", > draft-ietf-ipngwg-esd-analysis-04.txt. > >draft-ietf-ipngwg-addrconf-privacy-00.txt [Page 8] > >INTERNET-DRAFT June 24, 1999 > > [IPSEC] Kent, S., Atkinson, R., "Security Architecture for the > Internet Protocol", RFC 2401, November 1998. > > [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April > 1992. > > [SERIALNUM] Moore, K., "Privacy Considerations for the Use of > Hardware Serial Numbers in End-to-End Network Protocols", > draft-iesg-serno-privacy-00.txt. > >8. Authors' Addresses > > Thomas Narten > IBM Corporation > P.O. Box 12195 > Research Triangle Park, NC 27709-2195 > USA > > Phone: +1 919 254 7798 > EMail: narten@raleigh.ibm.com > >draft-ietf-ipngwg-addrconf-privacy-00.txt [Page 9] > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 11 12:11:28 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) id d9BJ4HM15452 for ipng-dist; Mon, 11 Oct 1999 12:04:17 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) with ESMTP id d9BJ3aR15442 for ; Mon, 11 Oct 1999 12:03:37 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA01405 for ; Mon, 11 Oct 1999 12:02:44 -0700 (PDT) Received: from ib.rc.vix.com (ib.rc.vix.com [204.152.187.22]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA13834 for ; Mon, 11 Oct 1999 13:02:43 -0600 (MDT) Received: from bb.rc.vix.com (bb.rc.vix.com [204.152.187.11]) by ib.rc.vix.com (8.9.1/8.9.1) via ESMTP id MAA29276; Mon, 11 Oct 1999 12:02:42 -0700 (PDT) env-from (Bob_Halley@iengines.net) Received: (from halley@localhost) by bb.rc.vix.com (8.9.1/8.9.1) id MAA09703; Mon, 11 Oct 1999 12:02:42 -0700 (PDT) env-from (Bob_Halley@iengines.net) To: Jim Bound Cc: ipng@sunroof.eng.sun.com, namedroppers@internic.net Subject: Re: draft-ietf-ipngwg-dns-lookups-04.txt References: <199910050340.XAA0000006071@quarry.zk3.dec.com> From: Bob Halley Date: 11 Oct 1999 12:02:42 -0700 In-Reply-To: Jim Bound's message of "Mon, 04 Oct 1999 23:40:04 -0400" Message-ID: Lines: 40 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim Bound writes: > I don't think we should mix A records in the query. Just AAAA or A6. It doesn't make sense to me to worry about saving roundtrips in the AAAA to A6 transition and not worry about roundtrips spent co-existing with the IPv4 Internet. Nevertheless, I remain opposed to a meta query at this time because of the problems interoperating with existing implementations and with negative caching which I described in my previous message. I'm not saying these problems can't be resolved with further changes to the DNS standards, but I don't think now is the time to do it. I think we're better off getting DNS lookups out of draft state ASAP. I propose the following changes to draft-ietf-ipngwg-dns-lookups-04: Eliminate type A and AAAA additional section processing for A6 records. This additional section processing doesn't save any effort unless you query for type A6 first, and the A/AAAA records are present. Because this is additional data, you can't assume that the absence of A or AAAA in a reply implies their nonexistence, so you have to query for them if they're not in the reply. Also, I think many resolvers would want to query for type A first, since I expect the majority of hosts will be IPv4-only for some time. Add guidance that resolver and nameserver implementations SHOULD allow the types, and order, of address queries to be specified. E.g. query for A, A6, and then AAAA. A resolver could choose to send the queries in parallel or in series as it saw fit. E.g. Send out A and A6 in parallel, and if there are no A6 records, send out an AAAA query. I propose that support for an address metaquery / multiple questions, and the negative caching changes that go along with it, be addressed in a separate future draft. I think any such support will have to be done as an EDNS version. /Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 11 13:47:09 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) id d9BKerV15563 for ipng-dist; Mon, 11 Oct 1999 13:40:53 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) with ESMTP id d9BKeAR15556 for ; Mon, 11 Oct 1999 13:40:11 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAB19138 for ; Mon, 11 Oct 1999 13:39:21 -0700 (PDT) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA22709 for ; Mon, 11 Oct 1999 14:39:13 -0600 (MDT) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id PAA06136; Mon, 11 Oct 1999 15:38:41 -0500 (CDT) Message-Id: <199910112038.PAA06136@gungnir.fnal.gov> To: ipng@sunroof.eng.sun.com, namedroppers@internic.net From: "Matt Crawford" Subject: Re: draft-ietf-ipngwg-dns-lookups-04.txt In-reply-to: Your message of Mon, 11 Oct 1999 12:02:42 PDT. Date: Mon, 11 Oct 1999 15:38:41 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, Bob, Erik, and all other interested parties, I hope to distill the differing viewpoints into consensus soon, if possible. I think we may fairly say that every preference put forth so far entails some cost; there's always a trade-off to be made. I propose that we deliberately sacrifice efficiency (in the form of possible extra DNS round-trips) for correctness (in the form of relying on long-tested semantics for all operations). Leave efficiency improvements for another, more general mechanism. My perception of a spec. derived from this position is: No new Qtype. No type A or AAAA additional processing for A6 queries. (RFC 1886 is already implemented and does not specify additional "A" data for AAAA queries.) "Recursive" additional processing for the DNS name (if any) found in the RDATA of the A6 records in the answer. All old query types that now do type A additional processing redefined to do A, A6, AAAA, in that order. Matt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 11 13:47:12 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) id d9BKhbw15572 for ipng-dist; Mon, 11 Oct 1999 13:43:37 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) with ESMTP id d9BKhSR15565 for ; Mon, 11 Oct 1999 13:43:29 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA09643 for ; Mon, 11 Oct 1999 13:42:42 -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 OAA24261 for ; Mon, 11 Oct 1999 14:42:41 -0600 (MDT) Received: from new (Ihinden-3.iprg.nokia.com [205.226.22.76]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with ESMTP id NAA27548; Mon, 11 Oct 1999 13:42:40 -0700 (PDT) Message-Id: <4.2.0.58.19991011133744.00b3c6b0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Mon, 11 Oct 1999 13:41:55 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: Slides from Tokyo IPng Meeting Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Presentations (in pdf) from the Tokyo IPng meeting are now available on: http://playground.sun.com/pub/ipng/html/meetings.html It includes the chairs summary and action items. The minutes are being edited and should be available later this week. Bob p.s. If you gave a presentation at the meeting and have not sent me your slides, please do. If you sent them and do they do not appear please resend them. I had some email problems when I got back and may have lost them. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 11 16:48:19 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) id d9BNfn215817 for ipng-dist; Mon, 11 Oct 1999 16:41:49 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) with ESMTP id d9BNfWR15802 for ; Mon, 11 Oct 1999 16:41:34 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id QAA02999 for ; Mon, 11 Oct 1999 16:41:32 -0700 (PDT) Received: from ib.rc.vix.com (ib.rc.vix.com [204.152.187.22]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA03876 for ; Mon, 11 Oct 1999 17:41:32 -0600 (MDT) Received: from bb.rc.vix.com (bb.rc.vix.com [204.152.187.11]) by ib.rc.vix.com (8.9.1/8.9.1) via ESMTP id QAA01891; Mon, 11 Oct 1999 16:41:31 -0700 (PDT) env-from (Bob_Halley@iengines.net) Received: (from halley@localhost) by bb.rc.vix.com (8.9.1/8.9.1) id QAA09237; Mon, 11 Oct 1999 16:41:31 -0700 (PDT) env-from (Bob_Halley@iengines.net) To: "Matt Crawford" Cc: ipng@sunroof.eng.sun.com, namedroppers@internic.net Subject: Re: draft-ietf-ipngwg-dns-lookups-04.txt References: <199910112038.PAA06136@gungnir.fnal.gov> From: Bob Halley Date: 11 Oct 1999 16:41:31 -0700 In-Reply-To: "Matt Crawford"'s message of "Mon, 11 Oct 1999 15:38:41 -0500" Message-ID: Lines: 15 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Matt Crawford" writes: > No new Qtype. No type A or AAAA additional processing for A6 > queries. (RFC 1886 is already implemented and does not specify > additional "A" data for AAAA queries.) "Recursive" additional > processing for the DNS name (if any) found in the RDATA of the A6 > records in the answer. All old query types that now do type A > additional processing redefined to do A, A6, AAAA, in that order. Sounds good to me. BIND 9 does additional data section processing in the order you specified, but I don't think that the order really matters and would be inclined not to specify it in the RFC. /Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 11 16:48:28 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) id d9BNfri15818 for ipng-dist; Mon, 11 Oct 1999 16:41:53 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.86.31] (may be forged)) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) with ESMTP id d9BNfbR15810 for ; Mon, 11 Oct 1999 16:41:37 -0700 (PDT) Received: from vallejo (vallejo.Eng.Sun.COM [129.146.86.131]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id QAA599053; Mon, 11 Oct 1999 16:41:28 -0700 (PDT) Date: Mon, 11 Oct 1999 16:41:28 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: draft-ietf-ipngwg-dns-lookups-04.txt To: Matt Crawford Cc: ipng@sunroof.eng.sun.com, namedroppers@internic.net In-Reply-To: "Your message with ID" <199910112038.PAA06136@gungnir.fnal.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > queries. (RFC 1886 is already implemented and does not specify > additional "A" data for AAAA queries.) "Recursive" additional > processing for the DNS name (if any) found in the RDATA of the A6 > records in the answer. All old query types that now do type A > additional processing redefined to do A, A6, AAAA, in that order. I think it would also be useful to try to nail down a default order that the resolver will ask for IPv6 address records and whether or not implementaions should have knobs to adjust that order. (The issue of ordering between A and AAAA/A6 records is already discussed in RFC 1933 if I'm not mistaken.) 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 11 19:59:21 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) id d9C2rKd16044 for ipng-dist; Mon, 11 Oct 1999 19:53:21 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) with ESMTP id d9C2rAR16037 for ; Mon, 11 Oct 1999 19:53:12 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id TAA26567 for ; Mon, 11 Oct 1999 19:53:10 -0700 (PDT) Received: from mailext04.compaq.com (mailext04.compaq.com [207.18.199.42]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA29800 for ; Mon, 11 Oct 1999 19:53:10 -0700 (PDT) Received: from mailint12.im.hou.compaq.com (mailint12.compaq.com [207.18.199.190]) by mailext04.compaq.com (Postfix) with ESMTP id E6F09104B9E; Mon, 11 Oct 1999 21:53:09 -0500 (CDT) Received: by mailint12.im.hou.compaq.com (Postfix, from userid 60001) id 4EE254FB09; Mon, 11 Oct 1999 21:52:59 -0500 (CDT) Received: from mailint12.im.hou.compaq.com (localhost [127.0.0.1]) by mailint12.im.hou.compaq.com (Postfix) with ESMTP id 4A0064C902; Mon, 11 Oct 1999 21:52:59 -0500 (CDT) Received: from quarry.zk3.dec.com([not looked up]) (peer bryquarry.zk3.dec.com[16.141.40.15]) by mailint12.im.hou.compaq.com with ESMTP id rcv004307; Mon, 11 Oct 1999 21:52:58 -0500 (CDT) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id WAA0000031538; Mon, 11 Oct 1999 22:53:07 -0400 (EDT) From: Jim Bound Message-Id: <199910120253.WAA0000031538@quarry.zk3.dec.com> To: "Matt Crawford" Cc: ipng@sunroof.eng.sun.com, namedroppers@internic.net Subject: Re: draft-ietf-ipngwg-dns-lookups-04.txt In-reply-to: Your message of "Mon, 11 Oct 1999 15:38:41 CDT." <199910112038.PAA06136@gungnir.fnal.gov> Date: Mon, 11 Oct 1999 22:53:07 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Matt, I agree with your logic and as Bob stated leave the nextgen solution to EDNS as it evolves. >My perception of a spec. derived from this position is: No new Qtype. No type A or AAAA additional processing for A6 queries. (RFC 1886 is already implemented and does not specify additional "A" data for AAAA queries.) "Recursive" additional processing for the DNS name (if any) found in the RDATA of the A6 records in the answer. All old query types that now do type A additional processing redefined to do A, A6, AAAA, in that order. This sounds doable and will work and we can ship it moderately quick (like that eh!). Would be good to provide some order to which types are searched for given first type requested (as the API defines the type initially and almost absolutely with the new flags param in getipnodebyname). thanks /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 13 15:31:25 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) id d9DMRB617934 for ipng-dist; Wed, 13 Oct 1999 15:27:11 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) with ESMTP id d9DMQiR17881 for ; Wed, 13 Oct 1999 15:26:44 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.1b+Sun/8.9.1) id KAA15550 for ipng@sunroof.eng.sun.com; Wed, 13 Oct 1999 10:25:23 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) with ESMTP id d9AMKUR14515 for ; Sun, 10 Oct 1999 15:20:31 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id PAA01807; Sun, 10 Oct 1999 15:20:29 -0700 (PDT) Received: from smtp1.interramp.com (smtp1.interramp.com [38.8.45.2]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA03955; Sun, 10 Oct 1999 15:20:28 -0700 (PDT) Received: from [38.30.238.146] (helo=bill) by smtp1.interramp.com with smtp (Exim 1.90 #1) id 11aRGz-0006Ke-00; Sun, 10 Oct 1999 18:16:57 -0400 Message-Id: <4.1.19991010162135.0096bb30@pop3.psinet.com> Message-Id: <4.1.19991010162135.0096bb30@pop3.psinet.com> X-Sender: frezza@pop3.psinet.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Sun, 10 Oct 1999 18:10:31 -0400 To: address list suppressed From: Bill Frezza Subject: Re: My InternetWeek op-ed column on IPv6 privacy issues Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Gentle readers, Thank you for your feedback on my recent column "Where's All The Outrage About The IPv6 Privacy Threat" http://www.internetwk.com/columns/frezz100499.htm Normally I respond to every letter I receive, but the volume of mail on this one broke all records so I'm afraid I have to send out a group note. (It seems that peeved IETF geeks are even more vociferous than peeved Mac-heads. :) Let me, in particular, address some of the comments from the folks who insist that there is no privacy problem with IPv6 or that the problem is identical with IPv4 or that the problem has already been solved by the IETF or that the use of EUI-64 addressing is optional and not mandatory, therefore there's no problem. (I do not intend to reply to the folks who just plain don't care about privacy as this is a philosophical issue beyond the scope of this note. As for readers who don't like my inflammatory writing style, feel free not to read my column. I write op-eds, not news articles.) 1) Yes, IPv4 has its own privacy problems. In fact, any time one uses a static or long-lived IP address, the possibility exists for abusive systematic surveillance. The fact that a central registry of addresses does or does not exist has no bearing on the potential threat as such a data base can be built over time, particularly for individuals or groups that have been specifically targeted. In addition, countries like China or Singapore could easily require registration. Why give them the tools in the first place? 2) Yes, dynamic assignment of IP addresses for dial-up users as well as Network Address Translation (NAT) helps mitigate (though does not eliminate) the privacy problem. As we move towards an "always connected" Internet, with more and more users communicating via Cable Modems or DSL, more IP addresses will become long lived, hence the problem will get worse. 3) It's too late to change IPv4 while it is not too late to change IPv6. My column was intended as a call to action to get the IETF off it's duff. A fault in my column is that I did not specifically describe proposals being circulated to address the issue, one of which is attached below. Mea culpa, and my apologies to the good guys for ignoring their efforts. May the force be with you. 4) Be that as it may, draft-ietf-ipngwg-addrconf-privacy-00.txt is just a proposal. It has not been and may not be adopted. Absent further action, it will go away. If it is adopted, it may or may not be implemented by major vendors, especially if the final standard offers a Chinese menu of choices. 5) Note that the proposal ACKNOWLEDGES THE PROBLEM. In addition it points out that > The desires of protecting individual privacy vs. the desire to > effectively maintain and debug a network can conflict with each > other. The same can be said across the board for many aspects of law enforcement in a society that values liberty. Just think how much safer the streets would be if we all walked around with electronic radio ID collars registering our movements. Fortunately, we have chosen not to construct such a society (although if you follow the development of the CALEA laws, this is not for want of the FBI trying). 6) The solutions proposed in draft-ietf-ipngwg-addrconf-privacy-00.txt cause a a major problem with one of the other goals of IPv6 > The IPv6 addressing architecture goes to great lengths to ensure that > interface identifiers are globally unique. During the IPng > discussions of the GSE proposal [GSE], it was felt that keeping > interface identifiers globally unique in practice might prove useful > to future transport protocols. Usage of the algorithms in this > document would eliminate that future flexibility. The random assignment algorithms look very promising. I hope they are adopted, but no one knows yet how this conflict is going to be resolved. 7) At the end of the day, what matters to the average netizen is not the menu of possible alternatives described in IETF standards, but the actual default implementation in popular products, e.g. Windows. Just because an educated and motivated geek can get into the plumbing of his machine and find a way to solve his own privacy problem doesn't mean the problem has been solved for the bulk of average users. If the folks at Microsoft don't properly address this in their future products, I can positively, absolutely guarantee that it will blow up in their face. 8) Readers who are interested in registering their concerns should contact the CDT at www.CDT.org. I got a very nice note from them indicating that they are now wading into the issue. One hopes that EPIC and the EFF will follow suit. Cheers, Bill Frezza InternetWeek frezza@alum.MIT.edu PS Special thanks to Scott Bradner and Mike O'Dell for helping me understand some of the technical nuances of this issue that I had previously misunderstood. Notwithstanding, I stand by my column and hope all you geeks do something about it. The opinions above are my own. ------------ INTERNET-DRAFT Thomas Narten IBM June 1999 Privacy Extensions for Stateless Address Autoconfiguration in IPv6 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract Nodes use IPv6 stateless address autoconfiguration to generate addresses without the necessity of a DHCP server. Addresses are formed by combining network prefixes with a constant interface identifier derived from the interface's IEEE Indentifier. This document describes an optional extension to IPv6 stateless address autoconfiguration that results in a node generating addresses from an interface identifier that changes over time. Changing the interface identifier over time makes it more difficult for eavesdroppers and other information collectors to identify when different addresses used in different transactions actually correspond to the same node. draft-ietf-ipngwg-addrconf-privacy-00.txt [Page 1] INTERNET-DRAFT June 24, 1999 Contents Status of this Memo.......................................... 1 1. Introduction............................................. 2 2. Background............................................... 3 3. Protocol Description..................................... 5 4. Implications of Changing Interface Identifiers........... 7 5. Open Issues and Future Work.............................. 7 6. Security Considerations.................................. 8 7. References............................................... 8 8. Authors' Addresses....................................... 9 1. Introduction Stateless address autoconfiguration [ADDRCONF] defines how an IPv6 node generates addresses without the need for a DHCP server. Network interfaces typically come with an embedded IEEE Identifier (i.e., a link-layer MAC address), and stateless address autoconfiguration uses the IEEE identifier to generate a 64-bit interface identifier [ADDRARCH]. By design, the interface identifier will typically be globally unique. The interface identifier is in turn appended to a prefix to form a 128-bit IPv6 address. All nodes use this technique to generate link-local addresses for their attached interfaces. Additional addresses, including site-local and global-scope addresses, are then created by combining prefixes advertised in Router Advertisements via Neighbor Discovery [DISCOVERY] with the interface identifier. As mobile devices (e.g., laptops, PDAs, etc.) move topologically, they form new addresses for their current topological point of attachment. While the node's address changes as it moves, however, the interface identifier contained within the address remains the same. Because the interface identifier associated with a node can potentially remain fixed for a long period of time (e.g., months or years) concern has been voiced that the interface identifier could in some cases be used to track the movement and usage of a particular machine. For example, a server that logs the source addresses of incoming connections would simultaneously collect identical information keyed on the interface id, allowing one to correlate draft-ietf-ipngwg-addrconf-privacy-00.txt [Page 2] INTERNET-DRAFT June 24, 1999 activities based on interface identifiers in addition to addresses. This is of particular concern with the expected proliferation of next-generation network-connected devices (e.g, PDAs, cell phones, etc.) in which large numbers of devices are in practice associated with a single user. Thus, the interface identifier embedded within an address could be used to track activities of an individual. This document discusses concerns associated with the embedding of interface identifiers within IPv6 addresses and describes optional extensions to stateless address autoconfiguration that can help mitigate those concerns in environments where such concerns are significant. 2. Background This section discusses the problem in more detail and provides context for evaluating the significance of the concerns in specific environments and makes comparisons with existing practices. 2.1. Extended Use of the Same Identifier The use of a non-changing interface identifier to form addresses is a specific instance of the more general case where a constant identifier is reused over an extended period of time and in multiple independent activities. Anytime the same identifier is used in multiple contexts, it becomes possible for that identifier to be used to correlate seemingly unrelated activity. For example, a network sniffer placed strategically on a link across which all traffic to/from a particular host crosses could keep track of which destinations a node communicated with and at what times. Such information can in some cases be used to infer things, such as what hours an employee was active, when someone is at home, etc. One of the requirements for correlating seemingly unrelated activities is the use (and reuse) of an identifier that is recognizable over time within different contexts. IP addresses provide one obvious example, but there are more. Many nodes also have DNS names associated with their addresses, in which case the DNS name serves as a similar identifier. Although the DNS name associated with an address is more work to obtain (it may require a DNS query) the information is often readily available. In such cases, changing the address on a machine over time would do little to address the concern raised in this document, as the DNS name would become the correlating identifier. The use of a constant identifier within an address is of special draft-ietf-ipngwg-addrconf-privacy-00.txt [Page 3] INTERNET-DRAFT June 24, 1999 concern because addresses are a fundamental requirement of communication and cannot easily be hidden from eavesdroppers and other parties. Even when higher layers encrypt their payloads, addresses in packet headers appear in the clear. Consequently, if a mobile host (e.g., laptop) accessed the network from several different locations, an eavesdropper might be able to track the movement of that mobile host from place to place, even if the upper layer payloads were encrypted [SERIALNUM]. 2.2. Not a New Issue Although the topic of this document may at first appear to be an issue new to IPv6, similar issues already exist in today's Internet already. That is, addresses used in today's Internet are often constant in practice for extended periods of time. In many sites, addresses are assigned statically; such addresses typically change infrequently. However, many sites are moving away from static allocation to dynamic allocation via DHCP. In theory, the address a client gets via DHCP can change over time, but in practice servers return the same address to the same client (unless addresses are in such short supply that they are reused immediately by a different node when they become free). Thus, although many sites use DHCP, clients end up using the same address for months at a time. Nodes that need a (non-changing) DNS name generally have static addresses assigned to them to simplify the configuration of DNS servers. Although Dynamic DNS [DDNS] can be used to update the DNS dynamically, it is not widely deployed today. In addition, changing an address but keeping the same DNS name does not really address the underlying concern, since the DNS name becomes a non-changing identifier. Servers generally require a DNS name (so clients can connect to them), and clients often do as well (e.g., some servers refuse to speak to a client whose address cannot be mapped into a DNS name that also maps back into the same address). Many network services require that the client authenticate itself to the server before gaining access to a resource. The authentication step binds the activity (e.g., TCP connection) to a specific entity (e.g., an end user). In such cases, a server already has the ability to track usage by an individual, independent of the address they happen to use. Indeed, such tracking is an important part of accounting. Web browsers and servers typically exchange "cookies" with each other. Such cookies allow web servers to correlate a current activity with a previous activity. One common usage is to send back targeted advertising to a browser by noting that a transaction that it is draft-ietf-ipngwg-addrconf-privacy-00.txt [Page 4] INTERNET-DRAFT June 24, 1999 performing was started by an entity that previously requested information that had the side-effect of indicating the interest of the querier. 2.3. Possible Approaches One way to avoid some of the problems discussed above would be to use DHCP for obtaining addresses. With DHCP, the DHCP server could arrange to hand out addresses that change over time. Another approach, one compatible with the stateless address autoconfiguration architecture would be to change the interface id portion of an address over time. For example, upon each system restart, select a new interface identifier different from the ones used previously. Changing the interface identifier makes it more difficult to look at the IP addresses in independent transactions and identify which ones actually correspond to the same node. In order to make it difficult to make educated guesses as to whether two different interface identifiers belong to the same node, the algorithm for generating alternate identifiers must include input that has an unpredictable component from the perspective of the outside entity's collecting information. Picking identifiers from a pseudorandom sequence suffices, so long as the specific sequence cannot be determined by an outsider examining just the identifiers that appear in addresses. This document proposes the use of an MD5 hash, using a per-interface "key" that varies from one interface to another. Specifically, we use the interface identifier generated using the normal procedure [ADDRARCH] as the key. 3. Protocol Description The goal of this section is to define procedures that: 1) Result in a different interface identifier being generated at each system restart or attachment to a network. 2) Produce a sequence of interface identifiers that appear to be random in the sense that it is difficult for an outside observer to predict a future identifier based on a current one and it is difficult to determine previous identifiers knowing only the present one. We describe two approaches. The first assumes the presence of stable storage that can be used to record state history for use as input into the next iteration of the algorithm, i.e., after a system draft-ietf-ipngwg-addrconf-privacy-00.txt [Page 5] INTERNET-DRAFT June 24, 1999 restart. A second approach addresses the case where stable storage is unavailable and the interface identifier must be generated at random. 3.1. When Stable Storage is Present The following algorithm assumes the presence of a 64-bit "history value" that is used as input in generating an interface identifier. The very first time the system boots (i.e., out-of-the-box), any value can be used including all zeros. Whenever a new interface identifier is generated, its value is saved in the seed for the next iteration of the process. Section 5.3 of [ADDRCONF] describes the steps for generating a link- local address when an interface becomes enabled. This document modifies that step in the following way. Rather than use interface identifiers generated as described in [ADDRARCH], the identifier is generated as follows: 1) Take the history value from the previous iteration (or 0 if there is no previous value) and append to it the interface identifier generated as described in [ADDRARCH]. 2) Compute the MD5 message digest [MD5] over the quantity created in step 1). 3) Take the left-most 64-bits of the MD5 digest and set bit 6 (the left-most bit is numbered 0) to zero. This creates an interface identifier with the universal/local bit indicating local significance only. Use the resultant identifier for generating addresses as outlined in [ADDRCONF]. That is, use the interface identifier to generate a link-local and other appropriate addresses. 4) Save the interface identifier created in step 3) in stable storage as the history value to be used in the next iteration of the algorithm. MD5 was chosen for convenience, not because of strict requirements. IPv6 nodes are already required to implement MD5 as part of IPsec [IPSEC], thus the code will already be present on IPv6 machines. 3.2. In The Absence of Stable Storage In the absence of stable storage, no history information will be available to generate a pseudo-random sequence of interface identifiers. Consequently, identifiers will need to be generated at random. A number of techniques might be appropriate. Consult [RANDOM] for suggestions on good sources for obtaining random numbers. Note that even though a machine may not have stable storage for storing draft-ietf-ipngwg-addrconf-privacy-00.txt [Page 6] INTERNET-DRAFT June 24, 1999 the previously using interface identifier, they will in many cases have configuration information that differs from one machine to another (e.g., user identity, security keys, etc.). One approach to generating random interface identifiers in such cases is to use the configuration information to generate some data bits (which may be remain constant for the life of the machine, but will vary from one machine to another), append some random data and compute the MD5 digest as before. The remaining details for generating addresses would be analogous to those of the previous section. 4. Implications of Changing Interface Identifiers The IPv6 addressing architecture goes to great lengths to ensure that interface identifiers are globally unique. During the IPng discussions of the GSE proposal [GSE], it was felt that keeping interface identifiers globally unique in practice might prove useful to future transport protocols. Usage of the algorithms in this document would eliminate that future flexibility. The desires of protecting individual privacy vs. the desire to effectively maintain and debug a network can conflict with each other. Having clients use addresses that change over time will make it more difficult to track down and isolate operational problems. For example, when looking at packet traces, it could become more difficult to determine whether one is seeing behavior caused by a single errant machine, or by a number of them. 5. Open Issues and Future Work This document specifies that a node generate a new interface identifier each time it autoconfigures an interface. The same identifier is used to generate all addresses, including link-local, site-local and global. However, the concerns this document addresses are most likely relevant only to global-scope addresses. Thus, it may make sense for a node to have two interface identifiers, the standard one [ADDRCONF] used for link-local and site-local addresses, with a changing one used only for global-scope addresses. This would appear to require only small changes from the current specification. In some cases, one could imagine the need to change an address more frequently than upon reboot or movement to a new location. For example, for machines that do not restart for months at time, one might change addresses every few days or weeks. In extreme cases, one might even want to change addresses upon the initiation of each new TCP connection. Doing frequent changes would appear to add significant issues and possible implementation complications. For draft-ietf-ipngwg-addrconf-privacy-00.txt [Page 7] INTERNET-DRAFT June 24, 1999 example, an implementation might need to support a significant number of address on an interface simultaneously. An implementation would also need to keep track of which addresses were being used so as to be able to stop using an address once no upper layer protocols are using it (but not before). This is in contrast to current approaches where addresses are removed from an interface when they become invalid [ADDRCONF], independent of whether or not upper layer protocols are still using them. Some machines server as both clients and servers. In such cases, the server would need a DNS name. Whether the address stays fixed or changes doesn't matter since the DNS name remains constant. Simultaneously, when acting as a client (e.g., initiating communication) it may want to vary the address it uses. In such environments, one might need multiple addresses. Source address selection rules would need to take into account the policy aspects of which addresses would be acceptable for use when initiating communication. 6. Security Considerations The motivation for this document stems from privacy concerns for individuals. This document does not appear to add any security issues beyond those already associated with stateless address autoconfiguration [ADDRCONF]. 7. References [ADDRARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998. [ADDRCONF] Thomson, S. and T. Narten, "IPv6 Address Autoconfiguration", RFC 2462, December 1998. [DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [DDNS] Vixie et. al., "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997. [DISCOVERY] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [GSE-ANALYSIS] Crawford et. al., "Separating Identifiers and Locators in Addresses: An Analysis of the GSE Proposal for IPv6 ", draft-ietf-ipngwg-esd-analysis-04.txt. draft-ietf-ipngwg-addrconf-privacy-00.txt [Page 8] INTERNET-DRAFT June 24, 1999 [IPSEC] Kent, S., Atkinson, R., "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. [SERIALNUM] Moore, K., "Privacy Considerations for the Use of Hardware Serial Numbers in End-to-End Network Protocols", draft-iesg-serno-privacy-00.txt. 8. Authors' Addresses Thomas Narten IBM Corporation P.O. Box 12195 Research Triangle Park, NC 27709-2195 USA Phone: +1 919 254 7798 EMail: narten@raleigh.ibm.com draft-ietf-ipngwg-addrconf-privacy-00.txt [Page 9] -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 13 15:43:59 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) id d9DMeU300379 for ipng-dist; Wed, 13 Oct 1999 15:40:30 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) with ESMTP id d9DMe9P00340 for ; Wed, 13 Oct 1999 15:40:11 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.1b+Sun/8.9.1) id PAA16221 for ipng@sunroof.eng.sun.com; Wed, 13 Oct 1999 15:37:53 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) with ESMTP id d9DMTaR18005 for ; Wed, 13 Oct 1999 15:29:37 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA09338 for ; Wed, 13 Oct 1999 09:14:02 -0700 (PDT) Received: from pool.pipex.net (pool.pipex.net [158.43.128.24]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id JAA27521 for ; Wed, 13 Oct 1999 09:14:01 -0700 (PDT) Received: (qmail 10165 invoked from smtpd); 13 Oct 1999 16:13:45 -0000 Received: from copper.cam.uk.internal (HELO guyd-ipv6.cam.uk.internal) (172.31.7.49) by pool.cam.uk.internal with SMTP; 13 Oct 1999 16:13:45 -0000 Date: Wed, 13 Oct 1999 17:13:45 +0100 (BST) From: Guy Davies X-Sender: guyd@guyd-ipv6.cam.uk.internal To: ipng@sunroof.eng.sun.com Subject: More misinformation on IPv6 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, Now the misinformation about the privacy threat posed by IPv6 is even being spread from the BBC web site. This is serious because, justifiably or not, people believe the BBC :-( http://news.bbc.co.uk/hi/english/sci/tech/newsid_473000/473647.stm Guy -- Guy Davies UUNET, An MCI WorldCom Company Sr. Network Engineer 332 Science Park, Cambridge, CB4 4BZ, UK email: guyd@uu.net tel: +44 (1223) 250457 mobile: +44 (7771) 907481 fax: +44 (1223) 250412 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 13 15:47:41 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) id d9DMkBJ00520 for ipng-dist; Wed, 13 Oct 1999 15:46:11 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) with ESMTP id d9DMk4P00509 for ; Wed, 13 Oct 1999 15:46:04 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.1b+Sun/8.9.1) id PAA16291 for ipng@sunroof.eng.sun.com; Wed, 13 Oct 1999 15:43:48 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) with ESMTP id d9DMhpP00452; Wed, 13 Oct 1999 15:43:52 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA24950; Wed, 13 Oct 1999 07:05:48 -0700 (PDT) Received: from duvel.inria.fr (duvel.inria.fr [128.93.9.50]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA06259; Wed, 13 Oct 1999 08:05:41 -0600 (MDT) Received: (from durand@localhost) by duvel.inria.fr (8.9.3/8.9.3) id QAA77816; Wed, 13 Oct 1999 16:05:13 +0200 (CEST) (envelope-from durand) Date: Wed, 13 Oct 1999 16:05:13 +0200 (CEST) From: Alain Durand Message-Id: <199910131405.QAA77816@duvel.inria.fr> To: alain.durand@imag.fr, Erik.Nordmark@eng.sun.com, brian@hursley.ibm.com, ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com Subject: source and destintion address selection algorithm Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'm writing this from another acount as we are currently experiencing severe connectivity problems with the US.. I hope it will get through. - Alain I'm copying this to IPng mailling list. At 08:59 12/10/99 -0700, Erik Nordmark wrote: >> The consequence of what you and Alain are saying is going to >> be a host configuration option for "prefer 6to4" versus "prefer native" >> in case that both are available. Do we really want another >> config option? If yes, the words are easy to write. > >I personally don't think we need to configuration option, but >others might think the order should be different. > >My order is: >1. If both the source and destination have at least one native IPv6 address use > IPv6 native source and destination. 2. If both the source and destination >have (at least one) 6to4 address use > 6to4 source and destination addresses. >3. If both the source and destination have (at least one) IPv4-compatible > addresses (remember that automatic tunneling stuff) use > IPv4-compatible source and destination addresses. > >In the above "native" means addresses that are not 6to4, not IPv4-compatible, >and not IPv4-mapped. > I think we can generalized this order with the following algorithm to select both source and destination address. Lets define the precedence prec of an address as the following function prec(link local) = 10 prec(site local) = 20 prec(native-v6 global, non 6to4) = 30 prec(native-V6 global, 6to4) = 35 prec(IPv4 compatible) = 50 Note: those are suggested default value. They can be override manually by configuration options if one does not like this specific order. 0. Consider the set of all possible source addresses and the set of all possible destination addresses, 1. Select destination address dst with the lowest precedence prec(dst) 2. If several destination addresses are still available, one may pick the first one returned by the DNS or use random selection. 3. Select src in this order: - one with the same precedence as prec(dst) - if impossible, one with the lowest precedence and prec(src) > prec(dst) - if impossible, one with the highest precedence 4. If several source addresses are still available, longest prefix match with the selected destination address or random selection may be used. 5. If the communication failed because the destination address is unreachable (scope too small for example), remove dst from the set of possible destination addresses and reiterate at step 1. In the case of a simple application that select the first address returned by the DNS and let the kernel fix the source address, step 3 & 4 of this algorithm can be used by the kernel. - 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 13 16:00:43 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) id d9DMvj400655 for ipng-dist; Wed, 13 Oct 1999 15:57:45 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) with ESMTP id d9DMvaP00648 for ; Wed, 13 Oct 1999 15:57:36 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id AAA22245; Wed, 13 Oct 1999 00:19:52 -0700 (PDT) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA23357; Wed, 13 Oct 1999 00:19:51 -0700 (PDT) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id JAA07392; Wed, 13 Oct 1999 09:19:42 +0200 (MET DST) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id JAA09809; Wed, 13 Oct 1999 09:19:40 +0200 (MET DST) Message-Id: <199910130719.JAA09809@givry.inria.fr> From: Francis Dupont To: Erik Nordmark cc: Matt Crawford , ipng@sunroof.eng.sun.com, namedroppers@internic.net Subject: Re: draft-ietf-ipngwg-dns-lookups-04.txt In-reply-to: Your message of Mon, 11 Oct 1999 16:41:28 PDT. Date: Wed, 13 Oct 1999 09:19:38 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: I think it would also be useful to try to nail down a default order that the resolver will ask for IPv6 address records and whether or not implementaions should have knobs to adjust that order. (The issue of ordering between A and AAAA/A6 records is already discussed in RFC 1933 if I'm not mistaken.) => about ordering, something is not specified: when an address is searched for a not fully qualified domain name then there is a search for IPv4/A and IPv6/AAAA/A6 and in the search list (the list of domains, usually initialised with the local domain name). Should we do IP version or domain first? I believe many implementations do domain first, ie. for instance look for an AAAA RR for the name completed with search list elements then if nothing is found try the same thing for an A RR. Francis.Dupont@inria.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 13 16:09:58 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) id d9DN7I300828 for ipng-dist; Wed, 13 Oct 1999 16:07:18 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.82.166] (may be forged)) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) with ESMTP id d9DN6IP00802; Wed, 13 Oct 1999 16:06:18 -0700 (PDT) Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id QAA297876; Wed, 13 Oct 1999 16:06:16 -0700 (PDT) Date: Wed, 13 Oct 1999 16:03:49 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: source and destintion address selection algorithm To: Alain Durand Cc: alain.durand@imag.fr, Erik.Nordmark@eng.sun.com, brian@hursley.ibm.com, ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <199910131405.QAA77816@duvel.inria.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Lets define the precedence prec of an address as the following function > prec(link local) = 10 > prec(site local) = 20 > prec(native-v6 global, non 6to4) = 30 > prec(native-V6 global, 6to4) = 35 > prec(IPv4 compatible) = 50 > > Note: those are suggested default value. They can be override manually > by configuration options if one does not like this specific order. > > > 0. Consider the set of all possible source addresses > and the set of all possible destination addresses, > > 1. Select destination address dst with the lowest precedence prec(dst) Selecting the destination address without looking at source addresses is not ideal. For instance if the destination has a native and a 6to4 address and the source has only a 6to4 address I think it is better to choose 6to4 for both source and destination. Your algorithm will first pick the native destination and then pick the best (in this case only) source. Thus I think you need to look at (source, dest) pairs and prefer those pairs where the source and dest are "similar". Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 13 16:29:13 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) id d9DNQ1200882 for ipng-dist; Wed, 13 Oct 1999 16:26:01 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) with ESMTP id d9DNPpP00875 for ; Wed, 13 Oct 1999 16:25:52 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id QAA23895 for ; Wed, 13 Oct 1999 16:25:46 -0700 (PDT) Received: from dfw-ix5.ix.netcom.com (dfw-ix5.ix.netcom.com [206.214.98.5]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA05777 for ; Wed, 13 Oct 1999 16:25:45 -0700 (PDT) Received: (from smap@localhost) by dfw-ix5.ix.netcom.com (8.8.4/8.8.4) id SAA22748; Wed, 13 Oct 1999 18:25:00 -0500 (CDT) Received: from dal-tx48-58.ix.netcom.com(198.211.45.122) by dfw-ix5.ix.netcom.com via smap (V1.3) id rma022224; Wed Oct 13 18:22:57 1999 Message-ID: <3804A3FC.64BAF976@ix.netcom.com> Date: Wed, 13 Oct 1999 16:23:43 +0100 From: Jeff Williams Organization: INEG. Inc. (Spokesman INEGroup) X-Mailer: Mozilla 4.08 [en] (Win16; I) MIME-Version: 1.0 To: Bill Frezza , ipng@sunroof.eng.sun.com, ICANN Comments CC: IFWP Discussion List , "etrigar@teleline.es" , "Esther (The clueless) Dyson" , "mmr@darwin.ptvy.ca.us" , "linda_wilson@radcliffe.edu" , "junsec@wide.ad.jp" , "gregcrew@iaccess.com.au" , "geraldine.capdeboscq@bull.fr" , "gconrades@polarisventures.com" , "fitzsimmon@dnb.com" , "gconrades@icann.org" , "gregcrew@icann.org" , "roberts@icann.org" Subject: Re: My InternetWeek op-ed column on IPv6 privacy issues References: <4.1.19991010162135.0096bb30@pop3.psinet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bill and all, Thank you for forwarding this. It helps to underscore the problems that will eventually become significant with respect to Privacy problems with IPv6. We [INEG Inc.] have been concerned with this problem with IPv6 for some time and have passed this concern on to the IETF as well as ICANN as ICANN seems to have a strong belief that IPv6 is the future. We respectfully are not in complete agreement for the privacy concerns amongst others associated with IPv6 and have decidedly moved towards a private effort towards IPv8 as a result. That effort in in deployment as I type this response. Bill Frezza wrote: > Gentle readers, > > Thank you for your feedback on my recent column "Where's All The Outrage > About The IPv6 Privacy Threat" > > http://www.internetwk.com/columns/frezz100499.htm > > Normally I respond to every letter I receive, but the volume of mail on > this one broke all records so I'm afraid I have to send out a group note. > (It seems that peeved IETF geeks are even more vociferous than peeved > Mac-heads. :) > > Let me, in particular, address some of the comments from the folks who > insist that there is no privacy problem with IPv6 or that the problem is > identical with IPv4 or that the problem has already been solved by the IETF > or that the use of EUI-64 addressing is optional and not mandatory, > therefore there's no problem. (I do not intend to reply to the folks who > just plain don't care about privacy as this is a philosophical issue beyond > the scope of this note. As for readers who don't like my inflammatory > writing style, feel free not to read my column. I write op-eds, not news > articles.) > > 1) Yes, IPv4 has its own privacy problems. In fact, any time one uses a > static or long-lived IP address, the possibility exists for abusive > systematic surveillance. The fact that a central registry of addresses does > or does not exist has no bearing on the potential threat as such a data > base can be built over time, particularly for individuals or groups that > have been specifically targeted. In addition, countries like China or > Singapore could easily require registration. Why give them the tools in the > first place? > > 2) Yes, dynamic assignment of IP addresses for dial-up users as well as > Network Address Translation (NAT) helps mitigate (though does not > eliminate) the privacy problem. As we move towards an "always connected" > Internet, with more and more users communicating via Cable Modems or DSL, > more IP addresses will become long lived, hence the problem will get worse. > > 3) It's too late to change IPv4 while it is not too late to change IPv6. My > column was intended as a call to action to get the IETF off it's duff. A > fault in my column is that I did not specifically describe proposals being > circulated to address the issue, one of which is attached below. Mea culpa, > and my apologies to the good guys for ignoring their efforts. May the force > be with you. > > 4) Be that as it may, draft-ietf-ipngwg-addrconf-privacy-00.txt is just a > proposal. It has not been and may not be adopted. Absent further action, it > will go away. If it is adopted, it may or may not be implemented by major > vendors, especially if the final standard offers a Chinese menu of choices. > > 5) Note that the proposal ACKNOWLEDGES THE PROBLEM. In addition it points > out that > > > The desires of protecting individual privacy vs. the desire to > > effectively maintain and debug a network can conflict with each > > other. > > The same can be said across the board for many aspects of law enforcement > in a society that values liberty. Just think how much safer the streets > would be if we all walked around with electronic radio ID collars > registering our movements. Fortunately, we have chosen not to construct > such a society (although if you follow the development of the CALEA laws, > this is not for want of the FBI trying). > > 6) The solutions proposed in draft-ietf-ipngwg-addrconf-privacy-00.txt > cause a a major problem with one of the other goals of IPv6 > > > The IPv6 addressing architecture goes to great lengths to ensure that > > interface identifiers are globally unique. During the IPng > > discussions of the GSE proposal [GSE], it was felt that keeping > > interface identifiers globally unique in practice might prove useful > > to future transport protocols. Usage of the algorithms in this > > document would eliminate that future flexibility. > > The random assignment algorithms look very promising. I hope they are > adopted, but no one knows yet how this conflict is going to be resolved. > > 7) At the end of the day, what matters to the average netizen is not the > menu of possible alternatives described in IETF standards, but the actual > default implementation in popular products, e.g. Windows. Just because an > educated and motivated geek can get into the plumbing of his machine and > find a way to solve his own privacy problem doesn't mean the problem has > been solved for the bulk of average users. If the folks at Microsoft don't > properly address this in their future products, I can positively, > absolutely guarantee that it will blow up in their face. > > 8) Readers who are interested in registering their concerns should contact > the CDT at www.CDT.org. I got a very nice note from them indicating that > they are now wading into the issue. One hopes that EPIC and the EFF will > follow suit. > > Cheers, > > Bill Frezza > InternetWeek > frezza@alum.MIT.edu > > PS Special thanks to Scott Bradner and Mike O'Dell for helping me > understand some of the technical nuances of this issue that I had > previously misunderstood. Notwithstanding, I stand by my column and hope > all you geeks do something about it. The opinions above are my own. > > Regards, -- Jeffrey A. Williams Spokesman INEGroup (Over 95k members strong!) CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 972-447-1894 Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 13 16:30:59 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) id d9DNTZv00917 for ipng-dist; Wed, 13 Oct 1999 16:29:35 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) with ESMTP id d9DNTNP00903 for ; Wed, 13 Oct 1999 16:29:23 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id QAA27152 for ; Wed, 13 Oct 1999 16:29:23 -0700 (PDT) Received: from dfw-ix5.ix.netcom.com (dfw-ix5.ix.netcom.com [206.214.98.5]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA07358 for ; Wed, 13 Oct 1999 16:29:22 -0700 (PDT) Received: (from smap@localhost) by dfw-ix5.ix.netcom.com (8.8.4/8.8.4) id SAA23336; Wed, 13 Oct 1999 18:29:19 -0500 (CDT) Received: from dal-tx48-58.ix.netcom.com(198.211.45.122) by dfw-ix5.ix.netcom.com via smap (V1.3) id rma023321; Wed Oct 13 18:28:56 1999 Message-ID: <3804A569.17E21F9F@ix.netcom.com> Date: Wed, 13 Oct 1999 16:29:47 +0100 From: Jeff Williams Organization: INEG. Inc. (Spokesman INEGroup) X-Mailer: Mozilla 4.08 [en] (Win16; I) MIME-Version: 1.0 To: Guy Davies CC: ipng@sunroof.eng.sun.com Subject: Re: More misinformation on IPv6 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Guy and all, Hummm? I guess we disagree here. I found this article that you kindly provided the link to to be essentially accurate. Pray tell what part you find either disagreeable or inaccurate? Guy Davies wrote: > Hi, > > Now the misinformation about the privacy threat posed by IPv6 is even > being spread from the BBC web site. This is serious because, justifiably > or not, people believe the BBC :-( > > http://news.bbc.co.uk/hi/english/sci/tech/newsid_473000/473647.stm > > Guy > -- > Guy Davies UUNET, An MCI WorldCom Company > Sr. Network Engineer 332 Science Park, Cambridge, CB4 4BZ, UK > email: guyd@uu.net tel: +44 (1223) 250457 > mobile: +44 (7771) 907481 fax: +44 (1223) 250412 > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- Regards, -- Jeffrey A. Williams Spokesman INEGroup (Over 95k members strong!) CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 972-447-1894 Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 13 16:46:10 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) id d9DNgEk00966 for ipng-dist; Wed, 13 Oct 1999 16:42:14 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) with ESMTP id d9DNg3P00950 for ; Wed, 13 Oct 1999 16:42:03 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id QAA27157 for ; Wed, 13 Oct 1999 16:42:03 -0700 (PDT) Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id QAA12083 for ; Wed, 13 Oct 1999 16:42:02 -0700 (PDT) Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by crufty; Wed Oct 13 19:40:09 EDT 1999 Received: from dnrc.bell-labs.com (dhcp-6-168.pa.bell-labs.com [135.250.6.168]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id TAA01235; Wed, 13 Oct 1999 19:40:06 -0400 (EDT) Message-ID: <380518B7.FFE7143A@dnrc.bell-labs.com> Date: Wed, 13 Oct 1999 16:41:44 -0700 From: Grenville Armitage Organization: Bell Laboratories, Lucent Technologies X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jeff Williams CC: ipng@sunroof.eng.sun.com Subject: Re: More misinformation on IPv6 References: <3804A569.17E21F9F@ix.netcom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jeff, A number of posters have recently commented on the essential _in_accuracies. It would be more illuminating if you listed each assertion of privacy concern you considered accurate, along with supporting evidence. cheers, gja Jeff Williams wrote: > > Guy and all, > > Hummm? I guess we disagree here. I found this article that > you kindly provided the link to to be essentially accurate. Pray > tell what part you find either disagreeable or inaccurate? > > Guy Davies wrote: > > > Hi, > > > > Now the misinformation about the privacy threat posed by IPv6 is even > > being spread from the BBC web site. This is serious because, justifiably > > or not, people believe the BBC :-( > > > > http://news.bbc.co.uk/hi/english/sci/tech/newsid_473000/473647.stm > > > > Guy > > -- > > Guy Davies UUNET, An MCI WorldCom Company > > Sr. Network Engineer 332 Science Park, Cambridge, CB4 4BZ, UK > > email: guyd@uu.net tel: +44 (1223) 250457 > > mobile: +44 (7771) 907481 fax: +44 (1223) 250412 > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > > Regards, > > -- > Jeffrey A. Williams > Spokesman INEGroup (Over 95k members strong!) > CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. > Information Network Eng. Group. INEG. INC. > E-Mail jwkckid1@ix.netcom.com > Contact Number: 972-447-1894 > Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 13 17:31:55 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) id d9E0SXi01038 for ipng-dist; Wed, 13 Oct 1999 17:28:33 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) with ESMTP id d9E0SOP01031 for ; Wed, 13 Oct 1999 17:28:25 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id RAA04285 for ; Wed, 13 Oct 1999 17:28:24 -0700 (PDT) Received: from dfw-ix2.ix.netcom.com (dfw-ix2.ix.netcom.com [206.214.98.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA27729 for ; Wed, 13 Oct 1999 18:28:23 -0600 (MDT) Received: (from smap@localhost) by dfw-ix2.ix.netcom.com (8.8.4/8.8.4) id TAA06070; Wed, 13 Oct 1999 19:28:14 -0500 (CDT) Received: from dal-tx61-52.ix.netcom.com(207.221.95.52) by dfw-ix2.ix.netcom.com via smap (V1.3) id rma005873; Wed Oct 13 19:27:16 1999 Message-ID: <3804B313.F49D6470@ix.netcom.com> Date: Wed, 13 Oct 1999 17:28:05 +0100 From: Jeff Williams Organization: INEG. Inc. (Spokesman INEGroup) X-Mailer: Mozilla 4.08 [en] (Win16; I) MIME-Version: 1.0 To: Grenville Armitage CC: ipng@sunroof.eng.sun.com Subject: Re: More misinformation on IPv6 References: <3804A569.17E21F9F@ix.netcom.com> <380518B7.FFE7143A@dnrc.bell-labs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Grenville and all, I can appreciate your interest here of course, but I believe I listed my supporting evidence as part of my in turn support for Bills comments as well as the article to which Guy kindly posted. I am in total agreement with the article in it's entirety. As such, that stands for my evidence in part as have the other two articles that were posted, one of which was the one I posted from AP.ORG. Grenville Armitage wrote: > Jeff, > > A number of posters have recently commented on the essential > _in_accuracies. It would be more illuminating if you listed each > assertion of privacy concern you considered accurate, along > with supporting evidence. > > cheers, > gja > > Jeff Williams wrote: > > > > Guy and all, > > > > Hummm? I guess we disagree here. I found this article that > > you kindly provided the link to to be essentially accurate. Pray > > tell what part you find either disagreeable or inaccurate? > > > > Guy Davies wrote: > > > > > Hi, > > > > > > Now the misinformation about the privacy threat posed by IPv6 is even > > > being spread from the BBC web site. This is serious because, justifiably > > > or not, people believe the BBC :-( > > > > > > http://news.bbc.co.uk/hi/english/sci/tech/newsid_473000/473647.stm > > > > > > Guy > > > -- > > > Guy Davies UUNET, An MCI WorldCom Company > > > Sr. Network Engineer 332 Science Park, Cambridge, CB4 4BZ, UK > > > email: guyd@uu.net tel: +44 (1223) 250457 > > > mobile: +44 (7771) 907481 fax: +44 (1223) 250412 > > > > > > -------------------------------------------------------------------- > > > IETF IPng Working Group Mailing List > > > IPng Home Page: http://playground.sun.com/ipng > > > FTP archive: ftp://playground.sun.com/pub/ipng > > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > > -------------------------------------------------------------------- > > > > Regards, > > > > -- > > Jeffrey A. Williams > > Spokesman INEGroup (Over 95k members strong!) > > CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. > > Information Network Eng. Group. INEG. INC. > > E-Mail jwkckid1@ix.netcom.com > > Contact Number: 972-447-1894 > > Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- Regards, -- Jeffrey A. Williams Spokesman INEGroup (Over 95k members strong!) CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 972-447-1894 Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 13 17:43:26 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) id d9E0eMm01092 for ipng-dist; Wed, 13 Oct 1999 17:40:22 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) with ESMTP id d9E0eCP01085 for ; Wed, 13 Oct 1999 17:40:13 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id RAA07346 for ; Wed, 13 Oct 1999 17:40:12 -0700 (PDT) Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id SAA01906 for ; Wed, 13 Oct 1999 18:40:11 -0600 (MDT) Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Wed Oct 13 20:38:12 EDT 1999 Received: from dnrc.bell-labs.com (dhcp-6-168.pa.bell-labs.com [135.250.6.168]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id UAA02860; Wed, 13 Oct 1999 20:38:09 -0400 (EDT) Message-ID: <38052653.ACEE752F@dnrc.bell-labs.com> Date: Wed, 13 Oct 1999 17:39:47 -0700 From: Grenville Armitage Organization: Bell Laboratories, Lucent Technologies X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jeff Williams CC: ipng@sunroof.eng.sun.com Subject: Re: More misinformation on IPv6 References: <3804A569.17E21F9F@ix.netcom.com> <380518B7.FFE7143A@dnrc.bell-labs.com> <3804B313.F49D6470@ix.netcom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jeff Williams wrote: [..] > As such, that stands for my evidence in part as > have the other two articles that were posted, one of which > was the one I posted from AP.ORG. Each article is a collection of assertions without much explanation. I'm asking for your explanations to backup the assertions you're buying into. This is a WG, not an op-ed group. cheers, gja -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 13 17:55:07 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) id d9E0q7Z01117 for ipng-dist; Wed, 13 Oct 1999 17:52:07 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) with ESMTP id d9E0pvP01110 for ; Wed, 13 Oct 1999 17:51:59 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id RAA07816 for ; Wed, 13 Oct 1999 17:51:56 -0700 (PDT) Received: from dfw-ix8.ix.netcom.com (dfw-ix8.ix.netcom.com [206.214.98.8]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA04762 for ; Wed, 13 Oct 1999 17:51:56 -0700 (PDT) Received: (from smap@localhost) by dfw-ix8.ix.netcom.com (8.8.4/8.8.4) id TAA02750; Wed, 13 Oct 1999 19:51:43 -0500 (CDT) Received: from dal-tx61-52.ix.netcom.com(207.221.95.52) by dfw-ix8.ix.netcom.com via smap (V1.3) id rma002514; Wed Oct 13 19:51:03 1999 Message-ID: <3804B8A3.B257499C@ix.netcom.com> Date: Wed, 13 Oct 1999 17:51:49 +0100 From: Jeff Williams Organization: INEG. Inc. (Spokesman INEGroup) X-Mailer: Mozilla 4.08 [en] (Win16; I) MIME-Version: 1.0 To: Grenville Armitage CC: ipng@sunroof.eng.sun.com Subject: Re: More misinformation on IPv6 References: <3804A569.17E21F9F@ix.netcom.com> <380518B7.FFE7143A@dnrc.bell-labs.com> <3804B313.F49D6470@ix.netcom.com> <38052653.ACEE752F@dnrc.bell-labs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Grenville and all, I believe I outlined in some specific the concerns I had regarding the privacy issues from a technical standpoint some 4 months ago on this list. You might want to review the archives for that time frame as repeating the concerns I outlined yet again would be an exercise that I feel is of little value at this juncture as those concerns as potential correction fell od deaf ears than and are likely to do so again should I repeat them here again. Grenville Armitage wrote: > Jeff Williams wrote: > [..] > > As such, that stands for my evidence in part as > > have the other two articles that were posted, one of which > > was the one I posted from AP.ORG. > > Each article is a collection of assertions without much > explanation. I'm asking for your explanations to backup > the assertions you're buying into. This is a WG, not > an op-ed group. > > cheers, > gja Regards, -- Jeffrey A. Williams Spokesman INEGroup (Over 95k members strong!) CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 972-447-1894 Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 13 18:18:53 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) id d9E1DcH01150 for ipng-dist; Wed, 13 Oct 1999 18:13:38 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) with ESMTP id d9E1DSP01143 for ; Wed, 13 Oct 1999 18:13:29 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id SAA18603 for ; Wed, 13 Oct 1999 18:13:28 -0700 (PDT) Received: from mailnfs0.tiac.net (mailnfs0.tiac.net [199.0.65.17]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA12025 for ; Wed, 13 Oct 1999 19:13:27 -0600 (MDT) Received: from rms (smiths.tiac.net [199.3.129.167]) by mailnfs0.tiac.net (8.8.8/8.8) with SMTP id VAA02367; Wed, 13 Oct 1999 21:13:22 -0400 (EDT) From: "Richard M. Smith" To: "Guy Davies" Cc: Subject: RE: More misinformation on IPv6 Date: Wed, 13 Oct 1999 21:13:34 -0400 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.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-reply-to: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Guy, I looked over the BBC article and it seems fine to me. My concern here is that Web sites will start building databases that include people's MAC address. MAC addresses will then allow Web sites to correlate personal data using a common MAC address key. The most likely scenario is when a Web site gets a hit, they can query other Web sites to find out what they know about the MAC address that comes in with the hit. My guess is that very quickly, market forces will produce some sort of central registry which can give out a name, Email address, phone #, etc. given a MAC address. Microsoft, for example, even started building just such a database with their Windows 98 Registration Wizard. For example, here is some of my registration information that illustrates the problem: === Microsoft Registration Wizard === Default First Name = Richard M. Default Last Name = Smith Default Company = Mailing Address = 172 Mason Terr. Additional Address = City = Brookline State = MA ZIP Code = 02446 Country = 0 Daytime Phone = 617 731-0682 ... HWID = 13b50d60ce4a11d2a67f002078900337 The HWID field is a GUID and so it contains my MAC address which is 002078900337. (If someone is running Windows 98 and has done electronic registration, this same information can be found in the file c:\windows\reginfo.txt.) Because of public pressure however, Microsoft has stopped saving HWIDs at their servers and in the second edition of Windows 98, no longer generates the number. Microsoft also plans to eliminate the use of MAC addresses inside of GUIDs in general in future versions of Windows. RealNetworks also is building a similar registration database with GUIDs and MAC addresses. However, they haven't stopped recording MAC addresses because no one has caught them yet. :-) Richard > -----Original Message----- > From: owner-ipng@sunroof.eng.sun.com > [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Guy Davies > Sent: Wednesday, October 13, 1999 12:14 PM > To: ipng@sunroof.eng.sun.com > Subject: More misinformation on IPv6 > > > Hi, > > Now the misinformation about the privacy threat posed by IPv6 is even > being spread from the BBC web site. This is serious because, justifiably > or not, people believe the BBC :-( > > http://news.bbc.co.uk/hi/english/sci/tech/newsid_473000/473647.stm > > Guy > -- > Guy Davies UUNET, An MCI WorldCom Company > Sr. Network Engineer 332 Science Park, Cambridge, CB4 4BZ, UK > email: guyd@uu.net tel: +44 (1223) 250457 > mobile: +44 (7771) 907481 fax: +44 (1223) 250412 > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 13 18:38:48 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9E1XN801235 for ipng-dist; Wed, 13 Oct 1999 18:33:23 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9E1X1k01228 for ; Wed, 13 Oct 1999 18:33:05 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id SAA20977 for ; Wed, 13 Oct 1999 18:32:40 -0700 (PDT) Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA16339 for ; Wed, 13 Oct 1999 18:32:39 -0700 (PDT) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id SAA479561; Wed, 13 Oct 1999 18:32:00 -0700 (PDT) mail_from (sm@bossette.engr.sgi.com) Received: from bossette.engr.sgi.com (bossette.engr.sgi.com [150.166.61.12]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id SAA29386; Wed, 13 Oct 1999 18:31:53 -0700 (PDT) mail_from (sm@bossette.engr.sgi.com) Received: (from sm@localhost) by bossette.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id SAA15113; Wed, 13 Oct 1999 18:31:51 -0700 (PDT) From: sm@bossette.engr.sgi.com (Sam Manthorpe) Message-Id: <199910140131.SAA15113@bossette.engr.sgi.com> Subject: Re: More misinformation on IPv6 To: smiths@tiac.net (Richard M. Smith) Date: Wed, 13 Oct 1999 18:31:50 -0700 (PDT) Cc: guyd@uu.net, ipng@sunroof.eng.sun.com In-Reply-To: from "Richard M. Smith" at Oct 13, 99 09:13:34 pm X-Mailer: ELM [version 2.4 PL25 PGP3 *ALPHA*] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Richard M. Smith wrote: > The most likely scenario is when a Web site > gets a hit, they can query other Web sites to find > out what they know about the MAC address that comes > in with the hit. My guess is that very quickly, market > forces will produce some sort of central registry > which can give out a name, Email address, phone #, > etc. given a MAC address. > > Microsoft, for example, even started building > just such a database with their Windows 98 Registration Wizard. So the problem already exists with IPv4, then, and is not IPv6 specific as the BBC article claims. Also, isn't it relatively easy to construct such databases for any people using the Web with Java enabled in their browser, irrespective of underlying hardware? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sam Manthorpe, SGI. tel: (650)933-2856 fax: (650)932-2856 sm@engr.sgi.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 13 18:49:40 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9E1iqu01271 for ipng-dist; Wed, 13 Oct 1999 18:44:52 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9E1igk01264 for ; Wed, 13 Oct 1999 18:44:43 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id SAA13668 for ; Wed, 13 Oct 1999 18:44:41 -0700 (PDT) Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA19693 for ; Wed, 13 Oct 1999 18:44:41 -0700 (PDT) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id SAA06344; Wed, 13 Oct 1999 18:45:14 -0700 (PDT) mail_from (sm@bossette.engr.sgi.com) Received: from bossette.engr.sgi.com (bossette.engr.sgi.com [150.166.61.12]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id SAA60784; Wed, 13 Oct 1999 18:44:30 -0700 (PDT) mail_from (sm@bossette.engr.sgi.com) Received: (from sm@localhost) by bossette.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id SAA15220; Wed, 13 Oct 1999 18:44:28 -0700 (PDT) From: sm@bossette.engr.sgi.com (Sam Manthorpe) Message-Id: <199910140144.SAA15220@bossette.engr.sgi.com> Subject: Re: More misinformation on IPv6 To: sm@bossette.engr.sgi.com (Sam Manthorpe) Date: Wed, 13 Oct 1999 18:44:28 -0700 (PDT) Cc: smiths@tiac.net, guyd@uu.net, ipng@sunroof.eng.sun.com In-Reply-To: <199910140131.SAA15113@bossette.engr.sgi.com> from "Sam Manthorpe" at Oct 13, 99 06:31:50 pm X-Mailer: ELM [version 2.4 PL25 PGP3 *ALPHA*] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Sam Manthorpe wrote: > So the problem already exists with IPv4, then, and is not IPv6 > specific as the BBC article claims. Also, isn't it relatively > easy to construct such databases for any people using the > Web with Java enabled in their browser, irrespective of underlying > hardware? Sorry, for `hardware', read `network layer protocol'. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sam Manthorpe, SGI. tel: (650)933-2856 fax: (650)932-2856 sm@engr.sgi.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 13 19:10:10 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9E24qR01305 for ipng-dist; Wed, 13 Oct 1999 19:04:52 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9E24Qk01298 for ; Wed, 13 Oct 1999 19:04:27 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id TAA16409 for ; Wed, 13 Oct 1999 19:04:25 -0700 (PDT) Received: from mailnfs0.tiac.net (mailnfs0.tiac.net [199.0.65.17]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA28118 for ; Wed, 13 Oct 1999 20:04:25 -0600 (MDT) Received: from rms (smiths.tiac.net [199.3.129.167]) by mailnfs0.tiac.net (8.8.8/8.8) with SMTP id WAA10609; Wed, 13 Oct 1999 22:04:21 -0400 (EDT) From: "Richard M. Smith" To: "Sam Manthorpe" Cc: , Subject: RE: More misinformation on IPv6 Date: Wed, 13 Oct 1999 22:04:33 -0400 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.2910.0) Importance: Normal In-Reply-To: <199910140131.SAA15113@bossette.engr.sgi.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Sam, IPv4 isn't considered a reliable tracking mechanism at Web sites because too many folks use dynamic IP addresses particularily among home users. That's why cookies were invented. Netscape at least designed them so they can't be shared between Web Sites. However with IPv6, when using the autoconfiguration feature, even dynamic addresses will contain a static MAC address and hence are trackable. By the time IPv6 sees widespread use, I suspect that most computers will have an Ethernet adapter for a LAN connection, DSL modem, or cablemodem. Pretty much everyone will have a MAC address. Hmm, maybe we should just start assigning them at birth and make them permanent? :-) Richard > -----Original Message----- > From: Sam Manthorpe [mailto:sm@bossette.engr.sgi.com] > Sent: Wednesday, October 13, 1999 9:32 PM > To: Richard M. Smith > Cc: guyd@uu.net; ipng@sunroof.eng.sun.com > Subject: Re: More misinformation on IPv6 > > > > Richard M. Smith wrote: > > The most likely scenario is when a Web site > > gets a hit, they can query other Web sites to find > > out what they know about the MAC address that comes > > in with the hit. My guess is that very quickly, market > > forces will produce some sort of central registry > > which can give out a name, Email address, phone #, > > etc. given a MAC address. > > > > Microsoft, for example, even started building > > just such a database with their Windows 98 Registration Wizard. > > So the problem already exists with IPv4, then, and is not IPv6 > specific as the BBC article claims. Also, isn't it relatively > easy to construct such databases for any people using the > Web with Java enabled in their browser, irrespective of underlying > hardware? > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ~~~~~~~~~ > Sam Manthorpe, SGI. tel: (650)933-2856 fax: (650)932-2856 > sm@engr.sgi.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 13 19:13:02 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9E2AHb01317 for ipng-dist; Wed, 13 Oct 1999 19:10:17 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9E2A3k01308 for ; Wed, 13 Oct 1999 19:10:04 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id TAA16801 for ; Wed, 13 Oct 1999 19:10:03 -0700 (PDT) Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id UAA29670 for ; Wed, 13 Oct 1999 20:10:02 -0600 (MDT) Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by crufty; Wed Oct 13 22:08:19 EDT 1999 Received: from dnrc.bell-labs.com (dhcp-6-168.pa.bell-labs.com [135.250.6.168]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id WAA05265; Wed, 13 Oct 1999 22:08:16 -0400 (EDT) Message-ID: <38053B71.D7D763D2@dnrc.bell-labs.com> Date: Wed, 13 Oct 1999 19:09:53 -0700 From: Grenville Armitage Organization: Bell Laboratories, Lucent Technologies X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Richard M. Smith" CC: ipng@sunroof.eng.sun.com Subject: Re: More misinformation on IPv6 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Richard M. Smith" wrote: [..] > My concern here is that Web sites will start building > databases that include people's MAC address. Which today they do using the entire IPv4 address. > MAC addresses will then allow Web sites to correlate > personal data using a common MAC address key. As with IPv4 addresses. And when a NAT box scrambles things, the fearful user's IP address is mangled - whether using v4 or v6. And when DHCP is used to assign addresses, the longterm uniqueness of the IP addresses collected by websites depends on DHCP Server policy - whether using v4 or v6. And when users are dial-up connected, same deal. Address-to-user associations are of a duration and obscurity dictated by the ISP. And when some other source of numbers is used for the bottom 64 bits, websites will still be able to correlate user behavior with their IPv6 address for as long as the source keeps the same lower 64 bits. All in all, nothing much new under the sun compared to v4. Except that a few reporters wanted a quick 'kill' over the IETF geeks, tripped over their shoelaces, and fell into the glassware cabinet in the process. Now we get to clean up the broken glass. cheers, gja -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 13 19:33:29 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9E2URj01392 for ipng-dist; Wed, 13 Oct 1999 19:30:27 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9E2UHk01385 for ; Wed, 13 Oct 1999 19:30:19 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id TAA18939 for ; Wed, 13 Oct 1999 19:30:17 -0700 (PDT) Received: from mailnfs0.tiac.net (mailnfs0.tiac.net [199.0.65.17]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA04962 for ; Wed, 13 Oct 1999 20:30:16 -0600 (MDT) Received: from rms (smiths.tiac.net [199.3.129.167]) by mailnfs0.tiac.net (8.8.8/8.8) with SMTP id WAA20317; Wed, 13 Oct 1999 22:30:13 -0400 (EDT) From: "Richard M. Smith" To: "Grenville Armitage" Cc: Subject: RE: More misinformation on IPv6 Date: Wed, 13 Oct 1999 22:30:26 -0400 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.2910.0) Importance: Normal In-Reply-To: <38053B71.D7D763D2@dnrc.bell-labs.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Grenville, > And when DHCP is used to assign addresses, the longterm > uniqueness of the IP addresses collected by websites depends > on DHCP Server policy - whether using v4 or v6. It sounds like everyone is complete agreement here. Always use DHCP to get the MAC addresses out of IPv6 addresses, and many of the new privacy concerns in IPv6 go away. At least then, the privacy problems don't get worse when we shift from IPv4 to IPv6. Richard -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 13 20:35:15 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9E3WL601495 for ipng-dist; Wed, 13 Oct 1999 20:32:21 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9E3WBk01488 for ; Wed, 13 Oct 1999 20:32:12 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id UAA22375 for ; Wed, 13 Oct 1999 20:32:10 -0700 (PDT) Received: from dfw-ix3.ix.netcom.com (dfw-ix3.ix.netcom.com [206.214.98.3]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA14876 for ; Wed, 13 Oct 1999 20:32:10 -0700 (PDT) Received: (from smap@localhost) by dfw-ix3.ix.netcom.com (8.8.4/8.8.4) id WAA21377; Wed, 13 Oct 1999 22:31:32 -0500 (CDT) Received: from dal-tx49-24.ix.netcom.com(198.211.45.152) by dfw-ix3.ix.netcom.com via smap (V1.3) id rma021166; Wed Oct 13 22:30:50 1999 Message-ID: <3804DE18.B6D4F4DB@ix.netcom.com> Date: Wed, 13 Oct 1999 20:31:39 +0100 From: Jeff Williams Organization: INEG. Inc. (Spokesman INEGroup) X-Mailer: Mozilla 4.08 [en] (Win16; I) MIME-Version: 1.0 To: Grenville Armitage CC: "Richard M. Smith" , ipng@sunroof.eng.sun.com, tbridis@ap.org Subject: Re: More misinformation on IPv6 References: <38053B71.D7D763D2@dnrc.bell-labs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Grenville and all, Nice piece of circular argument yourself here. Lets break it down a bit, shall we? >;) Grenville Armitage wrote: > "Richard M. Smith" wrote: > [..] > > My concern here is that Web sites will start building > > databases that include people's MAC address. > > Which today they do using the entire IPv4 address. True, but the individual user can control this presently in v4. With MAC's in v6 they will than become dependent on the service provider. Not a comforting though when it comes to privacy issues, is it? > > > > MAC addresses will then allow Web sites to correlate > > personal data using a common MAC address key. > > As with IPv4 addresses. Yes, but again this can be controlled by the user should they so choose to do so. Again you are oversimplifying the problem so as to strengthen your perspective instead of representing the plain cold facts in a tad bit more detail. Nice try here, but again no cigar! But I must say I admire you sense of deviousness! >;) > > > And when a NAT box scrambles things, the fearful user's > IP address is mangled - whether using v4 or v6. BUt this is not an assured occurrence in every instance, is it? So hardly comforting ore really relevant except in an occasional instance of two. Again Nice try, but again no cigar! >;) > > > And when DHCP is used to assign addresses, the longterm > uniqueness of the IP addresses collected by websites depends > on DHCP Server policy - whether using v4 or v6. Again this would depend of if, 1.) DHCP is being used at all, and 2.) As you say, the "Server Policy" and what criterion that policy is determined upon. Again hardly comforting. This should be a user determined decision, not some remote "Server Policy" set by their service provider. Hence this is paramount to bad design or design by political expediency. Nice try again, but again, no cigar! >;) > > > And when users are dial-up connected, same deal. Address-to-user > associations are of a duration and obscurity dictated by > the ISP. ANd this is really the crux of the debate, isn't it? The ISP/IAP makes the decision rather than the user due to a design flaw that doesn't allow for an opt out by the user. Bad idea, bad engineering. > > > And when some other source of numbers is used for the bottom > 64 bits, websites will still be able to correlate user > behavior with their IPv6 address for as long as the source > keeps the same lower 64 bits. > > All in all, nothing much new under the sun compared to v4. > Except that a few reporters wanted a quick 'kill' over > the IETF geeks, tripped over their shoelaces, and fell into > the glassware cabinet in the process. Now we get to clean up > the broken glass. ROFLMAO! As I have now pointed out yet again your conclusion is based on premises that are flawed and a design that is questionable, hence leaving this conclusion fallacious. > > > cheers, > gja > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- Regards, -- Jeffrey A. Williams Spokesman INEGroup (Over 95k members strong!) CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 972-447-1894 Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 13 23:55:00 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9E6qF501708 for ipng-dist; Wed, 13 Oct 1999 23:52:15 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9E6q3k01701 for ; Wed, 13 Oct 1999 23:52:04 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id XAA11505 for ; Wed, 13 Oct 1999 23:52:03 -0700 (PDT) Received: from inet-vrs-02.microsoft.com (mail2.microsoft.com [131.107.3.124]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id XAA24216 for ; Wed, 13 Oct 1999 23:52:03 -0700 (PDT) Received: from 157.54.9.104 by inet-vrs-02.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 13 Oct 1999 23:41:43 -0700 (Pacific Daylight Time) Received: by INET-IMC-02 with Internet Mail Service (5.5.2650.21) id <46W0T00G>; Wed, 13 Oct 1999 23:41:43 -0700 Message-ID: <3D2036E25376D31197A100805FEAD892712E82@x1red-msg-14.itg-messaging.redmond.corp.microsoft.com> From: Brian Zill To: "'Richard M. Smith'" , Guy Davies Cc: ipng@sunroof.eng.sun.com Subject: RE: More misinformation on IPv6 Date: Wed, 13 Oct 1999 23:41:37 -0700 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: Richard M. Smith [mailto:smiths@tiac.net] > > I looked over the BBC article and it seems fine to me. The BBC article states: "The new proposal is being made by the Internet Engineering Task Force (IETF), an international standards body. It would result in the inclusion of the unique serial number for each computer as part of its expanded new Internet protocol address." This statement is incorrect. RFC 2373, Section 2.5.1 (and also RFC 2374, Section 3.6) clearly state that the interface identifier portion of an IPv6 address is only required to be unique on the interface's local link. There is no requirement that each computer must have a unique serial number that never changes. I suspect most people on this list already understand this. What you're all arguing about is a "may" clause, one way out of many possible ways to form an interface identifier. How interface identifiers end up getting created in common practice is the real issue, I believe. (And even there the concern is primarily with end user machines, and not with the addresses of servers or routers.) There may or may not be a realistic privacy concern associated with this, opinions tend to vary with one's predictions of future common practices. So I'll refrain from commenting on that issue at this time. The concern I have that prompted this post is that some people are misrepresenting this issue as an IPv6 protocol flaw. It is not. It is an issue regarding how the protocol might be used in practice. The same issue is relevant (or not) with regards to how IPv4 addresses are used in practice today. The casual reader of the BBC article (or Frezza's column) is likely to come to mistaken conclusion that this is some new problem with IPv6 that is completely absent in IPv4. And thus may get the impression that IPv4 is somehow preferable to IPv6. I would hate for all the internet users (and network administrators!) of the world to miss out on all the great advances of IPv6 due to a misunderstanding propagated by hasty reporting and a small but vocal group of people with their own agenda. Especially since Thomas Narten's proposal has the potential to improve the privacy of IPv6 users over that of IPv4 users today. I suspect many other readers of this list share my concerns about IPv6 being misrepresented, and that this is the cause of much of the contention surrounding this issue on the list. It would be appreciated if the privacy advocates among us would help dispel such misconceptions about IPv6 in their conversations with reporters, rather than contributing to them. Cooperation is generally more productive than sniping from the sidelines (and also helps to identify those who are truly interested in achieving positive outcomes from those who merely want to snipe from the sidelines). Finally, it's worth noting that the BBC article also misrepresents Thomas's proposal as "manual configuration" (via placement of Thomas' quote immediately after a paragraph paraphrasing Fred Baker describing such). --Brian The opinions expressed in this message are my own and should not be taken as representative of Microsoft, the IPv6 Forum Tech Directorate, the ipv6.org web site, or any other company, group, person or inanimate object. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 14 00:42:53 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9E7e1a01778 for ipng-dist; Thu, 14 Oct 1999 00:40:01 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9E7dpk01771 for ; Thu, 14 Oct 1999 00:39:52 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id AAA14415 for ; Thu, 14 Oct 1999 00:39:51 -0700 (PDT) Received: from newman.itea.ntnu.no (newman.itea.ntnu.no [129.241.18.18]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA23743 for ; Thu, 14 Oct 1999 01:39:46 -0600 (MDT) Received: from alfa.itea.ntnu.no (alfa.itea.ntnu.no [129.241.18.10]) by newman.itea.ntnu.no (8.9.1/8.9.1) with ESMTP id IAA06578; Thu, 14 Oct 1999 08:39:33 +0100 (WET DST) From: Stig Venaas Received: (from venaas@localhost) by alfa.itea.ntnu.no (8.7.3/8.7.3) id JAA01049; Thu, 14 Oct 1999 09:40:03 +0200 (MET DST) Message-ID: <19991014094003.A737@itea.ntnu.no> Date: Thu, 14 Oct 1999 09:40:03 +0200 To: "Richard M. Smith" , Grenville Armitage Cc: ipng@sunroof.eng.sun.com Subject: Re: More misinformation on IPv6 References: <38053B71.D7D763D2@dnrc.bell-labs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from Richard M. Smith on Wed, Oct 13, 1999 at 10:30:26PM -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, Oct 13, 1999 at 10:30:26PM -0400, Richard M. Smith wrote: > Grenville, > > > And when DHCP is used to assign addresses, the longterm > > uniqueness of the IP addresses collected by websites depends > > on DHCP Server policy - whether using v4 or v6. > > It sounds like everyone is complete agreement > here. Always use DHCP to get the MAC addresses out of IPv6 > addresses, and many of the new privacy concerns in IPv6 > go away. At least then, the privacy problems don't > get worse when we shift from IPv4 to IPv6. I think it would be good to have fixed link-local address and perhaps site-local addresses. That should make life easier for local system and network administrators and also for DHCP I think. For the global address it would be nice to have both a fixed one and an ever changing one. When it initiates communication with other hosts it could then use the changing one, while it also is reachable at the fixed address which is important for many applications. Since not all have the same preferences as me, most of this should be configurable. It might be important that implementations choose the "right" defaults though. Most of this is noted in the draft and is an implementation issue. As with IPv4 it's perfectly possible to implement things in a bad way, and some will. Stig -- Stig Venaas UNINETT/NTNU -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 14 00:44:24 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9E7hFC01796 for ipng-dist; Thu, 14 Oct 1999 00:43:15 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9E7h1k01782 for ; Thu, 14 Oct 1999 00:43:02 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id AAA05255 for ; Thu, 14 Oct 1999 00:43:01 -0700 (PDT) Received: from dfw-ix12.ix.netcom.com (dfw-ix12.ix.netcom.com [206.214.98.12]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA05051 for ; Thu, 14 Oct 1999 00:43:01 -0700 (PDT) Received: (from smap@localhost) by dfw-ix12.ix.netcom.com (8.8.4/8.8.4) id CAA09352; Thu, 14 Oct 1999 02:42:26 -0500 (CDT) Received: from dal-tx61-49.ix.netcom.com(207.221.95.49) by dfw-ix12.ix.netcom.com via smap (V1.3) id rma009268; Thu Oct 14 02:42:04 1999 Message-ID: <380518F8.D324F4EC@ix.netcom.com> Date: Thu, 14 Oct 1999 00:42:51 +0100 From: Jeff Williams Organization: INEG. Inc. (Spokesman INEGroup) X-Mailer: Mozilla 4.08 [en] (Win16; I) MIME-Version: 1.0 To: Brian Zill CC: "'Richard M. Smith'" , Guy Davies , ipng@sunroof.eng.sun.com Subject: Re: More misinformation on IPv6 References: <3D2036E25376D31197A100805FEAD892712E82@x1red-msg-14.itg-messaging.redmond.corp.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian and all, Over all I agree with your sentiment at least. Looking for more positive solutions and insuring that there is absolutely NO privacy or security holes in IPv6 would be the best and most productive direction everyone can take. Now after stating that, and hoping that there is a renewed real interest in a positive direction, I do have some legitimate concerns regarding the TONE or some of you remaining comments. (See below your comments for those concerns). Brian Zill wrote: > > From: Richard M. Smith [mailto:smiths@tiac.net] > > > > I looked over the BBC article and it seems fine to me. > > The BBC article states: > "The new proposal is being made by the Internet Engineering Task Force > (IETF), an international standards body. It would result in the inclusion of > the unique serial number for each computer as part of its expanded new > Internet protocol address." > > This statement is incorrect. RFC 2373, Section 2.5.1 (and also RFC 2374, > Section 3.6) clearly state that the interface identifier portion of an IPv6 > address is only required to be unique on the interface's local link. There > is no requirement that each computer must have a unique serial number that > never changes. Right, it is not a requirement at the local link interface, but it is a possible implementation. That should not be the case as it opens up Pandora's Box, so to speak. > > > I suspect most people on this list already understand this. > > What you're all arguing about is a "may" clause, one way out of many > possible ways to form an interface identifier. How interface identifiers > end up getting created in common practice is the real issue, I believe. > (And even there the concern is primarily with end user machines, and not > with the addresses of servers or routers.) There may or may not be a > realistic privacy concern associated with this, opinions tend to vary with > one's predictions of future common practices. So I'll refrain from > commenting on that issue at this time. May not be a realistic privacy concern??? There definitely is a privacy concern and you pointed it out in your paragraph just before this one above. And "May not be" is not good enough. > > > The concern I have that prompted this post is that some people are > misrepresenting this issue as an IPv6 protocol flaw. It is not. It is an > issue regarding how the protocol might be used in practice. Well that is a flaw by definition. Not a feature. >;) > The same issue > is relevant (or not) with regards to how IPv4 addresses are used in practice > today. No this is not really the case at all. At the client level this problem can be dealt with by the user themselves. Not true with the current spec on IPV6. > > > The casual reader of the BBC article (or Frezza's column) is likely to come > to mistaken conclusion that this is some new problem with IPv6 that is > completely absent in IPv4. And thus may get the impression that IPv4 is > somehow preferable to IPv6. Well IPv4 is not preferable to IPv6 just because of a privacy concern, nor should it be viewed as such. But it is easy to see how from a business perspective where that perception could be taken given this "Flaw" in the IPv6 spec. > I would hate for all the internet users (and > network administrators!) of the world to miss out on all the great advances > of IPv6 due to a misunderstanding propagated by hasty reporting and a small > but vocal group of people with their own agenda. Especially since Thomas > Narten's proposal has the potential to improve the privacy of IPv6 users > over that of IPv4 users today. > > I suspect many other readers of this list share my concerns about IPv6 being > misrepresented, and that this is the cause of much of the contention > surrounding this issue on the list. It would be appreciated if the privacy > advocates among us would help dispel such misconceptions about IPv6 in their > conversations with reporters, rather than contributing to them. Cooperation > is generally more productive than sniping from the sidelines (and also helps > to identify those who are truly interested in achieving positive outcomes > from those who merely want to snipe from the sidelines). > > Finally, it's worth noting that the BBC article also misrepresents Thomas's > proposal as "manual configuration" (via placement of Thomas' quote > immediately after a paragraph paraphrasing Fred Baker describing such). > > --Brian > > The opinions expressed in this message are my own and should not be taken as > representative of Microsoft, the IPv6 Forum Tech Directorate, the ipv6.org > web site, or any other company, group, person or inanimate object. > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- Regards, -- Jeffrey A. Williams Spokesman INEGroup (Over 95k members strong!) CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 972-447-1894 Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 14 01:24:58 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9E8M6201871 for ipng-dist; Thu, 14 Oct 1999 01:22:06 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9E8Lvk01864 for ; Thu, 14 Oct 1999 01:21:58 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id BAA07470 for ; Thu, 14 Oct 1999 01:21:56 -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 CAA05363 for ; Thu, 14 Oct 1999 02:21:56 -0600 (MDT) Received: from new (slip139-92-111-27.gen.ch.prserv.net [139.92.111.27]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with ESMTP id BAA10666; Thu, 14 Oct 1999 01:21:53 -0700 (PDT) Message-Id: <4.2.0.58.19991014012034.03c151d0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 14 Oct 1999 01:21:22 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: Re: Slides from Tokyo IPng Meeting In-Reply-To: <4.2.0.58.19991011133744.00b3c6b0@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 I added three more presentations from the meeting. Bob At 01:41 PM 10/11/99 -0700, Bob Hinden wrote: >Presentations (in pdf) from the Tokyo IPng meeting are now available on: > > http://playground.sun.com/pub/ipng/html/meetings.html > >It includes the chairs summary and action items. > >The minutes are being edited and should be available later this week. > >Bob > >p.s. If you gave a presentation at the meeting and have not sent me your >slides, please do. If you sent them and do they do not appear please >resend them. I had some email problems when I got back and may have lost them. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 14 01:43:25 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9E8f7L01932 for ipng-dist; Thu, 14 Oct 1999 01:41:07 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9E8evk01925 for ; Thu, 14 Oct 1999 01:40:58 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id BAA17376 for ; Thu, 14 Oct 1999 01:40:56 -0700 (PDT) Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.211]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA10046 for ; Thu, 14 Oct 1999 02:40:55 -0600 (MDT) Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.9.1a/8.9.1) id KAA02234; Thu, 14 Oct 1999 10:39:26 +0200 (MET DST) Message-ID: <19991014103926.A2111@theory.cs.uni-bonn.de> Date: Thu, 14 Oct 1999 10:39:26 +0200 From: Ignatios Souvatzis To: Jeff Williams , Brian Zill Cc: "'Richard M. Smith'" , Guy Davies , ipng@sunroof.eng.sun.com Subject: Re: More misinformation on IPv6 References: <3D2036E25376D31197A100805FEAD892712E82@x1red-msg-14.itg-messaging.redmond.corp.microsoft.com> <380518F8.D324F4EC@ix.netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <380518F8.D324F4EC@ix.netcom.com>; from Jeff Williams on Thu, Oct 14, 1999 at 12:42:51AM +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, Oct 14, 1999 at 12:42:51AM +0100, Jeff Williams wrote: > Over all I agree with your sentiment at least. Looking for more > positive solutions and insuring that there is absolutely NO > privacy or security holes in IPv6 would be the best and most > productive direction everyone can take. Jeff, _This_ _cant_ _be_ _done_. As long as people use unicast protocols to access information, be it telephone, TCP, or an ATM circuit, the return address _has_ _to_ be included, and _is_ somehow trackable. Even if people use a random source address, routable by their ISP, for each access, it will be within their ISPs local address block. This is true for IPv4 as well as IPv6. There are two problems resulting from this: a) the ISP can map a (timestamp, sourceaddress) pair to a customer. He _needs_ to be able to do this during the connection (well, actually, he does the reverse; he mapps a customer to an address he assings her) for accounting purpuses. a1) Furthermore, some governments have (at least tried to) force the ISPs to keep this mapping information available in a database and at least accessible by government agencies (e.g., the former German government.) a2) Even if they did not, nothing but a rule not to do so and willing not to break such a rule (self-given or a law) will prevent an ISP from selling said database to interested, err, third parties. b) Even if a1 and a2 do NOT apply, interested WWW services can get statistical information about a certain ISPs customers. c) A variant of a2 is to sell the (partial) log of the proxy requests. Neither Bill Frezza nor you ever addressed a1), a2) or b), as far as I can tell. They are not technical. They apply to IPv4 as well as IPv6 as well as telephone connections. The only way out is to use multicasting protocols (e.g., Radio wave broadcasting or Usenet. IPv4 multicasting (and I guess, IPv6) comes near, as multicast routing requests won't propagate to near the source in most cases, but isn't perfect. Regards, -is -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 14 03:49:19 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9EAkKc02065 for ipng-dist; Thu, 14 Oct 1999 03:46:20 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9EAkAk02058; Thu, 14 Oct 1999 03:46:11 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id DAA11364; Thu, 14 Oct 1999 03:46:07 -0700 (PDT) Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA10463; Thu, 14 Oct 1999 03:46:07 -0700 (PDT) Received: from assan (assan.imag.fr [129.88.31.17]) by imag.imag.fr (8.9.3/8.8.5) with ESMTP id QAA15540; Wed, 13 Oct 1999 16:34:28 +0200 (MET DST) Message-Id: <4.2.0.58.19991013144955.00a62eb0@brahma.imag.fr> X-Sender: durand@brahma.imag.fr X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 13 Oct 1999 15:39:43 +0200 To: Erik Nordmark , Brian E Carpenter From: Alain Durand Subject: source and destintion address selection algorithm Cc: ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com In-Reply-To: References: <"Your message with ID" <38030BF0.BA6FA3AD@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'm copying this to IPng mailling list. At 08:59 12/10/99 -0700, Erik Nordmark wrote: > > The consequence of what you and Alain are saying is going to > > be a host configuration option for "prefer 6to4" versus "prefer native" > > in case that both are available. Do we really want another > > config option? If yes, the words are easy to write. > >I personally don't think we need to configuration option, but >others might think the order should be different. > >My order is: >1. If both the source and destination have at least one native IPv6 >address use > IPv6 native source and destination. 2. If both the source and destination >have (at least one) 6to4 address use > 6to4 source and destination addresses. >3. If both the source and destination have (at least one) IPv4-compatible > addresses (remember that automatic tunneling stuff) use > IPv4-compatible source and destination addresses. > >In the above "native" means addresses that are not 6to4, not IPv4-compatible, >and not IPv4-mapped. I think we can generalized this order with the following algorithm to select both source and destination address. Lets define the precedence prec of an address as the following function prec(link local) = 10 prec(site local) = 20 prec(native-v6 global, non 6to4) = 30 prec(native-V6 global, 6to4) = 35 prec(IPv4 compatible) = 50 Note: those are suggested default value. They can be override manually by configuration options if one does not like this specific order. 0. Consider the set of all possible source addresses and the set of all possible destination addresses, 1. Select destination address dst with the lowest precedence prec(dst) 2. If several destination addresses are still available, one may pick the first one returned by the DNS or use random selection. 3. Select src in this order: - one with the same precedence as prec(dst) - if impossible, one with the lowest precedence and prec(src) > prec(dst) - if impossible, one with the highest precedence 4. If several source addresses are still available, longest prefix match with the selected destination address or random selection may be used. 5. If the communication failed because the destination address is unreachable (scope too small for example), remove dst from the set of possible destination addresses and reiterate at step 1. In the case of a simple application that select the first address returned by the DNS and let the kernel fix the source address, step 3 & 4 of this algorithm can be used by the kernel. - Alain. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 14 03:53:32 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9EAqOO02099 for ipng-dist; Thu, 14 Oct 1999 03:52:24 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9EAqFk02092; Thu, 14 Oct 1999 03:52:16 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id DAA14258; Thu, 14 Oct 1999 03:52:14 -0700 (PDT) Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA10368; Thu, 14 Oct 1999 04:52:12 -0600 (MDT) Received: from assan (assan.imag.fr [129.88.31.17]) by imag.imag.fr (8.9.3/8.8.5) with ESMTP id MAA18461; Thu, 14 Oct 1999 12:52:10 +0200 (MET DST) Message-Id: <4.2.0.58.19991014111401.00a65dc0@brahma.imag.fr> X-Sender: durand@brahma.imag.fr X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 14 Oct 1999 12:51:02 +0200 To: Erik Nordmark , ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com From: Alain Durand Subject: update on src/dst selection algorithm Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I've tried to modify my algorithm to integrate Erik's comment. The interesting thing is that it is generic enough and can be extended easily to other class of addresses. Lets define the precedence prec of an address as the following function prec(link local) = 10 prec(site local) = 20 prec(native-v6 global, non 6to4) = 30 prec(native-V6 global, 6to4) = 35 prec(IPv4 compatible) = 50 Note1: those are suggested default value. They can be override manually by configuration options if one does not like this specific order. Note2: we are only considering valid, non deprecated addresses. 0. Consider the set P0 of all possible pairs source x destination addresses, 1. Consider the subset P1 of P0 of all possible pairs source x destination so that prec(source) = prec(destination) 2. If P1 is not empty, there is a least a match of precedence between source and destination 2.0 Let LP be the lowest precedence of all pairs 2.1. Consider the subset P2 of P1 of all pairs source x destination of precedence LP 2.2. If P2 is not reduce to a single pair, choose either - longest prefix match - DNS order for dst - random selection 3. If P1 is empty, there is no match of precedence between source and destination, communication may actually not be possible, we have some heuristic to try to connect. 3.0 Consider D0 the set of all possible destination addresses 3.1 Consider the subset D1 of D0 of destination addresses dst of the lowest precedence prec(dst) 3.2 If D1 is not reduced to one address, one may pick the first one returned by the DNS or use random selection. 3.3 Consider S0 the set of all possible source addresses 3.4 Consider the subset S1 of S0 of all possible source addresses of precedence > prec(dst) 3.5 If S1 is not empty, 3.5.0 Consider S2 the subset of S1 of source addresses of the lowest precedence 3.5.1 If S2 is not reduced to one address, one may use longest prefix match with dst or random selection. 3.6 If S1 is empty 3.6.0 Consider S3 the subset of S1 of source addresses of the highest precedence 3.6.1 If S3 is not reduced to one address, one may use longest prefix match with dst or random selection. 3.7 If the communication failed (scope too small for example), remove dst from the subset D0 and reiterate at step 3.1. In the case of a simple application that select the first address returned by the DNS and let the kernel fix the source address, this algorithm can still be used by the kernel with only one destination address. - Alain. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 14 04:04:00 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9EB1A102136 for ipng-dist; Thu, 14 Oct 1999 04:01:10 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9EB0wk02129 for ; Thu, 14 Oct 1999 04:00:59 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id EAA14695 for ; Thu, 14 Oct 1999 04:00:58 -0700 (PDT) Received: from inet-vrs-02.microsoft.com (mail2.microsoft.com [131.107.3.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id FAA12781 for ; Thu, 14 Oct 1999 05:00:57 -0600 (MDT) Received: from 157.54.9.104 by inet-vrs-02.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 14 Oct 1999 04:00:32 -0700 (Pacific Daylight Time) Received: by INET-IMC-02 with Internet Mail Service (5.5.2650.21) id <46W04PLC>; Thu, 14 Oct 1999 04:00:32 -0700 Message-ID: <3D2036E25376D31197A100805FEAD892712E84@x1red-msg-14.itg-messaging.redmond.corp.microsoft.com> From: Brian Zill To: ipng@sunroof.eng.sun.com Subject: Treatment of scoped addresses carried in extension headers Date: Thu, 14 Oct 1999 04:00:51 -0700 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Recently I've been working on adding better support for scoped addresses to our stack. And while it's fairly clear how to treat scoped addresses when they're presented along with a scope id, it is less clear how they should be treated when they are not. (For simplicity and the purposes of this message, you can take "scoped addresses" to mean link-local and site-local unicast addresses) When presented by a user, for example in a sockaddr_in6, a scoped address is accompanied by a scope id which identifies the particular instance of a scope (I'm told Steve Deering has proposed the term "zone" for this concept) in which the address is meaningful. When encountered in a packet on the wire, however, a scoped address has no accompanying scope id. This is not a problem for the Source and Destination addresses present in the base IPv6 header, since the routing system should prevent packets with scoped addresses in these fields from leaving their zone. (Their zone can thus be determined by the link they are encountered on, since they can't leave their zone) But what about scoped addresses in extension headers? For example, in routing headers and mobility options? Since they are not hop-by-hop options, routers will never look at them, and packets containing such could easily leave the zone in which their embedded scoped addresses are meaningful. Nothing I could find in the current specs mentions how to treat scoped addresses when present in these sorts of headers. I can see three actions a node could take upon encountering such a header. I can also see arguments for and against each one. 1) Treat the scoped address as meaningful in the zone that the interface the packet arrived on belongs to. This has the advantage of being simple to implement and the disadvantage that in order to be useful, the originator of the header would need detailed (?) information about the network topology. In the absence of such information, the packet could easily be interpreted incorrectly. One could also argue that allowing remote nodes to send to a local node that only has a link-local address via clever use of a routing header is a security problem. Others might see this as a handy feature. 2) This one only applies to multi-homed (or multi-sited) nodes. Take a best (?) guess as to the zone the address might be meaningful in, or try them all (the latter is only feasible with some types of extension headers). This has the advantage that it is more likely the address will be interpreted correctly, but at the risk that it might be interpreted incorrectly. For example, with a routing header, this might result in a packet being delivered to one or more wrong recipients. 3) Treat scoped addresses as illegal in such headers and drop the packet. This also has the advantage of being easy to implement, and is probably the most defensible choice since the prescribed behavior is always clear and unambiguous. But it has the disadvantage that it prevents some possible methods of using the protocol (I can imagine some mobility scenarios where you might want to have a scoped care-of address or a scoped home address, for example). It also has the disadvantage that we'd need to update some specs. Comments? Has this been discussed before and I missed it? --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 14 06:09:09 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9ED67t02274 for ipng-dist; Thu, 14 Oct 1999 06:06:07 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9ED5xk02267 for ; Thu, 14 Oct 1999 06:05:59 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id GAA19046 for ; Thu, 14 Oct 1999 06:05:59 -0700 (PDT) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA16917 for ; Thu, 14 Oct 1999 06:59:58 -0600 (MDT) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id OAA18848; Thu, 14 Oct 1999 14:58:58 +0200 (MET DST) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id OAA17306; Thu, 14 Oct 1999 14:58:57 +0200 (MET DST) Message-Id: <199910141258.OAA17306@givry.inria.fr> From: Francis Dupont To: Brian Zill cc: ipng@sunroof.eng.sun.com Subject: Re: Treatment of scoped addresses carried in extension headers In-reply-to: Your message of Thu, 14 Oct 1999 04:00:51 PDT. <3D2036E25376D31197A100805FEAD892712E84@x1red-msg-14.itg-messaging.redmond.corp.microsoft.com> Date: Thu, 14 Oct 1999 14:58:57 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Comments? Has this been discussed before and I missed it? => I have in my TODO list a similar comment about a proposed API for scoped addresses. For instance a RSVP or IKE tool (daemon in Unix :-) should use scoped addresses (ie. a structure with an address and a scope ID in place of an address only). Francis.Dupont@inria.fr PS: I am not (yet) convinced by your argument but I know an example of a (then not usable) link-local address without a scope ID (ie. an interface index) in a proposed protocol: DHCPv6. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 14 06:20:00 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9EDH7J02308 for ipng-dist; Thu, 14 Oct 1999 06:17:07 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9EDGuk02298 for ; Thu, 14 Oct 1999 06:16:56 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id GAA19805 for ; Thu, 14 Oct 1999 06:16:57 -0700 (PDT) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id HAA22242 for ; Thu, 14 Oct 1999 07:16:56 -0600 (MDT) Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 14 Oct 1999 06:11:24 -0700 (Pacific Daylight Time) Received: by INET-IMC-03 with Internet Mail Service (5.5.2650.21) id <454GTTY8>; Thu, 14 Oct 1999 06:11:24 -0700 Message-ID: <3D2036E25376D31197A100805FEAD892712E85@x1red-msg-14.itg-messaging.redmond.corp.microsoft.com> From: Brian Zill To: "'Jeff Williams'" Cc: "'Richard M. Smith'" , "'Guy Davies'" , "'ipng@sunroof.eng.sun.com'" Subject: RE: More misinformation on IPv6 Date: Thu, 14 Oct 1999 06:11:42 -0700 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Before someone dings me on this, I'd like to add this addendum to my last post. I was trying not to be too pedantic and ended up under-specifying. I shouldn't be attempting to think this late in my day. > From: Brian Zill > > The IPv6 specifications > allow for, and every IPv6 stack implementation > that I've seen provides the capability for, the end user to > manually set their address to whatever they want. There are a lot of caveats to "whatever they want" above. Both IPv4 and IPv6 have reserved addresses or prefixes for things like loopback, multicast, broadcast (in the case of v4), etc. The registries care about what you use for the upper bits if you want to join the global Internet. And both IPv4 and IPv6 require that the part of the address that identifies the end host on the local link (varies with the subnet mask for v4, called the interface identifier in v6) be locally unique, etc. The important take-away point was that both IPv4 and IPv6 allow the end host identifier part of the address to be user specified. And users can change their address at any time, v6 users just have a lot more bits to play with. Getting packets routed to them is another matter, but again, this is just like v4. --Brian Usual disclaimers apply. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 14 06:28:24 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9EDR0E02339 for ipng-dist; Thu, 14 Oct 1999 06:27:00 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9EDQnk02332 for ; Thu, 14 Oct 1999 06:26:49 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id GAA01664 for ; Thu, 14 Oct 1999 06:26:50 -0700 (PDT) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id HAA25304 for ; Thu, 14 Oct 1999 07:26:49 -0600 (MDT) Received: from 157.54.9.101 by mail1.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 14 Oct 1999 03:59:07 -0700 (Pacific Daylight Time) Received: by INET-IMC-01 with Internet Mail Service (5.5.2650.21) id <46WR8BH6>; Thu, 14 Oct 1999 03:59:06 -0700 Message-ID: <3D2036E25376D31197A100805FEAD892712E83@x1red-msg-14.itg-messaging.redmond.corp.microsoft.com> From: Brian Zill To: "'Jeff Williams'" Cc: "'Richard M. Smith'" , Guy Davies , ipng@sunroof.eng.sun.com Subject: RE: More misinformation on IPv6 Date: Thu, 14 Oct 1999 03:59:28 -0700 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Jeff, > From: Jeff Williams [mailto:jwkckid1@ix.netcom.com] > > Over all I agree with your sentiment at least. Glad to hear my message was received in the spirit it was intended. > Looking for more positive solutions and insuring > that there is absolutely NO privacy or security > holes in IPv6 would be the best and most > productive direction everyone can take. As Ignatios Souvatzis has already pointed out, absolutes are often impossible to achieve outside of an ideal world. IETF working groups are definitely not an ideal world :-). Since they are open to all comers, they are often necessarily creatures of compromise. Sometimes the goals inherently conflict. By posting here you are contributing, and positive suggestions that may lead to real solutions are appreciated. > > What you're all arguing about is a "may" clause, > > one way out of many possible ways to form an > > interface identifier. How interface identifiers > > end up getting created in common practice is the > > real issue, I believe. (And even there the concern > > is primarily with end user machines, and not > > with the addresses of servers or routers.) There > > may or may not be a realistic privacy concern > > associated with this, opinions tend to vary with > > one's predictions of future common practices. > > So I'll refrain from commenting on that issue > > at this time. > > May not be a realistic privacy concern??? > There definitely is a privacy concern and you > pointed it out in your paragraph just before this > one above. And "May not be" is not good enough. I believe you misunderstand me. The "may or may not" in my statement above depends upon the individual's prediction of future common practices. To pick an extreme example, if one predicts that no one will ever form their interface identifiers from MAC addresses, than it is clearly impossible in that future scenario for such things to be a privacy concern. If you have a different opinion, than presumably you have a different prediction of future common practices. I'm not trying to claim any particular prediction of the future is correct (if I was good at predicting the future, I'd be a stock trader, not a programmer :-). > > The concern I have that prompted this post > > is that some people are misrepresenting this > > issue as an IPv6 protocol flaw. It is not. > > It is an issue regarding how the protocol > > might be used in practice. > > Well that is a flaw by definition. Not a feature. >;) No, it IS a feature. Denying a capability to the entire set of possible users, simply because a particular subset doesn't wish to utilize that capability, is often viewed by those not in that particular subset as an unreasonable restriction. For example. There are many companies in the world today which don't provide (or whose policies don't allow) external access to the public Internet for their employees' personal use. Such a company may legitimately desire, for convenience or asset management reasons, to allocate all of its internal IPv6 addresses using embedded MAC addresses. The privacy concern that Richard Smith outlined doesn't appear to exist is this situation. This is a company that just wants to use its own private property in a way that is convenient for it to do so. Why should the IETF forbid such a thing? > > The same issue is relevant (or not) with regards > > to how IPv4 addresses are used in practice today. > > No this is not really the case at all. At the > client level this problem can be dealt with by the > user themselves. Not true with the current > spec on IPV6. I don't follow you, and I'm very familiar with the specifications of both IPv4 and IPv6. The IPv6 specifications allow for, and every IPv6 stack implementation that I've seen provides the capability for, the end user to manually set their address to whatever they want. --Brian The opinions I've expressed in this message are my own and should not be taken as representative of Microsoft, the IPv6 Forum Tech Directorate, the ipv6.org web site, or any other company, group, person or inanimate object. > -- > Jeffrey A. Williams > Spokesman INEGroup (Over 95k members strong!) > CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. > Information Network Eng. Group. INEG. INC. > E-Mail jwkckid1@ix.netcom.com > Contact Number: 972-447-1894 > Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 14 06:55:14 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9EDqEg02423 for ipng-dist; Thu, 14 Oct 1999 06:52:14 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9EDq2k02416 for ; Thu, 14 Oct 1999 06:52:03 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id GAA27191 for ; Thu, 14 Oct 1999 06:52:03 -0700 (PDT) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA25771 for ; Thu, 14 Oct 1999 06:52:02 -0700 (PDT) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id IAA24747; Thu, 14 Oct 1999 08:52:01 -0500 (CDT) Message-Id: <199910141352.IAA24747@gungnir.fnal.gov> To: ipng@sunroof.eng.sun.com, namedroppers@internic.net From: "Matt Crawford" Subject: Re: draft-ietf-ipngwg-dns-lookups-04.txt In-reply-to: Your message of Wed, 13 Oct 1999 09:19:38 +0200. <199910130719.JAA09809@givry.inria.fr> Date: Thu, 14 Oct 1999 08:52:01 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Francis dit: > => about ordering, something is not specified: when an address is > searched for a not fully qualified domain name then there is a search > for IPv4/A and IPv6/AAAA/A6 and in the search list (the list of domains, > usually initialised with the local domain name). > Should we do IP version or domain first? Let me restate the situation. The user refers to short-form name H, and the resolver is configured to search domains D1, ..., Dn. As I see it, the FQDN the user is implicitly naming is the first one which *exists* from the sequence H.D1, ..., H.Dn. Then the resolver gives back whatever suitable records are listed for that FQDN, or some sort of error if there are none. > I believe many implementations do domain first, ie. for instance > look for an AAAA RR for the name completed with search list > elements then if nothing is found try the same thing for an A RR. This isn't the same as what I presumed above. Which more closely matches the behavior of existing implementations? If in a v4-only world I type "telnet H" and H.D1 exists but has no A record, but H.D2 has an A record, what happens? Matt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 14 07:03:34 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9EE1hk02449 for ipng-dist; Thu, 14 Oct 1999 07:01:43 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9EE1Vk02442 for ; Thu, 14 Oct 1999 07:01:34 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA22781 for ; Thu, 14 Oct 1999 07:01:32 -0700 (PDT) Received: from dfw-ix7.ix.netcom.com (dfw-ix7.ix.netcom.com [206.214.98.7]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA29142 for ; Thu, 14 Oct 1999 07:01:31 -0700 (PDT) Received: (from smap@localhost) by dfw-ix7.ix.netcom.com (8.8.4/8.8.4) id IAA13996; Thu, 14 Oct 1999 08:59:55 -0500 (CDT) Received: from dal-tx46-36.ix.netcom.com(198.211.44.164) by dfw-ix7.ix.netcom.com via smap (V1.3) id rma013734; Thu Oct 14 08:59:05 1999 Message-ID: <38057153.1A484345@ix.netcom.com> Date: Thu, 14 Oct 1999 06:59:50 +0100 From: Jeff Williams Organization: INEG. Inc. (Spokesman INEGroup) X-Mailer: Mozilla 4.08 [en] (Win16; I) MIME-Version: 1.0 To: Ignatios Souvatzis CC: Brian Zill , "'Richard M. Smith'" , Guy Davies , ipng@sunroof.eng.sun.com Subject: Re: More misinformation on IPv6 References: <3D2036E25376D31197A100805FEAD892712E82@x1red-msg-14.itg-messaging.redmond.corp.microsoft.com> <380518F8.D324F4EC@ix.netcom.com> <19991014103926.A2111@theory.cs.uni-bonn.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ignatios and all, Ignatios Souvatzis wrote: > On Thu, Oct 14, 1999 at 12:42:51AM +0100, Jeff Williams wrote: > > > Over all I agree with your sentiment at least. Looking for more > > positive solutions and insuring that there is absolutely NO > > privacy or security holes in IPv6 would be the best and most > > productive direction everyone can take. > > Jeff, > > _This_ _cant_ _be_ _done_. I appreciate your frustration, but respectfully I don't agree with your comment here, and know that it CAN BE DONE. In fact our "Interface Facility" provides for this to the user level. > > > As long as people use unicast protocols to access information, be it telephone, > TCP, or an ATM circuit, the return address _has_ _to_ be included, and _is_ > somehow trackable. Yes but that access information much like Caller ID Blocking, can be and is being achieved now, all be it and a different layer, which was really forced upon us anyway as the IPV6 spec does not provide for this option presently, yet some sorts of implementations will in effect allow for some of protection similar to this to occur as has been pointed out on similar posts on this thread. > > > Even if people use a random source address, routable by their ISP, for each > access, it will be within their ISPs local address block. This is true for > IPv4 as well as IPv6. Right, and this is a sort of work around that is only somewhat addressing the problem. > > > There are two problems resulting from this: > > a) the ISP can map a (timestamp, sourceaddress) pair to a customer. He _needs_ > to be able to do this during the connection (well, actually, he does the > reverse; he mapps a customer to an address he assings her) for accounting > purpuses. Or the purposes of accounting it depends on what sort of billing method that ISP is going to do if this needs to be done. If they are doing flat rate billing than this is not necessary for billing purposes. > > > a1) Furthermore, some governments have (at least tried to) force the > ISPs to keep this mapping information available in a database and at least > accessible by government agencies (e.g., the former German government.) Yes they have, and they have failed. They have tried to codify this into law as well, and here too they have failed by in large, even the German government eventually failed. > > > a2) Even if they did not, nothing but a rule not to do so and willing not to > break such a rule (self-given or a law) will prevent an ISP from selling > said database to interested, err, third parties. Your are right here and this is one of the single biggest concerns and potential harms to the unsuspecting customer or user. That is why these security and privacy holes must not be allowed or designed in the spec, or at the very least provide for an opt out on the client side. > > > b) Even if a1 and a2 do NOT apply, interested WWW services can get statistical > information about a certain ISPs customers. Yes about "Certian" ISP customers, but not about all if a proper implementation is done on the ISP side or an opt out is provided on the client side. > > > c) A variant of a2 is to sell the (partial) log of the proxy requests. Yep, and a bd thing this certainly is! Not only that it is in violation of the privacy act as well. > > > Neither Bill Frezza nor you ever addressed a1), a2) or b), as far as I > can tell. They are not technical. They apply to IPv4 as well as IPv6 > as well as telephone connections. Yes I did and on more than one occasion. I have just done so again in this post as well. > > > The only way out is to use multicasting protocols (e.g., Radio wave > broadcasting or Usenet. IPv4 multicasting (and I guess, IPv6) comes near, > as multicast routing requests won't propagate to near the source in most > cases, but isn't perfect. > > Regards, > -is Regards, -- Jeffrey A. Williams Spokesman INEGroup (Over 95k members strong!) CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 972-447-1894 Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 14 07:24:33 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9EELTG02484 for ipng-dist; Thu, 14 Oct 1999 07:21:29 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9EELJk02477 for ; Thu, 14 Oct 1999 07:21:20 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA24428 for ; Thu, 14 Oct 1999 07:21:19 -0700 (PDT) Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.198.195]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA15474 for ; Thu, 14 Oct 1999 08:21:19 -0600 (MDT) Received: from [10.19.130.188] (deering-dsl3.cisco.com [10.19.130.188]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id HAA18093; Thu, 14 Oct 1999 07:21:16 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: In-Reply-To: <3D2036E25376D31197A100805FEAD892712E84@x1red-msg-14.itg-messaging.redmond .corp.microsoft.com> References: <3D2036E25376D31197A100805FEAD892712E84@x1red-msg-14.itg-messaging.redmond .corp.microsoft.com> Date: Thu, 14 Oct 1999 07:21:19 -0700 To: Brian Zill From: Steve Deering Subject: Re: Treatment of scoped addresses carried in extension headers Cc: ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 4:00 AM -0700 10/14/99, Brian Zill wrote: >But what about scoped addresses in extension headers? For example, in >routing headers and mobility options? ... > >I can see three actions a node could take upon encountering such a header. >I can also see arguments for and against each one. > >1) Treat the scoped address as meaningful in the zone that the interface the >packet arrived on belongs to. This has the advantage of being simple to >implement and the disadvantage that in order to be useful, the originator of >the header would need detailed (?) information about the network topology. >In the absence of such information, the packet could easily be interpreted >incorrectly. This is the approach I prefer. (No, the "correct" behavior has never been decided or written down.) In order to construct a useful Routing header or mobility option, one needs a certain amount of (not necessarily "detailed") topological information anyway, so my inclination is to assume that the sender knows what he/she/it is doing and is operating under the assumption that receivers behave according to your suggestion number (1). If senders do something meaningless, they will get meaningless behavior in response. > One could also argue that allowing remote nodes to send to a >local node that only has a link-local address via clever use of a routing >header is a security problem. Others might see this as a handy feature. One shouldn't think of scoped addresses as giving you security against unwanted traffic arriving from outside a zone. There are many ways such traffic can arrive, including higher-layer forwarding (e.g., transport layer proxies, application-level relays, etc.) We cannot write a practical spec on how to filter out all such behaviors. The only security property one should assume of scoped addresses is that packets containing a scoped source or destination address, sent from well-behaved senders (i.e., senders that don't try to play tricks with routing headers, etc.), will not leave the zone of the smaller-scoped of the two addresses. And note that that's not a particularly strong security property, given that any zone can include tunnel links (either at layer 2 or layer 3) that cross arbitrary "external" paths. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 14 07:24:38 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9EEMXn02494 for ipng-dist; Thu, 14 Oct 1999 07:22:33 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9EEMMk02487 for ; Thu, 14 Oct 1999 07:22:23 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA03086 for ; Thu, 14 Oct 1999 07:22:23 -0700 (PDT) Received: from dfw-ix16.ix.netcom.com (dfw-ix16.ix.netcom.com [206.214.98.16]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA06606 for ; Thu, 14 Oct 1999 07:22:22 -0700 (PDT) Received: (from smap@localhost) by dfw-ix16.ix.netcom.com (8.8.4/8.8.4) id JAA20058; Thu, 14 Oct 1999 09:21:36 -0500 (CDT) Received: from dal-tx46-36.ix.netcom.com(198.211.44.164) by dfw-ix16.ix.netcom.com via smap (V1.3) id rma019728; Thu Oct 14 09:20:49 1999 Message-ID: <3805766E.E13F8806@ix.netcom.com> Date: Thu, 14 Oct 1999 07:21:36 +0100 From: Jeff Williams Organization: INEG. Inc. (Spokesman INEGroup) X-Mailer: Mozilla 4.08 [en] (Win16; I) MIME-Version: 1.0 To: Brian Zill CC: "'Richard M. Smith'" , Guy Davies , ipng@sunroof.eng.sun.com Subject: Re: More misinformation on IPv6 References: <3D2036E25376D31197A100805FEAD892712E83@x1red-msg-14.itg-messaging.redmond.corp.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian and all, Brian Zill wrote: > Hi Jeff, > > > From: Jeff Williams [mailto:jwkckid1@ix.netcom.com] > > > > Over all I agree with your sentiment at least. > > Glad to hear my message was received in the spirit it was intended. > > > Looking for more positive solutions and insuring > > that there is absolutely NO privacy or security > > holes in IPv6 would be the best and most > > productive direction everyone can take. > > As Ignatios Souvatzis has already pointed out, absolutes are often > impossible to achieve outside of an ideal world. IETF working groups are > definitely not an ideal world :-). How true the IETF is not and ideal world, I have been involved with the IETF and been on working groups of various types for many years now. I for one don't expect perfection, but always strive for it. >;) > Since they are open to all comers, they > are often necessarily creatures of compromise. Sometimes the goals > inherently conflict. By posting here you are contributing, and positive > suggestions that may lead to real solutions are appreciated. > > > > What you're all arguing about is a "may" clause, > > > one way out of many possible ways to form an > > > interface identifier. How interface identifiers > > > end up getting created in common practice is the > > > real issue, I believe. (And even there the concern > > > is primarily with end user machines, and not > > > with the addresses of servers or routers.) There > > > may or may not be a realistic privacy concern > > > associated with this, opinions tend to vary with > > > one's predictions of future common practices. > > > So I'll refrain from commenting on that issue > > > at this time. > > > > May not be a realistic privacy concern??? > > There definitely is a privacy concern and you > > pointed it out in your paragraph just before this > > one above. And "May not be" is not good enough. > > I believe you misunderstand me. The "may or may not" in my statement above > depends upon the individual's prediction of future common practices. In some respects yes this is true, but where such concerns can be technically addressed they should be. ANd that is not the case here with this specific problem with IPv6 presently. The resistance to addressing this piracy concern seems to be motivated from other sectors it seems to me. Yet we all know that privacy concerns are paramount in the user community, in fact they are more an more demanding better privacy protections designed into the products they use as recent court cases can attest to. > To > pick an extreme example, if one predicts that no one will ever form their > interface identifiers from MAC addresses, than it is clearly impossible in > that future scenario for such things to be a privacy concern. If you have a > different opinion, than presumably you have a different prediction of future > common practices. Well as you know or should know, there is really no such a thing as "Common Practice" that is sufficient enough to stand up in court when it comes to some issues such a privacy issues. In addition I would venture to say that "Common Practice" does not dictate necessarily, "Good Practice". > I'm not trying to claim any particular prediction of the > future is correct (if I was good at predicting the future, I'd be a stock > trader, not a programmer :-). LOL! Well I do both. I am hitting the 85% on my stock trading. >;) > > > > > The concern I have that prompted this post > > > is that some people are misrepresenting this > > > issue as an IPv6 protocol flaw. It is not. > > > It is an issue regarding how the protocol > > > might be used in practice. > > > > Well that is a flaw by definition. Not a feature. >;) > > No, it IS a feature. Denying a capability to the entire set of possible > users, simply because a particular subset doesn't wish to utilize that > capability, is often viewed by those not in that particular subset as an > unreasonable restriction. I am not saying that this needs to be the case. I am saying that it should be in the hands of the user at the client level, not at the ISP or service level, hence the problem. > > > For example. There are many companies in the world today which don't > provide (or whose policies don't allow) external access to the public > Internet for their employees' personal use. Yes but this is shrinking rapidly. > Such a company may legitimately > desire, for convenience or asset management reasons, to allocate all of its > internal IPv6 addresses using embedded MAC addresses. And here is the crux of the problem. Those companies are even outside or the "Common Practice" to which you subscribe to. To aid and abed this practice is not only against "Common Practice" but also is a violation of that employees privacy rights and in violation of "Good Practice". > The privacy concern > that Richard Smith outlined doesn't appear to exist is this situation. This > is a company that just wants to use its own private property in a way that > is convenient for it to do so. Why should the IETF forbid such a thing? The IETF should not. The IETF should however provide for user determined options in the spec. > > > > > The same issue is relevant (or not) with regards > > > to how IPv4 addresses are used in practice today. > > > > No this is not really the case at all. At the > > client level this problem can be dealt with by the > > user themselves. Not true with the current > > spec on IPV6. > > I don't follow you, and I'm very familiar with the specifications of both > IPv4 and IPv6. The IPv6 specifications allow for, and every IPv6 stack > implementation that I've seen provides the capability for, the end user to > manually set their address to whatever they want. > > --Brian > > The opinions I've expressed in this message are my own and should not be > taken as representative of Microsoft, the IPv6 Forum Tech Directorate, the > ipv6.org web site, or any other company, group, person or inanimate object. > > > -- > > Jeffrey A. Williams > > Spokesman INEGroup (Over 95k members strong!) > > CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. > > Information Network Eng. Group. INEG. INC. > > E-Mail jwkckid1@ix.netcom.com > > Contact Number: 972-447-1894 > > Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 Regards, -- Jeffrey A. Williams Spokesman INEGroup (Over 95k members strong!) CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 972-447-1894 Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 14 07:31:10 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9EETjQ02521 for ipng-dist; Thu, 14 Oct 1999 07:29:45 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9EETak02514 for ; Thu, 14 Oct 1999 07:29:36 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA06674 for ; Thu, 14 Oct 1999 07:29:37 -0700 (PDT) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id HAA09010 for ; Thu, 14 Oct 1999 07:29:28 -0700 (PDT) Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id OA04415; Fri, 15 Oct 1999 00:29:17 +1000 (from kre@munnari.OZ.AU) From: Robert Elz To: "Matt Crawford" Cc: ipng@sunroof.eng.sun.com, namedroppers@internic.net Subject: Re: draft-ietf-ipngwg-dns-lookups-04.txt In-Reply-To: Your message of "Thu, 14 Oct 1999 08:52:01 EST." <199910141352.IAA24747@gungnir.fnal.gov> Date: Fri, 15 Oct 1999 00:29:16 +1000 Message-Id: <16537.939911356@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 14 Oct 1999 08:52:01 -0500 From: "Matt Crawford" Message-ID: <199910141352.IAA24747@gungnir.fnal.gov> | This isn't the same as what I presumed above. Which more closely | matches the behavior of existing implementations? If in a v4-only | world I type "telnet H" and H.D1 exists but has no A record, but H.D2 | has an A record, what happens? Assuming that H.D1 also does not have a CNAME which then gets to an A record, H.D2 is found. That's needed, or *.D1 MX whatever would cause "telnet H" to always attempt H.D1, regardless of there being nothing really called H in D1 at all. 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 14 08:11:18 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9EF87J02565 for ipng-dist; Thu, 14 Oct 1999 08:08:07 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9EF7vk02558 for ; Thu, 14 Oct 1999 08:07:59 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA10771 for ; Thu, 14 Oct 1999 08:07:54 -0700 (PDT) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA04798 for ; Thu, 14 Oct 1999 09:07:49 -0600 (MDT) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id RAA23655; Thu, 14 Oct 1999 17:06:25 +0200 (MET DST) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id RAA26799; Thu, 14 Oct 1999 17:06:24 +0200 (MET DST) Message-Id: <199910141506.RAA26799@givry.inria.fr> From: Francis Dupont To: "Matt Crawford" cc: ipng@sunroof.eng.sun.com, namedroppers@internic.net Subject: Re: draft-ietf-ipngwg-dns-lookups-04.txt In-reply-to: Your message of Thu, 14 Oct 1999 08:52:01 CDT. <199910141352.IAA24747@gungnir.fnal.gov> Date: Thu, 14 Oct 1999 17:06:23 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Francis dit: > => about ordering, something is not specified: when an address is > searched for a not fully qualified domain name then there is a search > for IPv4/A and IPv6/AAAA/A6 and in the search list (the list of domains, > usually initialised with the local domain name). > Should we do IP version or domain first? Let me restate the situation. The user refers to short-form name H, and the resolver is configured to search domains D1, ..., Dn. => with this notation the two choices are : - AAAA for H.D1, ..., H.Dn then A for H.D1, ..., H.Dn, or - AAAA then A for H.D1, ..., AAAA then A for H.Dn. As I see it, the FQDN the user is implicitly naming is the first one which *exists* from the sequence H.D1, ..., H.Dn. => this is the second choice, with the first one if H.Dx exists but has no AAAA RR and H.Dy exists and has an A RR with x < y then the returned FQDN will be H.Dy. Unfortunately this is not a theorical case because for instance my current search list is "inria.fr ipv6.inria.fr"! Then the resolver gives back whatever suitable records are listed for that FQDN, or some sort of error if there are none. => yes, a correct resolver should understand CNAME RRs and the difference between "no such domain" and "no address" (ie. name exists but has no such RR). > I believe many implementations do domain first, ie. for instance > look for an AAAA RR for the name completed with search list > elements then if nothing is found try the same thing for an A RR. This isn't the same as what I presumed above. => of course a query "address" type, even managed internally by the resolver (the T_ADDR hack), will give the second choice! Which more closely matches the behavior of existing implementations? => I think the first choice is used by most of them, try first IPv6, if there is no result and no fatal error then fall back to IPv4. (ie. it is convenient to use the res_search() function) If in a v4-only world I type "telnet H" and H.D1 exists but has no A record, but H.D2 has an A record, what happens? => H.D2 (and its address) is returned. All the standard applications use gethostbtname() function or a clone, only sendmail is smarter and uses directly the resolver library (with "mx" and "any" queries, avoiding to be fooled by wildcards, ...). Thanks Francis.Dupont@inria.fr PS: the code for AAAA and A RRs should be the same but some bogus name-servers don't deal correctly with queries for an AAAA RR for a name with (only) a CNAME RR then the choice between the two orders has some impacts on the answer decoding function in the resolver. PPS: the choice has a big impact in the speed and the number of queries in the current Internet where AAAA (and soon A6) RRs are *sparse*: this is not only an implementation issue! -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 14 09:36:44 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9EGXD502676 for ipng-dist; Thu, 14 Oct 1999 09:33:13 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9EGX0k02669 for ; Thu, 14 Oct 1999 09:33:01 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA21244 for ; Thu, 14 Oct 1999 09:33:00 -0700 (PDT) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA00640 for ; Thu, 14 Oct 1999 09:32:58 -0700 (PDT) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id LAA25471; Thu, 14 Oct 1999 11:32:57 -0500 (CDT) Message-Id: <199910141632.LAA25471@gungnir.fnal.gov> To: ipng@sunroof.eng.sun.com, namedroppers@internic.net From: "Matt Crawford" Subject: Re: draft-ietf-ipngwg-dns-lookups-04.txt In-reply-to: Your message of Fri, 15 Oct 1999 00:29:16 +1000. <16537.939911356@munnari.OZ.AU> Date: Thu, 14 Oct 1999 11:32:57 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk (Wow, the time zones invloved in this discussion!) Matt: > | Which more closely matches the behavior of existing implementations? > | If in a v4-only world I type "telnet H" and H.D1 exists but has > | no A record, but H.D2 has an A record, what happens? kre: > Assuming that H.D1 also does not have a CNAME which then gets to an > A record, H.D2 is found. Francis: > => I think the first choice is used by most of them, try first IPv6, > if there is no result and no fatal error then fall back to IPv4. > (ie. it is convenient to use the res_search() function) Sure enough. I dug through the most common genus of nameserver and resolver for which I have source code and this is what will happen. In capsule form, if an application prefers addresses coming from RR type T1 over those coming from RR type T2, and T2 over T3, and if the resolver has a domain search list D1, ..., Dn, then the conceptual operation "get me a connection to H" will choose an H.Dx with the most-preferred address type rather than the one with most-preferred domain. If a resolver's search list includes domains which have little or no administrative relation to one another, then this could cause surprises. If, for example, one had been accustomed to reaching H.D1 with the less-preferred address type one might suddenly reach H.Dn instead because it has added a more-preferred address type. Pretty much the same thing can happen in a pure-IPv4 setting if one is in the habit of specifying "H" to reach "H.D2" and then domain D1 adds a host "H". Therefore, proposed that we not concern ourselves about this except perhaps to mention it. When and if multi-question queries become available, other approaches will become possible. Matt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 14 09:41:12 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9EGdRh02724 for ipng-dist; Thu, 14 Oct 1999 09:39:27 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9EGdIk02710 for ; Thu, 14 Oct 1999 09:39:19 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.1b+Sun/8.9.1) id JAA16884 for ipng@sunroof.eng.sun.com; Thu, 14 Oct 1999 09:37:01 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9E9oxk01992 for ; Thu, 14 Oct 1999 02:51:01 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id CAA11698 for ; Thu, 14 Oct 1999 02:50:58 -0700 (PDT) Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA27254 for ; Thu, 14 Oct 1999 03:50:52 -0600 (MDT) Received: from penelope.ecs.soton.ac.uk (penelope.ecs.soton.ac.uk [152.78.68.135]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id KAA25171; Thu, 14 Oct 1999 10:50:41 +0100 (BST) Received: from penelope (penelope [152.78.68.135]) by penelope.ecs.soton.ac.uk (8.9.1a/8.9.1) with ESMTP id KAA29097; Thu, 14 Oct 1999 10:50:38 +0100 (BST) Date: Thu, 14 Oct 1999 10:50:38 +0100 (BST) From: Tim Chown To: Brian Zill cc: "'Richard M. Smith'" , Guy Davies , ipng@sunroof.eng.sun.com Subject: RE: More misinformation on IPv6 In-Reply-To: <3D2036E25376D31197A100805FEAD892712E82@x1red-msg-14.itg-messaging.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 Wed, 13 Oct 1999, Brian Zill wrote: > Finally, it's worth noting that the BBC article also misrepresents Thomas's > proposal as "manual configuration" (via placement of Thomas' quote > immediately after a paragraph paraphrasing Fred Baker describing such). If you look on the bright side, we at least have a BBC story which raises the profile and awareness of IPv6; as a result a few more people will look to find out more about it. I did some background reading before the Paris IPv6 Forum meeting and found some 30 or so IPv6 stories in the online press this year (and I'm sure there's a lot more). At least 75% were positive, and many relatively quite well written, e.g. "The Great Number Crunch" article. I think the Forum can help by tracking online press stories, and providing some sanitised commentary on articles (with Technical Directorate input) on its own web site. Linking to "bad" press is something that I feel should be done, so that any misconceptions can be highlighted. Considered and rational debunking of articles may put some pressure on the publishers to check facts more tightly. Some reporters will always seek sensationalist stories, and not be interested in reader feedback; at least this reporter quoted Fred Baker and stated that the IETF is addressing the issue, even if some assertions were a bit wobbly. Tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 14 09:50:14 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9EGkCv02784 for ipng-dist; Thu, 14 Oct 1999 09:46:12 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9EGk1k02777 for ; Thu, 14 Oct 1999 09:46:01 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA23931 for ; Thu, 14 Oct 1999 09:46:00 -0700 (PDT) Received: from mailext02.compaq.com (mailext02.compaq.com [207.18.199.33]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA18654 for ; Thu, 14 Oct 1999 10:45:59 -0600 (MDT) Received: from mailint12.im.hou.compaq.com (mailint12.compaq.com [207.18.199.190]) by mailext02.compaq.com (Postfix) with ESMTP id B47CE9A916; Thu, 14 Oct 1999 11:45:58 -0500 (CDT) Received: by mailint12.im.hou.compaq.com (Postfix, from userid 12345) id 451E44FB02; Thu, 14 Oct 1999 11:45:43 -0500 (CDT) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint12.im.hou.compaq.com (Postfix) with ESMTP id D04734C901; Thu, 14 Oct 1999 11:45:41 -0500 (CDT) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id MAA0000021992; Thu, 14 Oct 1999 12:45:54 -0400 (EDT) From: Jim Bound Message-Id: <199910141645.MAA0000021992@quarry.zk3.dec.com> To: Jeff Williams Cc: Bill Frezza , ipng@sunroof.eng.sun.com, ICANN Comments , IFWP Discussion List , "etrigar@teleline.es" , "Esther (The clueless) Dyson" , "mmr@darwin.ptvy.ca.us" , "linda_wilson@radcliffe.edu" , "junsec@wide.ad.jp" , "gregcrew@iaccess.com.au" , "geraldine.capdeboscq@bull.fr" , "gconrades@polarisventures.com" , "fitzsimmon@dnb.com" , "gconrades@icann.org" , "gregcrew@icann.org" , "roberts@icann.org" Subject: Re: My InternetWeek op-ed column on IPv6 privacy issues In-reply-to: Your message of "Wed, 13 Oct 1999 16:23:43 BST." <3804A3FC.64BAF976@ix.netcom.com> Date: Thu, 14 Oct 1999 12:45:54 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Give me a break IPv8 is a disgruntled joke. If you want to discuss IPv8 go create your own list. This is an IPv6 list and our charter. IPv8 is not part of the charter of this working group. Please take it elswwhere we have work to do on IPv6 here. Bill Frezza and others have raised an issue. It is being addressed in the IETF. As one of the key implementors of IPv6 I will tell all this is on the engineering table now for Ipv6 implementation. I will also tell you either fix proposed at this time is not a big deal to the code base or to get done in products even if they have shipped. But, what is important is that the IETF spend the time to get this right quickly and efficiently and not keep changing the fixes. But what is not good is to raise false alarms before they are a problem. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 14 10:30:53 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9EHQlZ02857 for ipng-dist; Thu, 14 Oct 1999 10:26:47 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9EHQak02850 for ; Thu, 14 Oct 1999 10:26:36 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA03428 for ; Thu, 14 Oct 1999 10:26:36 -0700 (PDT) Received: from dfw-ix3.ix.netcom.com (dfw-ix3.ix.netcom.com [206.214.98.3]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA26209 for ; Thu, 14 Oct 1999 10:26:35 -0700 (PDT) Received: (from smap@localhost) by dfw-ix3.ix.netcom.com (8.8.4/8.8.4) id MAA00538; Thu, 14 Oct 1999 12:18:49 -0500 (CDT) Received: from dal-tx43-54.ix.netcom.com(207.221.94.182) by dfw-ix3.ix.netcom.com via smap (V1.3) id rma000042; Thu Oct 14 12:16:48 1999 Message-ID: <38059FA2.D07B9375@ix.netcom.com> Date: Thu, 14 Oct 1999 10:17:24 +0100 From: Jeff Williams Organization: INEG. Inc. (Spokesman INEGroup) X-Mailer: Mozilla 4.08 [en] (Win16; I) MIME-Version: 1.0 To: Jim Bound CC: Bill Frezza , ipng@sunroof.eng.sun.com, ICANN Comments , IFWP Discussion List , "etrigar@teleline.es" , "Esther (The clueless) Dyson" , "mmr@darwin.ptvy.ca.us" , "linda_wilson@radcliffe.edu" , "junsec@wide.ad.jp" , "gregcrew@iaccess.com.au" , "geraldine.capdeboscq@bull.fr" , "gconrades@polarisventures.com" , "fitzsimmon@dnb.com" , "gconrades@icann.org" , "gregcrew@icann.org" , "roberts@icann.org" Subject: Re: My InternetWeek op-ed column on IPv6 privacy issues References: <199910141645.MAA0000021992@quarry.zk3.dec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim and all, No, you give everyone else a break. And while you are at it, get a grip on that attitude you seem to be displaying here. Yes I know very well that IPv8 is not part of the ipng list forum, and I only mentioned it in passing as in comparison nothing more, so cool you jets fella! The alarm was not raised originally by me as to the privacy concerns with IPv6, they were raised by others on the IPv6 working group originally in several IETF drafts by others that are authors of those very drafts as far back as 1997. So this is nothing really all that new. What is new though is the lack of addressing those privacy concerns to date despite them being known for some time. Jim Bound wrote: > Give me a break IPv8 is a disgruntled joke. If you want to discuss IPv8 > go create your own list. This is an IPv6 list and our charter. IPv8 is > not part of the charter of this working group. Please take it elswwhere > we have work to do on IPv6 here. > > Bill Frezza and others have raised an issue. It is being addressed in > the IETF. As one of the key implementors of IPv6 I will tell all this > is on the engineering table now for Ipv6 implementation. I will also > tell you either fix proposed at this time is not a big deal to the code > base or to get done in products even if they have shipped. But, what is > important is that the IETF spend the time to get this right quickly and > efficiently and not keep changing the fixes. > > But what is not good is to raise false alarms before they are a problem. > > /jim Regards, -- Jeffrey A. Williams Spokesman INEGroup (Over 95k members strong!) CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 972-447-1894 Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 14 10:43:48 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9EHeDb02908 for ipng-dist; Thu, 14 Oct 1999 10:40:13 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9EHe3k02901 for ; Thu, 14 Oct 1999 10:40:05 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA06133 for ; Thu, 14 Oct 1999 10:40:02 -0700 (PDT) Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id KAA02621 for ; Thu, 14 Oct 1999 10:40:02 -0700 (PDT) Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by crufty; Thu Oct 14 13:39:59 EDT 1999 Received: from dnrc.bell-labs.com (dhcp-6-168.pa.bell-labs.com [135.250.6.168]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id NAA05822; Thu, 14 Oct 1999 13:39:56 -0400 (EDT) Message-ID: <380615CE.246AB7F2@dnrc.bell-labs.com> Date: Thu, 14 Oct 1999 10:41:34 -0700 From: Grenville Armitage Organization: Bell Laboratories, Lucent Technologies X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jeff Williams CC: ipng@sunroof.eng.sun.com Subject: Re: More misinformation on IPv6 References: <38053B71.D7D763D2@dnrc.bell-labs.com> <3804DE18.B6D4F4DB@ix.netcom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jeff Williams wrote: [..] > Grenville Armitage wrote: > > > "Richard M. Smith" wrote: > > [..] > > > My concern here is that Web sites will start building > > > databases that include people's MAC address. > > > > Which today they do using the entire IPv4 address. > > True, but the individual user can control this presently > in v4. We clearly connect to different Internets. In my Internet, the service provider controls a large slab of the bits in my IPv4 address. Indeed, I have pretty limited range of choices as an average 'user'. Potentially none, in fact. So like I, and others, said - IPv6 and IPv4 addresses have very similar properties of (im)permanence and association to particular users. [..] > > > MAC addresses will then allow Web sites to correlate > > > personal data using a common MAC address key. > > > > As with IPv4 addresses. > > Yes, but again this can be controlled by the user should they so > choose to do so. Uh-huh. No, in practice, you cannot to any meaningful degree. See above. > Again you are oversimplifying the problem > so as to strengthen your perspective instead of representing > the plain cold facts in a tad bit more detail. Nice try here, but > again no cigar! But I must say I admire you sense of > deviousness! >;) Our facts apparently live in different worlds too. [..re NAT, Jeff agrees it solves the problem if used..] [..re DHCP, Jeff agrees it can solve the problem if used..] > > And when users are dial-up connected, same deal. Address-to-user > > associations are of a duration and obscurity dictated by > > the ISP. > > ANd this is really the crux of the debate, isn't it? Nope. It is the crux of the debate's debunking. > The ISP/IAP > makes the decision rather than the user Same as in IPv4. > due to a design > flaw that doesn't allow for an opt out by the user. Depends on your ISP. ISP policies are not the business of the IPng mailing list. cheers, gja-the-devious-one -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 14 10:56:32 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9EHrCo02948 for ipng-dist; Thu, 14 Oct 1999 10:53:12 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9EHr1k02941 for ; Thu, 14 Oct 1999 10:53:02 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA13109 for ; Thu, 14 Oct 1999 10:53:00 -0700 (PDT) Received: from mailext02.compaq.com (mailext02.compaq.com [207.18.199.33]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA19716 for ; Thu, 14 Oct 1999 11:53:00 -0600 (MDT) Received: from mailint02.im.hou.compaq.com (mailint02.compaq.com [207.18.199.35]) by mailext02.compaq.com (Postfix) with ESMTP id 61B179AB07; Thu, 14 Oct 1999 12:52:59 -0500 (CDT) Received: by mailint02.im.hou.compaq.com (Postfix, from userid 12345) id 37B3DBC4C3; Thu, 14 Oct 1999 12:52:41 -0500 (CDT) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint02.im.hou.compaq.com (Postfix) with ESMTP id 9840EB2A46; Thu, 14 Oct 1999 12:52:39 -0500 (CDT) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id NAA0000007482; Thu, 14 Oct 1999 13:52:56 -0400 (EDT) From: Jim Bound Message-Id: <199910141752.NAA0000007482@quarry.zk3.dec.com> To: Jeff Williams Cc: Jim Bound , Bill Frezza , ipng@sunroof.eng.sun.com, ICANN Comments , IFWP Discussion List , "etrigar@teleline.es" , "Esther (The clueless) Dyson" , "mmr@darwin.ptvy.ca.us" , "linda_wilson@radcliffe.edu" , "junsec@wide.ad.jp" , "gregcrew@iaccess.com.au" , "geraldine.capdeboscq@bull.fr" , "gconrades@polarisventures.com" , "fitzsimmon@dnb.com" , "gconrades@icann.org" , "gregcrew@icann.org" , "roberts@icann.org" Subject: Re: My InternetWeek op-ed column on IPv6 privacy issues In-reply-to: Your message of "Thu, 14 Oct 1999 10:17:24 BST." <38059FA2.D07B9375@ix.netcom.com> Date: Thu, 14 Oct 1999 13:52:56 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The alarm was not raised originally by me as to the privacy >concerns with IPv6, they were raised by others on the IPv6 >working group originally in several IETF drafts by others that >are authors of those very drafts as far back as 1997. So this is >nothing really all that new. What is new though is the lack of >addressing those privacy concerns to date despite them being known >for some time. There is a draft to fix it. IPv6 has not been widely deployed. The vendors will fix it when the draft is worked. The press is being typical for the 90's. Most of this mail has been a waste of our time as a working group IMO. Which I will state any time I feel like it. So you cool your jets. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 14 10:58:27 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9EHuqt02966 for ipng-dist; Thu, 14 Oct 1999 10:56:52 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9EHuck02952 for ; Thu, 14 Oct 1999 10:56:39 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA09715 for ; Thu, 14 Oct 1999 10:56:38 -0700 (PDT) Received: from dfw-ix1.ix.netcom.com (dfw-ix1.ix.netcom.com [206.214.98.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA21204 for ; Thu, 14 Oct 1999 11:56:37 -0600 (MDT) Received: (from smap@localhost) by dfw-ix1.ix.netcom.com (8.8.4/8.8.4) id MAA04403; Thu, 14 Oct 1999 12:56:19 -0500 (CDT) Received: from dal-tx43-54.ix.netcom.com(207.221.94.182) by dfw-ix1.ix.netcom.com via smap (V1.3) id rma004260; Thu Oct 14 12:55:44 1999 Message-ID: <3805A8BB.7745F9C2@ix.netcom.com> Date: Thu, 14 Oct 1999 10:56:15 +0100 From: Jeff Williams Organization: INEG. Inc. (Spokesman INEGroup) X-Mailer: Mozilla 4.08 [en] (Win16; I) MIME-Version: 1.0 To: Grenville Armitage CC: ipng@sunroof.eng.sun.com Subject: Re: More misinformation on IPv6 References: <38053B71.D7D763D2@dnrc.bell-labs.com> <3804DE18.B6D4F4DB@ix.netcom.com> <380615CE.246AB7F2@dnrc.bell-labs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Grenville and all, Grenville Armitage wrote: > Jeff Williams wrote: > [..] > > Grenville Armitage wrote: > > > > > "Richard M. Smith" wrote: > > > [..] > > > > My concern here is that Web sites will start building > > > > databases that include people's MAC address. > > > > > > Which today they do using the entire IPv4 address. > > > > True, but the individual user can control this presently > > in v4. > > We clearly connect to different Internets. In my Internet, > the service provider controls a large slab of the bits in > my IPv4 address. Indeed, I have pretty limited range of > choices as an average 'user'. Potentially none, in fact. That is a shame. I guess I am luckier that you must be. > > > So like I, and others, said - IPv6 and IPv4 addresses have > very similar properties of (im)permanence and association to > particular users. > > [..] > > > > MAC addresses will then allow Web sites to correlate > > > > personal data using a common MAC address key. > > > > > > As with IPv4 addresses. > > > > Yes, but again this can be controlled by the user should they so > > choose to do so. > > Uh-huh. No, in practice, you cannot to any meaningful degree. See > above. Well we shall have to agree to disagree here. I KNOW that you can you say that you can't. > > > > Again you are oversimplifying the problem > > so as to strengthen your perspective instead of representing > > the plain cold facts in a tad bit more detail. Nice try here, but > > again no cigar! But I must say I admire you sense of > > deviousness! >;) > > Our facts apparently live in different worlds too. Uh huh, well maybe you live on another planet. I live on the planet earth. I am sure things look different from your celestial perspective. >;) > > > [..re NAT, Jeff agrees it solves the problem if used..] > > [..re DHCP, Jeff agrees it can solve the problem if used..] Right, and so? > > > > > And when users are dial-up connected, same deal. Address-to-user > > > associations are of a duration and obscurity dictated by > > > the ISP. > > > > ANd this is really the crux of the debate, isn't it? > > Nope. It is the crux of the debate's debunking. No it is just the crux. You position seems to be more of the debunking as you seem to wish to refuse the already documented in IETF drafts, the facts. Interesting perspective I must say. >;) > > > > The ISP/IAP > > makes the decision rather than the user > > Same as in IPv4. In some cases yes this is true. but it does not HAVE to be or remain so. > > > > due to a design > > flaw that doesn't allow for an opt out by the user. > > Depends on your ISP. ISP policies are not the business of the IPng > mailing list. And I was not and am not now referring to the ISP in this sense. I see that you are though. Nice attempt at a spin, but it still comes full circle, so to speak. > > > cheers, > gja-the-devious-one Regards, -- Jeffrey A. Williams Spokesman INEGroup (Over 95k members strong!) CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 972-447-1894 Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 14 11:13:59 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9EIABa03028 for ipng-dist; Thu, 14 Oct 1999 11:10:11 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9EIA2k03021 for ; Thu, 14 Oct 1999 11:10:03 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA13442 for ; Thu, 14 Oct 1999 11:10:02 -0700 (PDT) Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id MAA27836 for ; Thu, 14 Oct 1999 12:10:01 -0600 (MDT) Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Thu Oct 14 14:08:51 EDT 1999 Received: from dnrc.bell-labs.com (dhcp-6-168.pa.bell-labs.com [135.250.6.168]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id OAA07524; Thu, 14 Oct 1999 14:08:48 -0400 (EDT) Message-ID: <38061C92.4B83F872@dnrc.bell-labs.com> Date: Thu, 14 Oct 1999 11:10:26 -0700 From: Grenville Armitage Organization: Bell Laboratories, Lucent Technologies X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jeff Williams CC: ipng@sunroof.eng.sun.com Subject: Re: More misinformation on IPv6 References: <38053B71.D7D763D2@dnrc.bell-labs.com> <3804DE18.B6D4F4DB@ix.netcom.com> <380615CE.246AB7F2@dnrc.bell-labs.com> <3805A8BB.7745F9C2@ix.netcom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [..] > No it is just the crux. You position seems to be more of the > debunking as you seem to wish to refuse the already documented in IETF > drafts, the facts. Interesting perspective I must say. >;) The 'debate' (as you so amusingly refer to it) began as debunking of recent media misrepresentation of this group's work. As Jim Bounds just pointed out, these particular media reports screwed up. By leaping to their defense, you did too. I think the debunking is now complete. cheers, gja -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 14 11:19:18 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9EIH8W03070 for ipng-dist; Thu, 14 Oct 1999 11:17:08 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9EIGhk03054 for ; Thu, 14 Oct 1999 11:16:45 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA14667 for ; Thu, 14 Oct 1999 11:16:13 -0700 (PDT) Received: from dfw-ix1.ix.netcom.com (dfw-ix1.ix.netcom.com [206.214.98.1]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA19985 for ; Thu, 14 Oct 1999 11:16:10 -0700 (PDT) Received: (from smap@localhost) by dfw-ix1.ix.netcom.com (8.8.4/8.8.4) id NAA07673; Thu, 14 Oct 1999 13:08:33 -0500 (CDT) Received: from dal-tx43-54.ix.netcom.com(207.221.94.182) by dfw-ix1.ix.netcom.com via smap (V1.3) id rma006277; Thu Oct 14 13:03:42 1999 Message-ID: <3805AAA3.160C892C@ix.netcom.com> Date: Thu, 14 Oct 1999 11:04:22 +0100 From: Jeff Williams Organization: INEG. Inc. (Spokesman INEGroup) X-Mailer: Mozilla 4.08 [en] (Win16; I) MIME-Version: 1.0 To: Jim Bound CC: Bill Frezza , ipng@sunroof.eng.sun.com, ICANN Comments , IFWP Discussion List , "etrigar@teleline.es" , "Esther (The clueless) Dyson" , "mmr@darwin.ptvy.ca.us" , "linda_wilson@radcliffe.edu" , "junsec@wide.ad.jp" , "gregcrew@iaccess.com.au" , "geraldine.capdeboscq@bull.fr" , "gconrades@polarisventures.com" , "fitzsimmon@dnb.com" , "gconrades@icann.org" , "gregcrew@icann.org" , "roberts@icann.org" Subject: Re: My InternetWeek op-ed column on IPv6 privacy issues References: <199910141752.NAA0000007482@quarry.zk3.dec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim and all, Jim Bound wrote: > > The alarm was not raised originally by me as to the privacy > >concerns with IPv6, they were raised by others on the IPv6 > >working group originally in several IETF drafts by others that > >are authors of those very drafts as far back as 1997. So this is > >nothing really all that new. What is new though is the lack of > >addressing those privacy concerns to date despite them being known > >for some time. > > There is a draft to fix it. Yes? Which one is that? the latest draft also recognizes the privacy problem as well. > > > IPv6 has not been widely deployed. Not likely to be either unless or until these problems in the spec are corrected. > > > The vendors will fix it when the draft is worked. That may be, let's hope so. But there seems to be some resistance to doing that presently. Hence public exposure is necessary in order for the proper pressure to be brought to bear in order to underscore that this problem MUST be fixed. > > > The press is being typical for the 90's. The press is always typical, regardless of the decade. > > > Most of this mail has been a waste of our time as a working group IMO. > Which I will state any time I feel like it. So you cool your jets. Oh, feel free, please! >;) As will I if I feel that it is relevant and necessary. >;) But I agree, that most of the denial that there is a serious privacy concern with IPv6 is a waste of time. > > > /jim Regards, -- Jeffrey A. Williams Spokesman INEGroup (Over 95k members strong!) CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 972-447-1894 Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 14 11:19:27 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9EIH2p03069 for ipng-dist; Thu, 14 Oct 1999 11:17:02 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9EIGlk03056 for ; Thu, 14 Oct 1999 11:16:49 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA18703 for ; Thu, 14 Oct 1999 11:16:35 -0700 (PDT) Received: from dfw-ix14.ix.netcom.com (dfw-ix14.ix.netcom.com [206.214.98.14]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA00719 for ; Thu, 14 Oct 1999 12:16:33 -0600 (MDT) Received: (from smap@localhost) by dfw-ix14.ix.netcom.com (8.8.4/8.8.4) id NAA23743; Thu, 14 Oct 1999 13:16:15 -0500 (CDT) Received: from dal-tx43-54.ix.netcom.com(207.221.94.182) by dfw-ix14.ix.netcom.com via smap (V1.3) id rma023211; Thu Oct 14 13:14:18 1999 Message-ID: <3805AD17.BFD426B7@ix.netcom.com> Date: Thu, 14 Oct 1999 11:14:50 +0100 From: Jeff Williams Organization: INEG. Inc. (Spokesman INEGroup) X-Mailer: Mozilla 4.08 [en] (Win16; I) MIME-Version: 1.0 To: Grenville Armitage CC: ipng@sunroof.eng.sun.com Subject: Re: More misinformation on IPv6 References: <38053B71.D7D763D2@dnrc.bell-labs.com> <3804DE18.B6D4F4DB@ix.netcom.com> <380615CE.246AB7F2@dnrc.bell-labs.com> <3805A8BB.7745F9C2@ix.netcom.com> <38061C92.4B83F872@dnrc.bell-labs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Grenville and all, Well I am happy to see that you have decided (For us all perhaps?) that you debunking of legitimate concerns by yourself is complete. But somehow I doubt that. >;) None the less, the concern remains and the debunking of some article does not fix the problem. As such it is just not going to just go away. Grenville Armitage wrote: > [..] > > No it is just the crux. You position seems to be more of the > > debunking as you seem to wish to refuse the already documented in IETF > > drafts, the facts. Interesting perspective I must say. >;) > > The 'debate' (as you so amusingly refer to it) began as debunking > of recent media misrepresentation of this group's work. As Jim > Bounds just pointed out, these particular media reports screwed > up. By leaping to their defense, you did too. I think the debunking > is now complete. > > cheers, > gja Regards, -- Jeffrey A. Williams Spokesman INEGroup (Over 95k members strong!) CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 972-447-1894 Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 14 11:26:47 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9EILQw03123 for ipng-dist; Thu, 14 Oct 1999 11:21:26 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9EILKk03116 for ; Thu, 14 Oct 1999 11:21:21 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.1b+Sun/8.9.1) id LAA17057 for ipng@sunroof.eng.sun.com; Thu, 14 Oct 1999 11:19:03 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9EICDk03030 for ; Thu, 14 Oct 1999 11:12:13 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA13926 for ; Thu, 14 Oct 1999 11:12:13 -0700 (PDT) Received: from ib.rc.vix.com (ib.rc.vix.com [204.152.187.22]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA28905 for ; Thu, 14 Oct 1999 12:12:12 -0600 (MDT) Received: from bb.rc.vix.com (bb.rc.vix.com [204.152.187.11]) by ib.rc.vix.com (8.9.1/8.9.1) via ESMTP id LAA05457; Thu, 14 Oct 1999 11:12:10 -0700 (PDT) env-from (vixie@mibh.net) Received: from bb.rc.vix.com (localhost [127.0.0.1]) by bb.rc.vix.com (8.9.1/8.9.1) via ESMTP id LAA05216; Thu, 14 Oct 1999 11:12:10 -0700 (PDT) env-from (vixie@mibh.net) Message-Id: <199910141812.LAA05216@bb.rc.vix.com> To: "Matt Crawford" cc: ipng@sunroof.eng.sun.com, namedroppers@internic.net Subject: Re: draft-ietf-ipngwg-dns-lookups-04.txt In-reply-to: Your message of "Thu, 14 Oct 1999 08:52:01 CDT." <199910141352.IAA24747@gungnir.fnal.gov> Date: Thu, 14 Oct 1999 11:12:10 -0700 From: Paul A Vixie Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Let me restate the situation. The user refers to short-form name H, > and the resolver is configured to search domains D1, ..., Dn. > > As I see it, the FQDN the user is implicitly naming is the first one > which *exists* from the sequence H.D1, ..., H.Dn. Then the resolver > gives back whatever suitable records are listed for that FQDN, or > some sort of error if there are none. we went through this in pure IPv4, too, due to early API ambiguity between "name doesn't exist at all" and "name exists, but there are no address records." in fact it was KRE who complained about it then, as now. so assuming H.D1 IN MX 10 foo and H.D2 IN A 10.0.0.53 and a domain search list of D1,D2, it used to be that "ping h" would return "no such host". now it pings 10.0.0.53. to me, this is the same issue except that we're fine-pointing on the meaning of the question "are there address records at this node?" -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 14 11:52:41 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9EImq903232 for ipng-dist; Thu, 14 Oct 1999 11:48:52 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9EImgk03225 for ; Thu, 14 Oct 1999 11:48:43 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA22128 for ; Thu, 14 Oct 1999 11:48:42 -0700 (PDT) Received: from inet-vrs-02.microsoft.com (mail2.microsoft.com [131.107.3.124]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id LAA05651 for ; Thu, 14 Oct 1999 11:48:42 -0700 (PDT) Received: from 157.54.9.104 by inet-vrs-02.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 14 Oct 1999 11:23:32 -0700 (Pacific Daylight Time) Received: by INET-IMC-02 with Internet Mail Service (5.5.2650.21) id <4705FBAA>; Thu, 14 Oct 1999 11:23:30 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D81014515C06@RED-MSG-50> From: Richard Draves To: "'Alain Durand'" Cc: "'IPng List'" , Erik Nordmark Subject: RE: (ngtrans) I-D ACTION:draft-ietf-ngtrans-6to4-03.txt Date: Thu, 14 Oct 1999 10:39:05 -0700 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The sets of precedence in the updated algorithm I posted today > to select source & destination addresses should take care of > the buckets you suggest. > Those precedence have default values that can be administratively > changed. > One can always define some new levels which could correspond > to new buckets. > > Is it not enough? [I agree, we should be discussing this on ipng instead of ngtrans. I've removed ngtrans, I don't like getting multiple messages...] Alain, our initial two proposals were fairly similar. However in the end I think we need to separate the concepts of buckets and the concepts of precedence and use both. First I have some confusion when I read your proposal. At some points you use numerical inequalities eg prec(a) < prec(b). That's clear. At other points you say "higher precedence". Does higher precedence mean lower numerically or higher numerically? So maybe you'll have to correct my interpretation of your proposed algorithm. I'd like to give the administrator the ability to configure a solution to the other problem that you raised in Tokyo - situations where longest-matching-prefix does not do the right thing because of mismatches with the topology, like where one's ISP is has two separate prefixes. So suppose the administrator can say "give first preference to addresses in my own site (prefix A/48), next to addresses from my ISP (prefixes A/16 and B/16), next to all other global native addresses, next to 6to4, last to v4-compatible". That sounds like a useful capability for the administrator. Suppose the administrator tries to do this with your algorithm. Then a node with two source addresses, one from prefix A/48 and one 6to4, initiates communication with another node with one destination address from prefix B/16. I believe that your algorithm will select the 6to4 source address instead of the A/48 source address - clearly the wrong thing. Another situation - the source addresses are the same (prefixes A/48 and 6to4), but there are two destination addresses (prefixes B/16 and 6to4). In this situation your algorithm will select the 6to4 source & destination addresses instead of the two native addresses. The administrator really wants to have two buckets - one for native addresses and one for 6to4/v4-compatible addresses. The first priority is to have destination & source addresses from the same bucket. But within the buckets the administrator might also want to have some preferences, like saying use 6to4 before v4-compatible, or use addresses in my ISP's prefixes before other native/global addresses. So the second priority is to use addresses that have highest (lowest numerically) precedence value. Then third priority can be longest-matching-prefix, and a fourth priority can be preserving DNS order. Before I try to sketch out an algorithm that uses both buckets & precedence... how does this sound so far? 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 Thu Oct 14 12:07:58 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9EJ4BM03279 for ipng-dist; Thu, 14 Oct 1999 12:04:11 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9EJ41k03272 for ; Thu, 14 Oct 1999 12:04:03 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA00070 for ; Thu, 14 Oct 1999 12:04:01 -0700 (PDT) Received: from hamper (relay.bt.net [194.72.6.60]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA13332 for ; Thu, 14 Oct 1999 12:03:56 -0700 (PDT) Received: from wstaalnt544731.ukcore.bt.net by hamper with SMTP (XT-PP); Thu, 14 Oct 1999 20:03:30 +0100 Received: by wstaalnt544731.ukcore.bt.net with Microsoft Mail id <01BF167E.C78166A0@wstaalnt544731.ukcore.bt.net>; Thu, 14 Oct 1999 20:00:35 +0100 Message-ID: <01BF167E.C78166A0@wstaalnt544731.ukcore.bt.net> From: Jim Dunn To: "'Tim Chown'" , Brian Zill Cc: "'Richard M. Smith'" , Guy Davies , "ipng@sunroof.eng.sun.com" Subject: RE: More misinformation on IPv6 Date: Thu, 14 Oct 1999 20:00:34 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id d9EJ43k03273 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I agree with Tim, But maybe it would be better if we provided the relevant input before the article was published. Many people will read the article and take it as seen, without ever checking the flip side of the coin and going to the technical directorate web site to get the full story. Maybe we can formulate a formal process for dealing with the press so that they get the full story, both problems and proposed resolutions. That is after all what we are all doing, someone has a problem and we collectively bang heads to get the best resolution to that problem. Maybe each of the working groups could nominate a "press Officer", I know it's overly bureaucratic and not really the IETF way but the potential benefits could far outway any negative side. This officer could answer to the area directors of that particular working group and would be intimately familiar with the issues at hand in order to give all of the facts in a clear and concise manner to the press, who would then be diseminating information straight from the horses mouth as it were. Just an Idea.......(my $0.02) Jim Jim Dunn IP Network Engineer (2nd Line) BT Internet Operations Centre E-mail: jim.dunn@bt.net -----Original Message----- From: Tim Chown [SMTP:tjc@ecs.soton.ac.uk] Sent: 14 October 1999 10:51 To: Brian Zill Cc: 'Richard M. Smith'; Guy Davies; ipng@sunroof.eng.sun.com Subject: RE: More misinformation on IPv6 On Wed, 13 Oct 1999, Brian Zill wrote: > Finally, it's worth noting that the BBC article also misrepresents Thomas's > proposal as "manual configuration" (via placement of Thomas' quote > immediately after a paragraph paraphrasing Fred Baker describing such). If you look on the bright side, we at least have a BBC story which raises the profile and awareness of IPv6; as a result a few more people will look to find out more about it. I did some background reading before the Paris IPv6 Forum meeting and found some 30 or so IPv6 stories in the online press this year (and I'm sure there's a lot more). At least 75% were positive, and many relatively quite well written, e.g. "The Great Number Crunch" article. I think the Forum can help by tracking online press stories, and providing some sanitised commentary on articles (with Technical Directorate input) on its own web site. Linking to "bad" press is something that I feel should be done, so that any misconceptions can be highlighted. Considered and rational debunking of articles may put some pressure on the publishers to check facts more tightly. Some reporters will always seek sensationalist stories, and not be interested in reader feedback; at least this reporter quoted Fred Baker and stated that the IETF is addressing the issue, even if some assertions were a bit wobbly. Tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 14 12:14:52 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9EJDMN03312 for ipng-dist; Thu, 14 Oct 1999 12:13:22 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9EJDDk03305 for ; Thu, 14 Oct 1999 12:13:14 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA26108 for ; Thu, 14 Oct 1999 12:13:12 -0700 (PDT) Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA17818 for ; Thu, 14 Oct 1999 12:13:12 -0700 (PDT) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id PAA18734 for ; Thu, 14 Oct 1999 15:12:49 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.37.82.31]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id PAA23100 for ; Thu, 14 Oct 1999 15:12:49 -0400 Received: from rotala.raleigh.ibm.com (localhost [127.0.0.1]) by rotala.raleigh.ibm.com (8.9.3/8.7/RTP-ral-1.0) with ESMTP id PAA23716 for ; Thu, 14 Oct 1999 15:07:20 -0400 Message-Id: <199910141907.PAA23716@rotala.raleigh.ibm.com> To: ipng@sunroof.eng.sun.com Subject: draft-ietf-ipngwg-addrconf-privacy-00.txt Date: Thu, 14 Oct 1999 15:07:20 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Folks, One thing that would be helpful in this moment of hightened interest is to take a look at this document and provide specific comments on it, especially with respect to the Section 2, "Background". The intent of that section is to provide some overall perspective on the issue. Some of the comments that have been made recently on this list should probably be put into this section. Regarding the protocol description, per comments and the discussion in Oslo, the mechanism itself will likely be moved to an appendix or simply be thrown out. It's too simplistic to be useful in the cases of real interest. The next version of the document will define a mechanism that keeps the EUI-64-derived interface ID for link-local and site-local addresses, but allows the global scope addresses to have random interface IDs. In addition, nodes need to have both a "permanent" address (i.e., one with the EUI-64-derived address) that is "public" so that the node can act as a server and accept incoming connections. Simultaneously, nodes will want to act as clients, initiating connections from addresses with the random interface ID component. Both addresses will be in effect simultaneously. The interested reader may wish to think about how this might impact source address selection algorithms that are invoked when initiating connections. Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 14 12:52:27 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9EJn5C03436 for ipng-dist; Thu, 14 Oct 1999 12:49:05 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9EJmsk03429 for ; Thu, 14 Oct 1999 12:48:54 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA03100 for ; Thu, 14 Oct 1999 12:48:54 -0700 (PDT) Received: from dfw-ix2.ix.netcom.com (dfw-ix2.ix.netcom.com [206.214.98.2]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA02853 for ; Thu, 14 Oct 1999 12:48:51 -0700 (PDT) Received: (from smap@localhost) by dfw-ix2.ix.netcom.com (8.8.4/8.8.4) id OAA04169; Thu, 14 Oct 1999 14:41:18 -0500 (CDT) Received: from dal-tx6-56.ix.netcom.com(207.94.122.120) by dfw-ix2.ix.netcom.com via smap (V1.3) id rma003984; Thu Oct 14 14:40:28 1999 Message-ID: <3805C152.A9BE8976@ix.netcom.com> Date: Thu, 14 Oct 1999 12:41:08 +0100 From: Jeff Williams Organization: INEG. Inc. (Spokesman INEGroup) X-Mailer: Mozilla 4.08 [en] (Win16; I) MIME-Version: 1.0 To: list@ifwp.org CC: Jim Bound , Bill Frezza , ipng@sunroof.eng.sun.com, ICANN Comments , "etrigar@teleline.es" , "Esther (The clueless) Dyson" , "mmr@darwin.ptvy.ca.us" , "linda_wilson@radcliffe.edu" , "junsec@wide.ad.jp" , "gregcrew@iaccess.com.au" , "geraldine.capdeboscq@bull.fr" , "gconrades@polarisventures.com" , "fitzsimmon@dnb.com" , "gconrades@icann.org" , "gregcrew@icann.org" , "roberts@icann.org" Subject: Re: [IFWP] Re: My InternetWeek op-ed column on IPv6 privacy issues References: <19991014190107.1462FF04B@ns1.vrx.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Richard and all, Yep, that about sums up their logic here I would say. interesting approach, eh? >;) Richard J. Sexton wrote: > How to stop an IPV8 critic: ask them how IPV8 works. They can't tell you, > they don't know. But they do know it doesn't work. > > -- > richard@tangled.web sexton@mejac.palo-alto.ca.us > "I see you've got yout fist out. Say your peace and get out. Guess > I get the gist of it, but... it's alright. Sorry that you feel that > way. The only thing there is to say is to say: ever silver lining > has a touch of grey" - JG. Regards, -- Jeffrey A. Williams Spokesman INEGroup (Over 95k members strong!) CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 972-447-1894 Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 14 12:58:13 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9EJug003470 for ipng-dist; Thu, 14 Oct 1999 12:56:42 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9EJuWk03463 for ; Thu, 14 Oct 1999 12:56:33 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA04196 for ; Thu, 14 Oct 1999 12:56:31 -0700 (PDT) Received: from mailnfs0.tiac.net (mailnfs0.tiac.net [199.0.65.17]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA05975 for ; Thu, 14 Oct 1999 12:56:30 -0700 (PDT) Received: from rms (smiths.tiac.net [199.3.129.167]) by mailnfs0.tiac.net (8.8.8/8.8) with SMTP id PAA30765; Thu, 14 Oct 1999 15:56:24 -0400 (EDT) From: "Richard M. Smith" To: "Thomas Narten" , Subject: RE: draft-ietf-ipngwg-addrconf-privacy-00.txt Date: Thu, 14 Oct 1999 15:56:36 -0400 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.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <199910141907.PAA23716@rotala.raleigh.ibm.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Thomas, > The next version of the document will define a > mechanism that keeps the EUI-64-derived interface ID for link-local > and site-local addresses, but allows the global scope addresses to > have random interface IDs. One needs to be a bit careful here with the idea of local vs global addresses. It's very easy for programmers to get mixed up and use the wrong one. The result is that an application software package can inadvertently send out a local or site IPv6 address to a remote server. I just found an example of this sort of bug today in IPv4. I run a NAT box at home (a Web Ramp Internet sharing box), so I have a "private" IP address for my computer and a "public" IP address that the world sees. I was running a packet sniffer on the Windows Media Player and discovered that it includes my private IP address in a Unicode string in an MMS packet. This packet appears to be sent to a Web server anytime an audio or video clip is played. For what reason this is being done, I can't say. This address is meaningless to the server. This bug doesn't matter to me. However folks who are using some sort of proxy server to provide anonymity while watching a video clip are going to be in for a bit of a surprise. It's likely that Web servers have their real IP address anyway. Richard -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 14 13:07:26 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9EK1oW03503 for ipng-dist; Thu, 14 Oct 1999 13:01:50 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9EK1dk03495 for ; Thu, 14 Oct 1999 13:01:39 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA04983 for ; Thu, 14 Oct 1999 13:01:38 -0700 (PDT) Received: from mailext03.compaq.com (mailext03.compaq.com [207.18.199.41]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA08192 for ; Thu, 14 Oct 1999 13:01:37 -0700 (PDT) Received: from mailint02.im.hou.compaq.com (mailint02.compaq.com [207.18.199.35]) by mailext03.compaq.com (Postfix) with ESMTP id EC65C151FE6; Thu, 14 Oct 1999 15:01:36 -0500 (CDT) Received: by mailint02.im.hou.compaq.com (Postfix, from userid 12345) id B28A7BC4C3; Thu, 14 Oct 1999 15:01:18 -0500 (CDT) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint02.im.hou.compaq.com (Postfix) with ESMTP id 34017B2A45; Thu, 14 Oct 1999 15:01:17 -0500 (CDT) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id QAA0000002399; Thu, 14 Oct 1999 16:01:34 -0400 (EDT) From: Jim Bound Message-Id: <199910142001.QAA0000002399@quarry.zk3.dec.com> To: Jeff Williams Cc: Jim Bound , Bill Frezza , ipng@sunroof.eng.sun.com, ICANN Comments , IFWP Discussion List , "etrigar@teleline.es" , "Esther (The clueless) Dyson" , "mmr@darwin.ptvy.ca.us" , "linda_wilson@radcliffe.edu" , "junsec@wide.ad.jp" , "gregcrew@iaccess.com.au" , "geraldine.capdeboscq@bull.fr" , "gconrades@polarisventures.com" , "fitzsimmon@dnb.com" , "gconrades@icann.org" , "gregcrew@icann.org" , "roberts@icann.org" Subject: Re: My InternetWeek op-ed column on IPv6 privacy issues In-reply-to: Your message of "Thu, 14 Oct 1999 11:04:22 BST." <3805AAA3.160C892C@ix.netcom.com> Date: Thu, 14 Oct 1999 16:01:34 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> There is a draft to fix it. > > Yes? Which one is that? the latest draft also recognizes the >privacy problem as well. THe draft Bill provided in his mail to this forum. I have read Thomas's draft and it will work, he provides two solutions. I would also like to see a solution where the node administrator can provide a seed for the EUI token too. > IPv6 has not been widely deployed. > > Not likely to be either unless or until these problems in the >spec are corrected. On the contrary. I believe IPv6 will be deployed on Intranet's first and the deployment will happen from within to without and ISPs and routers will be last to deploy IPv6, which is why we need transition mechanisms like 6to4. > The vendors will fix it when the draft is worked. >. >. That may be, let's hope so. But there seems to be some >.resistance to doing that presently. Hence public exposure is >necessary in order for the proper pressure to be brought to >bear in order to underscore that this problem MUST be fixed. As a note. Thomas Narten made us aware of this long ago before the draft came out. Its been on the implementation issue agenda for a long time. If anything was late it was a spec. Not the vendors. I know of no vendor or implementor that has stated they would not fix this issue. >> The press is being typical for the 90's. > > The press is always typical, regardless of the decade. At least in the U.S. it is far worse than it has ever been before I can recall or from the history lessons I have absorbed. What has happened here is a complete abuse of the U.S. 1st ammendment which is the right to free speech. The articles accusing the IETF and IPv6 of being flawed and sitting on their backside, were like yelling Fire in a crowded theatre. 1. The IETF is not lax here at all. The problem is well understood and under control. Folks can look at Thomas's spec and make comments or shoot holes in it. I think its fine as a note, but would like to see some manual options by node admins. 2. IPv6 is not flawed. If anything IPv6 is more equipped to deal with this problem than IPv4 simply cause we have more bits to randomize as one solution. IPv4 does not have that luxury. This is an IPv4 problem too. I could use the "sophist" argument that this uproar is even more reason to move to IPv6 quickly cause we can fix it and IPv4 cannot. But that would be dishonorable and unethical on my part and also yelling fire in the theatre. 3. No Ipv6 implementors have stated they would not make the code changes to support this in the Addr Conf spec. So saying implementors may not fix it was a complete fabrication by that assumption, or that we would ship products for IPv6 forever with this issue. This could have affected IPv6 deployment, but it won't cause its not a real problem, cause it will get fixed, cause it is not and never was a basic flaw in the pristine and elegant design and architecture of the Next Internet Generation Protocol, which we call IPv6. But more to the philosophical point which I find great irony with is the entire notion of privacy. The best privacy is to live in the mountains of some place in a cabin and not participate in the world, if one has the ability to do so. But at the other extreme when you participate on the Internet or as one of my colleagues put it elsewhere when you make a phone call and give out your unlisted number your privacy is reduced. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 14 13:08:20 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9EK5gQ03512 for ipng-dist; Thu, 14 Oct 1999 13:05:42 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9EK5Uk03505 for ; Thu, 14 Oct 1999 13:05:33 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA05732 for ; Thu, 14 Oct 1999 13:05:26 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA18020 for ; Thu, 14 Oct 1999 14:05:25 -0600 (MDT) Received: from zed.isi.edu (zed-e.isi.edu [128.9.160.57]) by boreas.isi.edu (8.8.7/8.8.6) with ESMTP id NAA06204 for ; Thu, 14 Oct 1999 13:05:24 -0700 (PDT) From: Bill Manning Received: (from bmanning@localhost) by zed.isi.edu (8.8.7/8.8.6) id NAA03480 for ipng@sunroof.eng.sun.com; Thu, 14 Oct 1999 13:05:24 -0700 (PDT) Message-Id: <199910142005.NAA03480@zed.isi.edu> Subject: robustness & DNS To: ipng@sunroof.eng.sun.com Date: Thu, 14 Oct 1999 13:05:24 -0700 (PDT) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'd like to increase the number of slaves that home the ip6.int zone. If you would like to have one of your servers act in this capacity, please let me know. I expect to only add a few more servers. I'd like to get the servers for this zone prepared to answer with both IPv6 and IPv4 and provide authentication. This means that some effort in being -very- current is desirable. (e.g. this may not be for the production servers of the world, at least for the nonce. :) your name: contact fone: machine name (FQDN): DNS s/w version: --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 Thu Oct 14 13:27:52 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9EKI5p03568 for ipng-dist; Thu, 14 Oct 1999 13:18:05 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9EKHtk03561 for ; Thu, 14 Oct 1999 13:17:56 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA07630 for ; Thu, 14 Oct 1999 13:17:50 -0700 (PDT) Received: from inet-vrs-02.microsoft.com (mail2.microsoft.com [131.107.3.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id OAA23102 for ; Thu, 14 Oct 1999 14:17:43 -0600 (MDT) Received: from 157.54.9.104 by inet-vrs-02.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 14 Oct 1999 12:34:18 -0700 (Pacific Daylight Time) Received: by INET-IMC-02 with Internet Mail Service (5.5.2650.21) id <4705FM00>; Thu, 14 Oct 1999 12:34:17 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D81014515C0A@RED-MSG-50> From: Richard Draves To: "'Thomas Narten'" Cc: ipng@sunroof.eng.sun.com Subject: RE: draft-ietf-ipngwg-addrconf-privacy-00.txt Date: Thu, 14 Oct 1999 12:34:11 -0700 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Regarding the protocol description, per comments and the discussion in > Oslo, the mechanism itself will likely be moved to an appendix or > simply be thrown out. It's too simplistic to be useful in the cases of > real interest. The next version of the document will define a > mechanism that keeps the EUI-64-derived interface ID for link-local > and site-local addresses, but allows the global scope addresses to > have random interface IDs. In addition, nodes need to have both a > "permanent" address (i.e., one with the EUI-64-derived address) that > is "public" so that the node can act as a server and accept incoming > connections. Simultaneously, nodes will want to act as clients, > initiating connections from addresses with the random interface ID > component. Both addresses will be in effect simultaneously. > > The interested reader may wish to think about how this might impact > source address selection algorithms that are invoked when initiating > connections. I was assuming that the permanent (EUI-64-derived) addresses would be deprecated, so they would not be used when initiating communication. So this would not introduce any extra complexity into source address selection. 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 Thu Oct 14 13:35:35 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9EKTqD03594 for ipng-dist; Thu, 14 Oct 1999 13:29:52 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9EKTfk03587 for ; Thu, 14 Oct 1999 13:29:42 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA09685 for ; Thu, 14 Oct 1999 13:29:40 -0700 (PDT) Received: from dfw-ix8.ix.netcom.com (dfw-ix8.ix.netcom.com [206.214.98.8]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA19902 for ; Thu, 14 Oct 1999 13:29:37 -0700 (PDT) Received: (from smap@localhost) by dfw-ix8.ix.netcom.com (8.8.4/8.8.4) id PAA23226; Thu, 14 Oct 1999 15:21:57 -0500 (CDT) Received: from dal-tx6-56.ix.netcom.com(207.94.122.120) by dfw-ix8.ix.netcom.com via smap (V1.3) id rma022533; Thu Oct 14 15:18:23 1999 Message-ID: <3805CA2A.1A7BC702@ix.netcom.com> Date: Thu, 14 Oct 1999 13:18:54 +0100 From: Jeff Williams Organization: INEG. Inc. (Spokesman INEGroup) X-Mailer: Mozilla 4.08 [en] (Win16; I) MIME-Version: 1.0 To: Jim Bound CC: Bill Frezza , ipng@sunroof.eng.sun.com, ICANN Comments , IFWP Discussion List , "etrigar@teleline.es" , "Esther (The clueless) Dyson" , "mmr@darwin.ptvy.ca.us" , "linda_wilson@radcliffe.edu" , "junsec@wide.ad.jp" , "gregcrew@iaccess.com.au" , "geraldine.capdeboscq@bull.fr" , "gconrades@polarisventures.com" , "fitzsimmon@dnb.com" , "gconrades@icann.org" , "gregcrew@icann.org" , "roberts@icann.org" Subject: Re: My InternetWeek op-ed column on IPv6 privacy issues References: <199910142001.QAA0000002399@quarry.zk3.dec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim and all, Jim Bound wrote: > >> There is a draft to fix it. > > > > Yes? Which one is that? the latest draft also recognizes the > >privacy problem as well. > > THe draft Bill provided in his mail to this forum. I have read Thomas's > draft and it will work, he provides two solutions. I would also like to > see a solution where the node administrator can provide a seed for the > EUI token too. Agreed there are two potential solutions on the table presently. But neither of them apply to autoimplimnentation do they? No, they don't, and hence the concern still remains for obvious reasons. I don't think I need to outline those reasons in detail as they have already been stated very eloquently by others quite nicely. > > > > IPv6 has not been widely deployed. > > > > Not likely to be either unless or until these problems in the > >spec are corrected. > > On the contrary. I believe IPv6 will be deployed on Intranet's first > and the deployment will happen from within to without and ISPs and > routers will be last to deploy IPv6, which is why we need transition > mechanisms like 6to4. On IntrAnets, maybe. But on a broad scale on the Internet, I have my doubts for several other reasons other than just privacy, 6to4 not withstanding. > > > > The vendors will fix it when the draft is worked. > >. > >. That may be, let's hope so. But there seems to be some > >.resistance to doing that presently. Hence public exposure is > >necessary in order for the proper pressure to be brought to > >bear in order to underscore that this problem MUST be fixed. > > As a note. Thomas Narten made us aware of this long ago before the > draft came out. Its been on the implementation issue agenda for a long > time. If anything was late it was a spec. Not the vendors. I know of > no vendor or implementor that has stated they would not fix this issue. Yes, possibly your conclusion here is correct, but the vendors should not be in a position to have to fix this problem. It should be part of the spec to begin with, which is the crux of my argument. > > > >> The press is being typical for the 90's. > > > > The press is always typical, regardless of the decade. > > At least in the U.S. it is far worse than it has ever been before I can > recall or from the history lessons I have absorbed. Well you may be correct here. But I doubt it really, as this has been a complaint for as long I I can remember and even before. SO the perception is a matter of conjecture. > What has happened > here is a complete abuse of the U.S. 1st ammendment which is the right > to free speech. The articles accusing the IETF and IPv6 of being flawed > and sitting on their backside, were like yelling Fire in a crowded > theatre. SOme do, and some postulate or oversee what need to be done. This is a fundamental truth in any society. As to the "Yelling of fire in a crowded theater" as it may relate to 1st amendment, I find this is always the charge that those that have been caught when they are guilty. Hardly a realistic defense in this instance. > > > 1. The IETF is not lax here at all. The problem is well understood and > under control. Folks can look at Thomas's spec and make comments > or shoot holes in it. I think its fine as a note, but would > like to see some manual options by node admins. Agreed. It needs also some reversal in the autoimplimentation as well. > > > 2. IPv6 is not flawed. If anything IPv6 is more equipped to deal > with this problem than IPv4 simply cause we have more bits to > randomize as one solution. IPv4 does not have that luxury. > This is an IPv4 problem too. I could use the "sophist" argument > that this uproar is even more reason to move to IPv6 quickly cause > we can fix it and IPv4 cannot. But that would be dishonorable > and unethical on my part and also yelling fire in the theatre. Yes to a point I would tend to agree. BUt we have more experience with IPv4, and hence have learned to deal with this problem. > > > 3. No Ipv6 implementors have stated they would not make the code > changes to support this in the Addr Conf spec. So saying > implementors may not fix it was a complete fabrication by > that assumption, or that we would ship products for IPv6 > forever with this issue. > > This could have affected IPv6 deployment, but it won't cause its not a > real problem, cause it will get fixed, cause it is not and never was a > basic flaw in the pristine and elegant design and architecture of the > Next Internet Generation Protocol, which we call IPv6. > > But more to the philosophical point which I find great irony with is the > entire notion of privacy. The best privacy is to live in the mountains > of some place in a cabin and not participate in the world, if one has > the ability to do so. But at the other extreme when you participate on > the Internet or as one of my colleagues put it elsewhere when you make a > phone call and give out your unlisted number your privacy is reduced. > > /jim Regards, -- Jeffrey A. Williams Spokesman INEGroup (Over 95k members strong!) CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 972-447-1894 Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 14 13:56:09 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9EKq2H03670 for ipng-dist; Thu, 14 Oct 1999 13:52:02 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9EKpfk03662 for ; Thu, 14 Oct 1999 13:51:42 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA22411 for ; Thu, 14 Oct 1999 13:51:40 -0700 (PDT) Received: from ausmail2.austin.ibm.com (ausmail2.austin.ibm.com [192.35.232.11]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA07647 for ; Thu, 14 Oct 1999 14:51:39 -0600 (MDT) Received: from netmail1.austin.ibm.com (netmail1.austin.ibm.com [9.53.250.96]) by ausmail2.austin.ibm.com (8.9.1/8.8.5) with ESMTP id PAA91218 for ; Thu, 14 Oct 1999 15:48:15 -0500 Received: from mojave.austin.ibm.com (mojave.austin.ibm.com [9.53.150.76]) by netmail1.austin.ibm.com (8.8.5/8.8.5) with ESMTP id PAA25526; Thu, 14 Oct 1999 15:51:35 -0500 Received: (from marquard@localhost) by mojave.austin.ibm.com (AIX4.3/8.9.3/8.7-client1.01) id PAA14358; Thu, 14 Oct 1999 15:51:33 -0500 To: Jeff Williams Cc: Jim Bound , Bill Frezza , ipng@sunroof.eng.sun.com, ICANN Comments , IFWP Discussion List , "etrigar@teleline.es" , "Esther (The clueless) Dyson" , "mmr@darwin.ptvy.ca.us" , "linda_wilson@radcliffe.edu" , "junsec@wide.ad.jp" , "gregcrew@iaccess.com.au" , "geraldine.capdeboscq@bull.fr" , "gconrades@polarisventures.com" , "fitzsimmon@dnb.com" , "gconrades@icann.org" , "gregcrew@icann.org" , "roberts@icann.org" Subject: Re: My InternetWeek op-ed column on IPv6 privacy issues References: <199910142001.QAA0000002399@quarry.zk3.dec.com> <3805CA2A.1A7BC702@ix.netcom.com> From: Dave Marquardt Date: 14 Oct 1999 15:51:32 -0500 In-Reply-To: Jeff Williams's message of "Thu, 14 Oct 1999 13:18:54 +0100" Message-ID: Lines: 12 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "20 Minutes to Nikko" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jeff Williams writes: > Agreed there are two potential solutions on the table presently. But > neither of them apply to autoimplimnentation do they? No, they don't, > and hence the concern still remains for obvious reasons. I don't > think I need to outline those reasons in detail as they have already been > stated very eloquently by others quite nicely. What do you mean by "autoimplimnentation"? Do you mean autoconfiguration? As I read Thomas' draft, it certainly does apply to autoconfiguration. -Dave -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 14 14:30:49 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9ELQrW03770 for ipng-dist; Thu, 14 Oct 1999 14:26:53 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9ELQhk03763 for ; Thu, 14 Oct 1999 14:26:43 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id OAA21505 for ; Thu, 14 Oct 1999 14:26:44 -0700 (PDT) Received: from dfw-ix10.ix.netcom.com (dfw-ix10.ix.netcom.com [206.214.98.10]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA15095 for ; Thu, 14 Oct 1999 14:26:44 -0700 (PDT) Received: (from smap@localhost) by dfw-ix10.ix.netcom.com (8.8.4/8.8.4) id QAA01383; Thu, 14 Oct 1999 16:18:22 -0500 (CDT) Received: from dal-tx47-45.ix.netcom.com(198.211.44.237) by dfw-ix10.ix.netcom.com via smap (V1.3) id rma001214; Thu Oct 14 16:17:23 1999 Message-ID: <3805D803.E14F7692@ix.netcom.com> Date: Thu, 14 Oct 1999 14:17:57 +0100 From: Jeff Williams Organization: INEG. Inc. (Spokesman INEGroup) X-Mailer: Mozilla 4.08 [en] (Win16; I) MIME-Version: 1.0 To: Dave Marquardt CC: Jim Bound , Bill Frezza , ipng@sunroof.eng.sun.com, ICANN Comments , IFWP Discussion List , "etrigar@teleline.es" , "Esther (The clueless) Dyson" , "mmr@darwin.ptvy.ca.us" , "linda_wilson@radcliffe.edu" , "junsec@wide.ad.jp" , "gregcrew@iaccess.com.au" , "geraldine.capdeboscq@bull.fr" , "gconrades@polarisventures.com" , "fitzsimmon@dnb.com" , "gconrades@icann.org" , "gregcrew@icann.org" , "roberts@icann.org" Subject: Re: My InternetWeek op-ed column on IPv6 privacy issues References: <199910142001.QAA0000002399@quarry.zk3.dec.com> <3805CA2A.1A7BC702@ix.netcom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dave and all, Yes excuse me, I did mean autoconfiguration. As I read Thomas' draft the fix for the MAC privacy problem is not addressed as a function of autoconfiguration. What part did you see that does? Dave Marquardt wrote: > Jeff Williams writes: > > Agreed there are two potential solutions on the table presently. But > > neither of them apply to autoimplimnentation do they? No, they don't, > > and hence the concern still remains for obvious reasons. I don't > > think I need to outline those reasons in detail as they have already been > > stated very eloquently by others quite nicely. > > What do you mean by "autoimplimnentation"? Do you mean > autoconfiguration? As I read Thomas' draft, it certainly does apply > to autoconfiguration. > > -Dave Regards, -- Jeffrey A. Williams Spokesman INEGroup (Over 95k members strong!) CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 972-447-1894 Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 14 14:33:43 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9ELVrB03794 for ipng-dist; Thu, 14 Oct 1999 14:31:53 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9ELVgk03787 for ; Thu, 14 Oct 1999 14:31:42 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id OAA22724 for ; Thu, 14 Oct 1999 14:31:29 -0700 (PDT) Received: from dfw-ix10.ix.netcom.com (dfw-ix10.ix.netcom.com [206.214.98.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA24738 for ; Thu, 14 Oct 1999 15:31:29 -0600 (MDT) Received: (from smap@localhost) by dfw-ix10.ix.netcom.com (8.8.4/8.8.4) id QAA03093; Thu, 14 Oct 1999 16:31:18 -0500 (CDT) Received: from dal-tx47-45.ix.netcom.com(198.211.44.237) by dfw-ix10.ix.netcom.com via smap (V1.3) id rma003035; Thu Oct 14 16:31:02 1999 Message-ID: <3805DB3A.E19ADA6A@ix.netcom.com> Date: Thu, 14 Oct 1999 14:31:41 +0100 From: Jeff Williams Organization: INEG. Inc. (Spokesman INEGroup) X-Mailer: Mozilla 4.08 [en] (Win16; I) MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com CC: IFWP Discussion List , "etrigar@teleline.es" , "Esther (The clueless) Dyson" , "mmr@darwin.ptvy.ca.us" , "linda_wilson@radcliffe.edu" , "junsec@wide.ad.jp" , "gregcrew@iaccess.com.au" , "geraldine.capdeboscq@bull.fr" , "gconrades@polarisventures.com" , "fitzsimmon@dnb.com" , "gconrades@icann.org" , "gregcrew@icann.org" , "roberts@icann.org" , Vinton Cref Subject: MCI and Vinton Cerf suggest IPv6 become a standard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk All, http://www.techweb.com/wire/story/TWB19991012S0009 Of course Vinton would make these recommendations, but the answers to the questions in this article are a bit too unspecified as to the security issues and barely address the privacy problem with IPv6 presently, not to mention other concerns such as v4tov6 issues. On the other side of this coin see: http://www.techweb.com/se/directlink.cgi?WIR1997060910 And interesting excerpt that seems contrary to what Vinton says is as follows: "MCI is testing IPv6 on its high-speed research backbone that carries traffic for the National Science Foundation, but it has no plans to deploy v6 on its internetMCI commercial service." and.... "From our customer perspective, we have no significant or moderate demand for IPv6," said Rob Hagens, MCI's director of Internet engineering. "They want a faster and cheaper IPv4." So one can easily conclude that old Vinton says one thing and his vaunted MCI/Sprint is doing another. Words don't meet the deeds I would say here Vinton old buddy! >;) Troubles in MCI town maybe??? Regards, -- Jeffrey A. Williams Spokesman INEGroup (Over 95k members strong!) CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 972-447-1894 Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 14 15:03:41 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9ELwVa04008 for ipng-dist; Thu, 14 Oct 1999 14:58:31 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9ELwKk04001 for ; Thu, 14 Oct 1999 14:58:21 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id OAA26522 for ; Thu, 14 Oct 1999 14:58:20 -0700 (PDT) Received: from inet-vrs-02.microsoft.com (mail2.microsoft.com [131.107.3.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id PAA05582 for ; Thu, 14 Oct 1999 15:58:20 -0600 (MDT) Received: from 157.54.9.104 by inet-vrs-02.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 14 Oct 1999 14:07:43 -0700 (Pacific Daylight Time) Received: by INET-IMC-02 with Internet Mail Service (5.5.2650.21) id <4705FY8G>; Thu, 14 Oct 1999 14:07:42 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D81014515C13@RED-MSG-50> From: Richard Draves To: "'Alain Durand'" Cc: "'IPng List'" , "'Erik Nordmark'" Subject: RE: (ngtrans) I-D ACTION:draft-ietf-ngtrans-6to4-03.txt Date: Thu, 14 Oct 1999 14:07:36 -0700 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk More thoughts on letting administrators configure address selection... One scenario that Alain raised is when longest-matching-prefix (LMP) does the wrong thing. Can administrative configuration of some kind of precedence be used to fix this? Here's a scenario: ISP A ISP B (prefixes 2004::/16, 2006::/16) --------- (prefixes 2005::/16, 2007::/16) / \ / | / \ / | site 1 site 2 site 3 (prefix 2006:1::/48) (prefixes 2004:2::/48, 2007:2::/48) (prefix 2005:3::/48) node 2006:1::1 node 2004:2::2, 2007:2::2 node 2005:3::3 The ISPs are using two TLAs (ran out of room in their first TLA, or mergers). Site 2 communicates a lot with site 1 and site 3, the admins are very motivated to optimize this communication. In fact this why site 2 is paying to multihome. Note that LMP does the wrong thing - for communication between site 1 and site 2, comparing 2006:1::1 with 2004:2::2, 2007:2::2 it will pick (2006:1::1, 2007:2::2). Similarly for communication between site 2 and site 3. Everyone is very upset. So assuming this is worth trying to fix with address selection (instead of the longer term proposals)... let's look at the precedence idea as a way of fixing this. Suppose site 3 configures its nodes to prefer destination addresses in the prefixes 2005::/16 and 2007::/16. Then 2005:3::3 will pick destination 2007:2::2 over 2004:2::2. Good. But in site 2 the problem is source address selection and it's more difficult. Preferring 2007:2::2 over 2004:2::2 will work for communication with 2005:3::3, but it's the wrong thing to do for communication with 2006:1::1. Here's one possibility - let the administrator configure preferred source prefixes (for source address selection) as well as precedences (for destination address selection) and buckets (for both source & destination address selection). So in this case, site 2 would configure something like 2004:2::/48 -> bucket 0, precedence 0, prefer source addrs matching 2004:2::/48 2007:2::/48 -> bucket 0, precedence 0, prefer source 2007:2::/48 2004::/16 -> bucket 0, precedence 1, prefer source 2004:2::/48 2006::/16 -> bucket 0, precedence 1, prefer source 2004:2::/48 2005::/16 -> bucket 0, precedence 1, prefer source 2007:2::/48 2007::/16 -> bucket 0, precedence 1, prefer source 2007:2::/48 ::/0 -> bucket 0, precedence 2, prefer source ::/0 2002::/16 -> bucket 1, precedence 3, prefer source 2002::/16 ::/96 -> bucket 2, precedence 4, prefer source ::/96 This is quite flexible, of course it's also getting quite complicated... 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 Thu Oct 14 17:49:23 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9F0k5v04345 for ipng-dist; Thu, 14 Oct 1999 17:46:05 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.81.144] (may be forged)) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9F0jtk04338 for ; Thu, 14 Oct 1999 17:45:55 -0700 (PDT) Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id RAA471421; Thu, 14 Oct 1999 17:45:53 -0700 (PDT) Date: Thu, 14 Oct 1999 17:43:26 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Treatment of scoped addresses carried in extension headers To: Brian Zill Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3D2036E25376D31197A100805FEAD892712E84@x1red-msg-14.itg-messaging.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 > 3) Treat scoped addresses as illegal in such headers and drop the packet. > This also has the advantage of being easy to implement, and is probably the > most defensible choice since the prescribed behavior is always clear and > unambiguous. But it has the disadvantage that it prevents some possible > methods of using the protocol (I can imagine some mobility scenarios where > you might want to have a scoped care-of address or a scoped home address, > for example). It also has the disadvantage that we'd need to update some > specs. draft-ietf-ipngwg-site-prefixes does specify how site-local addresses can be used in mobile IPv6's use of extension headers and options (in such a way that it doesn't cause confusion). In this case (a mobile node which has been assigned site-local address(es) that moves outside its site) the mobile node becomes multi-sited and has to take appropriate care when dealing with non-global addresses. 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 14 18:20:22 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9F1HKk04446 for ipng-dist; Thu, 14 Oct 1999 18:17:20 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9F1GQk04439 for ; Thu, 14 Oct 1999 18:16:42 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id SAA20003 for ; Thu, 14 Oct 1999 18:15:45 -0700 (PDT) Received: from mailext04.compaq.com (mailext04.compaq.com [207.18.199.42]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA13460 for ; Thu, 14 Oct 1999 18:15:44 -0700 (PDT) Received: from mailint12.im.hou.compaq.com (mailint12.compaq.com [207.18.199.190]) by mailext04.compaq.com (Postfix) with ESMTP id DE32B104BFE; Thu, 14 Oct 1999 20:15:43 -0500 (CDT) Received: by mailint12.im.hou.compaq.com (Postfix, from userid 12345) id EB2244FB43; Thu, 14 Oct 1999 20:15:28 -0500 (CDT) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint12.im.hou.compaq.com (Postfix) with ESMTP id 8E5C44C902; Thu, 14 Oct 1999 20:15:27 -0500 (CDT) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id VAA0000002531; Thu, 14 Oct 1999 21:15:39 -0400 (EDT) From: Jim Bound Message-Id: <199910150115.VAA0000002531@quarry.zk3.dec.com> To: Jeff Williams Cc: Dave Marquardt , Jim Bound , Bill Frezza , ipng@sunroof.eng.sun.com, ICANN Comments , IFWP Discussion List , "etrigar@teleline.es" , "Esther (The clueless) Dyson" , "mmr@darwin.ptvy.ca.us" , "linda_wilson@radcliffe.edu" , "junsec@wide.ad.jp" , "gregcrew@iaccess.com.au" , "geraldine.capdeboscq@bull.fr" , "gconrades@polarisventures.com" , "fitzsimmon@dnb.com" , "gconrades@icann.org" , "gregcrew@icann.org" , "roberts@icann.org" Subject: Re: My InternetWeek op-ed column on IPv6 privacy issues In-reply-to: Your message of "Thu, 14 Oct 1999 14:17:57 BST." <3805D803.E14F7692@ix.netcom.com> Date: Thu, 14 Oct 1999 21:15:39 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a good technical question. > Yes excuse me, I did mean autoconfiguration. As I read >Thomas' draft the fix for the MAC privacy problem is not >addressed as a function of autoconfiguration. What part >did you see that does? From: draft-ietf-ipngwg-addrconf-privacy-00.txt The following text defines the adjuncts to stateless addrconf RFC 2462 what would need to be done, and the modifications to RFC 2462 to resolve the issue at hand. On this list today and yesterday I was also hearing folks would want manual configuration too. Me too. As a third option. Having implemented addr conf I will say this is very doable and its a matter of the IETF working on the spec (which is in process) and wrapping this up. So as I read the attached below the issue is addressed for address autoconfiguration. I would suggest we just move on to the technical work at hand and work this spec out in the working group. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 3. Protocol Description The goal of this section is to define procedures that: 1) Result in a different interface identifier being generated at each system restart or attachment to a network. 2) Produce a sequence of interface identifiers that appear to be random in the sense that it is difficult for an outside observer to predict a future identifier based on a current one and it is difficult to determine previous identifiers knowing only the present one. 3.1. When Stable Storage is Present The following algorithm assumes the presence of a 64-bit "history value" that is used as input in generating an interface identifier. The very first time the system boots (i.e., out-of-the-box), any value can be used including all zeros. Whenever a new interface identifier is generated, its value is saved in the seed for the next iteration of the process. Section 5.3 of [ADDRCONF] describes the steps for generating a link- local address when an interface becomes enabled. This document modifies that step in the following way. Rather than use interface identifiers generated as described in [ADDRARCH], the identifier is generated as follows: 1) Take the history value from the previous iteration (or 0 if there is no previous value) and append to it the interface identifier generated as described in [ADDRARCH]. 2) Compute the MD5 message digest [MD5] over the quantity created in step 1). 3) Take the left-most 64-bits of the MD5 digest and set bit 6 (the left-most bit is numbered 0) to zero. This creates an interface identifier with the universal/local bit indicating local significance only. Use the resultant identifier for generating addresses as outlined in [ADDRCONF]. That is, use the interface identifier to generate a link-local and other appropriate addresses. 4) Save the interface identifier created in step 3) in stable storage as the history value to be used in the next iteration of the algorithm. MD5 was chosen for convenience, not because of strict requirements. IPv6 nodes are already required to implement MD5 as part of IPsec [IPSEC], thus the code will already be present on IPv6 machines. 3.2. In The Absence of Stable Storage In the absence of stable storage, no history information will be available to generate a pseudo-random sequence of interface identifiers. Consequently, identifiers will need to be generated at random. A number of techniques might be appropriate. Consult [RANDOM] for suggestions on good sources for obtaining random numbers. Note that even though a machine may not have stable storage for storing the previously using interface identifier, they will in many cases have configuration information that differs from one machine to another (e.g., user identity, security keys, etc.). One approach to generating random interface identifiers in such cases is to use the configuration information to generate some data bits (which may be remain constant for the life of the machine, but will vary from one machine to another), append some random data and compute the MD5 digest as before. The remaining details for generating addresses would be analogous to those of the previous section. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 14 18:36:36 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9F1Sjl04481 for ipng-dist; Thu, 14 Oct 1999 18:28:45 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9F1SYk04474 for ; Thu, 14 Oct 1999 18:28:36 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id SAA07069 for ; Thu, 14 Oct 1999 18:28:35 -0700 (PDT) Received: from ns.uk.newbridge.com (ns.uk.newbridge.com [194.223.115.67]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id TAA10563 for ; Thu, 14 Oct 1999 19:28:33 -0600 (MDT) Received: (from smtpd@localhost) by ns.uk.newbridge.com (8.6.12/8.6.12) id CAA24943; Fri, 15 Oct 1999 02:28:08 +0100 Received: from uk-gw1.uk.newbridge.com(194.223.115.70), claiming to be "newport-mh1.uk.newbridge.com" via SMTP by ns.uk.newbridge.com, id smtpdAAAa24941; Fri Oct 15 02:28:03 1999 Received: from [138.120.24.25] by newport-mh1.uk.newbridge.com with ESMTP; Fri, 15 Oct 1999 02:28:02 +0100 Message-Id: <4.2.0.58.19991015021758.00a9fdc8@127.0.0.1> X-Sender: bcrosby/emamail01.uk.newbridge.com@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 15 Oct 1999 02:20:42 +0100 To: Jeff Williams From: Ben Crosby Subject: Re: MCI and Vinton Cerf suggest IPv6 become a standard Cc: ipng@sunroof.eng.sun.com, IFWP Discussion List In-Reply-To: <3805DB3A.E19ADA6A@ix.netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Just a quick point for those who are too busy to read the articles: > On the other side of this coin see: >http://www.techweb.com/se/directlink.cgi?WIR1997060910 To be fair, you have decided to extract quotes from an article which is now over two years old. It is possible that MCI may have updated their plans. Anyone care to comment ? Ben. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 14 20:20:39 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9F3HAV04680 for ipng-dist; Thu, 14 Oct 1999 20:17:10 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9F3Gok04673 for ; Thu, 14 Oct 1999 20:16:54 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id UAA01521 for ; Thu, 14 Oct 1999 20:16:12 -0700 (PDT) Received: from dfw-ix3.ix.netcom.com (dfw-ix3.ix.netcom.com [206.214.98.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA02314 for ; Thu, 14 Oct 1999 21:16:12 -0600 (MDT) Received: (from smap@localhost) by dfw-ix3.ix.netcom.com (8.8.4/8.8.4) id WAA18724; Thu, 14 Oct 1999 22:08:21 -0500 (CDT) Received: from dal-tx1-06.ix.netcom.com(207.94.120.70) by dfw-ix3.ix.netcom.com via smap (V1.3) id rma018645; Thu Oct 14 22:08:03 1999 Message-ID: <38062A35.BFF5087E@ix.netcom.com> Date: Thu, 14 Oct 1999 20:08:39 +0100 From: Jeff Williams Organization: INEG. Inc. (Spokesman INEGroup) X-Mailer: Mozilla 4.08 [en] (Win16; I) MIME-Version: 1.0 To: Jim Bound CC: Dave Marquardt , Bill Frezza , ipng@sunroof.eng.sun.com, ICANN Comments , IFWP Discussion List , "etrigar@teleline.es" , "Esther (The clueless) Dyson" , "mmr@darwin.ptvy.ca.us" , "linda_wilson@radcliffe.edu" , "junsec@wide.ad.jp" , "gregcrew@iaccess.com.au" , "geraldine.capdeboscq@bull.fr" , "gconrades@polarisventures.com" , "fitzsimmon@dnb.com" , "gconrades@icann.org" , "gregcrew@icann.org" , "roberts@icann.org" Subject: Re: My InternetWeek op-ed column on IPv6 privacy issues References: <199910150115.VAA0000002531@quarry.zk3.dec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim and all, Jim Bound wrote: > This is a good technical question. > > > Yes excuse me, I did mean autoconfiguration. As I read > >Thomas' draft the fix for the MAC privacy problem is not > >addressed as a function of autoconfiguration. What part > >did you see that does? > > From: draft-ietf-ipngwg-addrconf-privacy-00.txt > The following text defines the adjuncts to stateless addrconf RFC 2462 > what would need to be done, and the modifications to RFC 2462 to resolve > the issue at hand. On this list today and yesterday I was also hearing > folks would want manual configuration too. Me too. As a third option. > Having implemented addr conf I will say this is very doable and its a > matter of the IETF working on the spec (which is in process) and > wrapping this up. I agree here and this is in part one method of addressing the the privacy concerns. But I would strongly suggest for reasons that I have already stated the the autoconfiguration include that the privacy concerns be addressed as a default of the spec. If this is done much of the problem with IPv6 in this area would be adequately addressed. I also agree that a manual configuration too be included as has been suggested by others, but be a second priority to the autoconfiguration fix. > > > So as I read the attached below the issue is addressed for address > autoconfiguration. > > I would suggest we just move on to the technical work at hand and work > this spec out in the working group. > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > 3. Protocol Description > > The goal of this section is to define procedures that: > > 1) Result in a different interface identifier being generated at each > system restart or attachment to a network. > > 2) Produce a sequence of interface identifiers that appear to be > random in the sense that it is difficult for an outside observer > to predict a future identifier based on a current one and it is > difficult to determine previous identifiers knowing only the > present one. > > 3.1. When Stable Storage is Present > > The following algorithm assumes the presence of a 64-bit "history > value" that is used as input in generating an interface identifier. > The very first time the system boots (i.e., out-of-the-box), any > value can be used including all zeros. Whenever a new interface > identifier is generated, its value is saved in the seed for the next > iteration of the process. > > Section 5.3 of [ADDRCONF] describes the steps for generating a link- > local address when an interface becomes enabled. This document > modifies that step in the following way. Rather than use interface > identifiers generated as described in [ADDRARCH], the identifier is > generated as follows: > > 1) Take the history value from the previous iteration (or 0 if there > is no previous value) and append to it the interface identifier > generated as described in [ADDRARCH]. > 2) Compute the MD5 message digest [MD5] over the quantity created in > step 1). > 3) Take the left-most 64-bits of the MD5 digest and set bit 6 (the > left-most bit is numbered 0) to zero. This creates an interface > identifier with the universal/local bit indicating local > significance only. Use the resultant identifier for generating > addresses as outlined in [ADDRCONF]. That is, use the interface > identifier to generate a link-local and other appropriate > addresses. > 4) Save the interface identifier created in step 3) in stable storage > as the history value to be used in the next iteration of the > algorithm. > > MD5 was chosen for convenience, not because of strict requirements. > IPv6 nodes are already required to implement MD5 as part of IPsec > [IPSEC], thus the code will already be present on IPv6 machines. > > 3.2. In The Absence of Stable Storage > > In the absence of stable storage, no history information will be > available to generate a pseudo-random sequence of interface > identifiers. Consequently, identifiers will need to be generated at > random. A number of techniques might be appropriate. Consult [RANDOM] > for suggestions on good sources for obtaining random numbers. Note > that even though a machine may not have stable storage for storing > the previously using interface identifier, they will in many cases > have configuration information that differs from one machine to > another (e.g., user identity, security keys, etc.). One approach to > generating random interface identifiers in such cases is to use the > configuration information to generate some data bits (which may be > remain constant for the life of the machine, but will vary from one > machine to another), append some random data and compute the MD5 > digest as before. The remaining details for generating addresses > would be analogous to those of the previous section. > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > /jim Regards, -- Jeffrey A. Williams Spokesman INEGroup (Over 95k members strong!) CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 972-447-1894 Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 14 23:43:43 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9F6emg04884 for ipng-dist; Thu, 14 Oct 1999 23:40:48 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9F6ebk04877 for ; Thu, 14 Oct 1999 23:40:38 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id XAA24334 for ; Thu, 14 Oct 1999 23:40:37 -0700 (PDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id XAA15470 for ; Thu, 14 Oct 1999 23:40:38 -0700 (PDT) Received: from 157.54.9.101 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 14 Oct 1999 23:40:36 -0700 (Pacific Daylight Time) Received: by INET-IMC-01 with Internet Mail Service (5.5.2650.21) id <48HFS6NA>; Thu, 14 Oct 1999 23:40:36 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D81014515C20@RED-MSG-50> From: Richard Draves To: "'IPng List'" Subject: reconnecting an interface Date: Thu, 14 Oct 1999 23:40:33 -0700 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk My driver interface can tell me when an interface is disconnected/reconnected to its media. For example, I get an event when an ethernet cable is unplugged and then another event when it's plugged back in. I'm trying to take advantage of this in MSR IPv6. Of course I don't know if the interface reconnected to the same subnet that it left. If it did reconnect to the same subnet, then it seems reasonable for this to be minimally intrusive to applications. If it reconnected to a different subnet, then it seems reasonable to discard old information learned from auto-configuration and auto-configure anew. My preliminary thoughts are: 1. When disconnecting from the media: do nothing. Addresses on the interface survive and continue to age normally, routes on the interface survive, etc. 2. When reconnecting to media: - set REACHABLE neighbor cache entries to the STALE state - set auto-configured unicast address lifetimes down to a small value (the length of time that we'll attempt to get an RA - max number of router solicits * solicit interval) - put all unicast addresses into the tentative state and restart duplicate address detection - set lifetimes of routes learned from autoconfig (default routers, on-link prefixes) down to the same small value - send out MLD reports, rejoining any multicast addresses assigned to the interface - start sending router solicitations The idea being that if we did reconnect to the same subnet, then we'll get an RA that will reset all the lifetimes back to their usual values. However if we are connected to a new subnet, then the old addresses and routes will disappear and we'll have acquired new addresses and routes. However any manually configured addresses or routes will not disappear. Does this sound reasonable? Am I missing anything? 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 Thu Oct 14 23:56:06 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9F6rAZ04911 for ipng-dist; Thu, 14 Oct 1999 23:53:10 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9F6qxk04904 for ; Thu, 14 Oct 1999 23:53:00 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id XAA21027 for ; Thu, 14 Oct 1999 23:52:59 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA18924 for ; Thu, 14 Oct 1999 23:52:58 -0700 (PDT) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id PAA00204; Fri, 15 Oct 1999 15:52:51 +0900 (JST) To: Richard Draves cc: "'IPng List'" In-reply-to: richdr's message of Thu, 14 Oct 1999 23:40:33 MST. <4D0A23B3F74DD111ACCD00805F31D81014515C20@RED-MSG-50> 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: reconnecting an interface From: itojun@iijlab.net Date: Fri, 15 Oct 1999 15:52:51 +0900 Message-ID: <202.939970371@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >My driver interface can tell me when an interface is >disconnected/reconnected to its media. For example, I get an event when an >ethernet cable is unplugged and then another event when it's plugged back >in. You may want to take a look at KAME nomadic node hack by Tatsuya Jinmei, which is described in section 3.4 of the following paper: http://www.isoc.org/inet99/proceedings/4s/4s_2.htm The code is available in normal KAME distribution and works well. >2. When reconnecting to media: >- set REACHABLE neighbor cache entries to the STALE state >- set auto-configured unicast address lifetimes down to a small value (the >length of time that we'll attempt to get an RA - max number of router >solicits * solicit interval) >- put all unicast addresses into the tentative state and restart duplicate >address detection >- set lifetimes of routes learned from autoconfig (default routers, on-link >prefixes) down to the same small value >- send out MLD reports, rejoining any multicast addresses assigned to the >interface >- start sending router solicitations Hmm, KAME code takes care about neighbor cache, reachability of router (mangle default router list/prefix list), and RS/RA. It would be a good idea to do something for MLD and DAD as well. 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 Fri Oct 15 00:06:20 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9F73MA04940 for ipng-dist; Fri, 15 Oct 1999 00:03:22 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9F73Ak04933 for ; Fri, 15 Oct 1999 00:03:11 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id AAA25624 for ; Fri, 15 Oct 1999 00:03:10 -0700 (PDT) Received: from anise.tte.vtt.fi (anise.tte.vtt.fi [130.188.52.29]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA21533 for ; Fri, 15 Oct 1999 00:03:10 -0700 (PDT) Received: (from msa@localhost) by anise.tte.vtt.fi (8.8.5/8.8.5) id KAA05655; Fri, 15 Oct 1999 10:03:08 +0300 (EET DST) Date: Fri, 15 Oct 1999 10:03:08 +0300 (EET DST) From: Markku Savela Message-Id: <199910150703.KAA05655@anise.tte.vtt.fi> To: ipng@sunroof.eng.sun.com In-reply-to: <199910150115.VAA0000002531@quarry.zk3.dec.com> (message from Jim Bound on Thu, 14 Oct 1999 21:15:39 -0400) Subject: Re: My InternetWeek op-ed column on IPv6 privacy issues Reply-to: msa@hemuli.tte.vtt.fi (Markku Savela) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [I removed the long CC list] This discussion seems to lead to a situation where IP-addresses are never "permanent", just when I was hoping that IPv6 would bring enough addresses to use, so that I could have permanent addresses for myself... This is a dilemma... - for some things I would like to use random (src) address - but, I still would like to have permantent address so that my SMTP daemon on mobile phone [:-)] can be contacted (or that it can receive voice over IP calls). Or just that I can run WEB server on my home machine, to be more realistic. Is this another dimension to the source address selection discussion? -- Markku Savela (msa@hemuli.tte.vtt.fi), Technical Research Centre of Finland Multimedia Systems, P.O.Box 1203,FIN-02044 VTT,http://www.vtt.fi/tte/staff/msa/ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 15 00:10:26 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9F793c04967 for ipng-dist; Fri, 15 Oct 1999 00:09:03 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9F78sk04960 for ; Fri, 15 Oct 1999 00:08:55 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id AAA15270 for ; Fri, 15 Oct 1999 00:08:54 -0700 (PDT) Received: from jazz-1.trumpet.com.au (jazz-1.trumpet.com.au [203.5.119.62]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA13517 for ; Fri, 15 Oct 1999 01:08:53 -0600 (MDT) Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id SAA19982 for ; Fri, 15 Oct 1999 18:08:51 +1100 (EST) Date: Fri, 15 Oct 1999 18:08:51 +1100 (EST) From: Peter Tattam To: IPNG Mailing List Subject: Comments on draft-ietf-ipngwg-addrconf-privacy-00.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all. Just weighing in on this topic, I have the following to say, and apologies if it overlaps or has been said before. I believe I raised the topic several months ago, but nobody seemed to take much notice, but I'm glad that the issues have now been discussed in more detail. Mind you there has been little outcome except draft-ietf-ipngwg-addrconf-privacy-00.txt which I think answers the technical issue elegantly. Given the current public concern over the privacy issue, I have decided that I might improve our product by having an optional facility for the stack to automatically change it's address using draft-ietf-ipngwg-addrconf-privacy-00.txt. This raises a number of issues.. 1. How frequent should an address change be. One could make the changes on a regular basis, and still retain reasonable utilization of the stack. I would suggest making it user configuarable, but there may be some practical limitations. It could potentially be as rapid as an address change per TCP connection. The issues to consider would be - what should be the minimum time between address changes - what load on the network would be required. Presumably only one or two ND exchanges, as well as the duplicate detection phase. Maybe also some dynamic DNS. The address change could be scheduled to happen in advance if necessary. - how should the old addresses in the sequence be deprecated, presumably active sockets should continue to work, but new connections should only use the new address. - how long should we continue to respond to a deprecated address if there are no active sockets bound to that address. In all these areas, I presume there would be similar semantics to multihoming. 2. With my ISP hat on, there might be significant security issues with allowing this type of mechanism to be common place, and it also brings into the spotlght address auto config even without the random address assignment. It is important for ISPs to track which user is one which address for accounting reasons and also for security reasons. >From the accounting side, if an ISP can't tell which user is using which address, some traffic might be untraceable. Systems for logging traffic might result in incorrect records, and there might also be implications for protocols like RADIUS. >From the security side, an ISP must have the ability to locate and filter a user based on IP address since a potentially hostile user may be mounting a network attack, and often the only way of locating the user is by IP address. Having a random component in the address could be problematic. Having raised both of these ISP issues, I could debunk them by the comment that in practice, a user might be identifiable by the top 64 bits of the address anyway. While this looks likely to be the case for PPP, I am not so sure for other technologies like cable or xDSL. If it was indeed the case, the top 64 bits of an IPv6 address would then degenerate into the situation we currently have in IPv4 with privacy of addresses. The issue of auto addr conf for IPv6 may also cause difficulties for technologies that rely on strong binding between mac addresses and IP addresses. e.g. Cable & xDSL. How does the ISP deal with this? Do they filter and account for IPv6 traffic *only* matching the mac address of the customers equipment, or do they allow willy nilly Ipv6 addresses using auto conf and track and account using the MAC address on the wire which is only available at the connect point. This hasn't been an issue in v4 because addresses are so scarce that the ISP can dictate to the customer which Ipv4 address they must use. Not so in IPv6. Typically tools for logging are based on IP addresses which is usefule because the logs can be applied at all parts of the network. Having to do it by mac address means that the logging would need to be done closer to the client which might be impractical under some circumstances. There is a counter argument that would imply that customers would need to be protected from each other anyway. Does this then imply that each customer receives their own /64 presumably staticly configured at the ISP end possibily defeating the whole purpose of address autoconfig. Regards Peter -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 15 00:19:53 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9F7GeJ04997 for ipng-dist; Fri, 15 Oct 1999 00:16:40 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9F7GCk04990 for ; Fri, 15 Oct 1999 00:16:18 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id AAA26287 for ; Fri, 15 Oct 1999 00:16:13 -0700 (PDT) Received: from jazz-1.trumpet.com.au (jazz-1.trumpet.com.au [203.5.119.62]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA15173 for ; Fri, 15 Oct 1999 01:16:12 -0600 (MDT) Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id SAA20542; Fri, 15 Oct 1999 18:16:07 +1100 (EST) Date: Fri, 15 Oct 1999 18:16:06 +1100 (EST) From: Peter Tattam To: Richard Draves cc: "'IPng List'" Subject: Re: reconnecting an interface In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D81014515C20@RED-MSG-50> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Richard, I already have this issue with multiple profiles in our stack. I resolved it by completely flushing the ND cache for that interface and doing a router solicit on all interfaces every time the config changes to get a fresh view of the universe. I would consider that pulling the ethernet cable out & plugging back again is equivalent to a total reconfig, *unless* you still have active interfaces in another media. >From the upper layers point of view, they continue to operate with the addresses that they were initiated with. This potentially allows me to change config to another profile, do a bit of work, switch back to the original profile and the TCP connections are still working. I believe the TCP standard permits this sequence of events. Of course if the other end of the connections decide that they want to terminate the connections, it is their business and application running my host should be robust enough to deal with that eventuality. Peter On Thu, 14 Oct 1999, Richard Draves wrote: > My driver interface can tell me when an interface is > disconnected/reconnected to its media. For example, I get an event when an > ethernet cable is unplugged and then another event when it's plugged back > in. > > I'm trying to take advantage of this in MSR IPv6. Of course I don't know if > the interface reconnected to the same subnet that it left. If it did > reconnect to the same subnet, then it seems reasonable for this to be > minimally intrusive to applications. If it reconnected to a different > subnet, then it seems reasonable to discard old information learned from > auto-configuration and auto-configure anew. > > My preliminary thoughts are: > > 1. When disconnecting from the media: do nothing. Addresses on the interface > survive and continue to age normally, routes on the interface survive, etc. > > 2. When reconnecting to media: > - set REACHABLE neighbor cache entries to the STALE state > - set auto-configured unicast address lifetimes down to a small value (the > length of time that we'll attempt to get an RA - max number of router > solicits * solicit interval) > - put all unicast addresses into the tentative state and restart duplicate > address detection > - set lifetimes of routes learned from autoconfig (default routers, on-link > prefixes) down to the same small value > - send out MLD reports, rejoining any multicast addresses assigned to the > interface > - start sending router solicitations > > The idea being that if we did reconnect to the same subnet, then we'll get > an RA that will reset all the lifetimes back to their usual values. However > if we are connected to a new subnet, then the old addresses and routes will > disappear and we'll have acquired new addresses and routes. However any > manually configured addresses or routes will not disappear. > > Does this sound reasonable? Am I missing anything? > > 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 > -------------------------------------------------------------------- > -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 15 00:20:33 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9F7J9M05006 for ipng-dist; Fri, 15 Oct 1999 00:19:09 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9F7J0k04999 for ; Fri, 15 Oct 1999 00:19:00 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id AAA00131 for ; Fri, 15 Oct 1999 00:19:01 -0700 (PDT) Received: from jazz-1.trumpet.com.au (jazz-1.trumpet.com.au [203.5.119.62]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA26177 for ; Fri, 15 Oct 1999 00:18:59 -0700 (PDT) Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id SAA20624; Fri, 15 Oct 1999 18:18:49 +1100 (EST) Date: Fri, 15 Oct 1999 18:18:49 +1100 (EST) From: Peter Tattam To: Markku Savela cc: ipng@sunroof.eng.sun.com Subject: Re: My InternetWeek op-ed column on IPv6 privacy issues In-Reply-To: <199910150703.KAA05655@anise.tte.vtt.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 15 Oct 1999, Markku Savela wrote: > [I removed the long CC list] > > This discussion seems to lead to a situation where IP-addresses are > never "permanent", just when I was hoping that IPv6 would bring enough > addresses to use, so that I could have permanent addresses for myself... > > This is a dilemma... > > - for some things I would like to use random (src) address > > - but, I still would like to have permantent address so that my SMTP > daemon on mobile phone [:-)] can be contacted (or that it can > receive voice over IP calls). Or just that I can run WEB server on > my home machine, to be more realistic. > > Is this another dimension to the source address selection discussion? Technically it is plausible to have a mix of both types of addresses. You could use set of addresses for making connects, while your permanent addresses could be used only for receiving connections. Now that is an interesting aspect of Ipv6 that could be a good selling point. Peter -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 15 01:04:55 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9F81nv05101 for ipng-dist; Fri, 15 Oct 1999 01:01:49 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9F81ck05094 for ; Fri, 15 Oct 1999 01:01:40 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id BAA02518 for ; Fri, 15 Oct 1999 01:01:39 -0700 (PDT) Received: from dfw-ix10.ix.netcom.com (dfw-ix10.ix.netcom.com [206.214.98.10]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA09638 for ; Fri, 15 Oct 1999 01:01:38 -0700 (PDT) Received: (from smap@localhost) by dfw-ix10.ix.netcom.com (8.8.4/8.8.4) id DAA15432; Fri, 15 Oct 1999 03:00:49 -0500 (CDT) Received: from dal-tx1-16.ix.netcom.com(207.94.120.80) by dfw-ix10.ix.netcom.com via smap (V1.3) id rma015398; Fri Oct 15 03:00:15 1999 Message-ID: <38066EB1.A966610E@ix.netcom.com> Date: Fri, 15 Oct 1999 01:00:51 +0100 From: Jeff Williams Organization: INEG. Inc. (Spokesman INEGroup) X-Mailer: Mozilla 4.08 [en] (Win16; I) MIME-Version: 1.0 To: Peter Tattam CC: Markku Savela , ipng@sunroof.eng.sun.com Subject: Re: My InternetWeek op-ed column on IPv6 privacy issues References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Peter and all, Peter Tattam wrote: > On Fri, 15 Oct 1999, Markku Savela wrote: > > > [I removed the long CC list] > > > > This discussion seems to lead to a situation where IP-addresses are > > never "permanent", just when I was hoping that IPv6 would bring enough > > addresses to use, so that I could have permanent addresses for myself... > > > > This is a dilemma... > > > > - for some things I would like to use random (src) address > > > > - but, I still would like to have permantent address so that my SMTP > > daemon on mobile phone [:-)] can be contacted (or that it can > > receive voice over IP calls). Or just that I can run WEB server on > > my home machine, to be more realistic. > > > > Is this another dimension to the source address selection discussion? > > Technically it is plausible to have a mix of both types of addresses. You > could use set of addresses for making connects, while your permanent addresses > could be used only for receiving connections. Now that is an interesting > aspect of Ipv6 that could be a good selling point. Yep, you sure could do as you suggest here. I might be a good point to make for "Best Practice"?? At least an "Preferred option"?? > > > Peter > > -- > Peter R. Tattam peter@trumpet.com > Managing Director, Trumpet Software International Pty Ltd > Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- Regards, -- Jeffrey A. Williams Spokesman INEGroup (Over 95k members strong!) CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 972-447-1894 Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 15 01:06:28 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9F84sp05110 for ipng-dist; Fri, 15 Oct 1999 01:04:54 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9F84ik05103 for ; Fri, 15 Oct 1999 01:04:44 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id BAA19096 for ; Fri, 15 Oct 1999 01:04:44 -0700 (PDT) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA25563 for ; Fri, 15 Oct 1999 02:04:39 -0600 (MDT) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id KAA16180; Fri, 15 Oct 1999 10:04:37 +0200 (MET DST) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id KAA13928; Fri, 15 Oct 1999 10:04:36 +0200 (MET DST) Message-Id: <199910150804.KAA13928@givry.inria.fr> From: Francis Dupont To: Thomas Narten cc: ipng@sunroof.eng.sun.com Subject: Re: draft-ietf-ipngwg-addrconf-privacy-00.txt In-reply-to: Your message of Thu, 14 Oct 1999 15:07:20 EDT. <199910141907.PAA23716@rotala.raleigh.ibm.com> Date: Fri, 15 Oct 1999 10:04:35 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Regarding the protocol description, per comments and the discussion in Oslo, the mechanism itself will likely be moved to an appendix or simply be thrown out. It's too simplistic to be useful in the cases of real interest. => please KISS. The next version of the document will define a mechanism that keeps the EUI-64-derived interface ID for link-local and site-local addresses, but allows the global scope addresses to have random interface IDs. In addition, nodes need to have both a "permanent" address (i.e., one with the EUI-64-derived address) that is "public" so that the node can act as a server and accept incoming connections. Simultaneously, nodes will want to act as clients, initiating connections from addresses with the random interface ID component. Both addresses will be in effect simultaneously. => this seems for me rather complex... A stupid random and dynamic interface ID should be enough for untracebility and not worse than current dynamic IPv4 addresses. If I'd like to have both a server at a well known address and a personal box for XXX web browsing (in order to get a nice picture for my screen background :-) then I should use a second box... The interested reader may wish to think about how this might impact source address selection algorithms that are invoked when initiating connections. => argh! Francis.Dupont@inria.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Oct 15 01:10:17 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9F88pk05146 for ipng-dist; Fri, 15 Oct 1999 01:08:51 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9F88fk05139 for ; Fri, 15 Oct 1999 01:08:43 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id BAA19312 for ; Fri, 15 Oct 1999 01:08:41 -0700 (PDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA26321 for ; Fri, 15 Oct 1999 02:08:40 -0600 (MDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id JAA83880 for ; Fri, 15 Oct 1999 09:08:38 +0100 Received: from hursley.ibm.com (lig32-239-151-207.emea.lig-dial.ibm.com [32.239.151.207]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id JAA22376 for ; Fri, 15 Oct 1999 09:08:36 +0100 (BST) Message-ID: <3806204F.CA060A2D@hursley.ibm.com> Date: Thu, 14 Oct 1999 13:26:23 -0500 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: More misinformation on IPv6 References: <38053B71.D7D763D2@dnrc.bell-labs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk What we need is for someone to write a one or two page text explaining in unemotional language why the security and privacy issues are essentially bogus, and what the IETF is doing for those who nevertheless remain concerned. A good text along these lines can be the basis for an appropriate PR response, and I would suggest that the IAB endorse it. Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Oct 15 01:28:49 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9F8Pnx05207 for ipng-dist; Fri, 15 Oct 1999 01:25:49 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9F8Pek05200 for ; Fri, 15 Oct 1999 01:25:40 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id BAA26113 for ; Fri, 15 Oct 1999 01:25:39 -0700 (PDT) Received: from dfw-ix13.ix.netcom.com (dfw-ix13.ix.netcom.com [206.214.98.13]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA29287 for ; Fri, 15 Oct 1999 02:25:39 -0600 (MDT) Received: (from smap@localhost) by dfw-ix13.ix.netcom.com (8.8.4/8.8.4) id DAA13072; Fri, 15 Oct 1999 03:25:26 -0500 (CDT) Received: from dal-tx1-16.ix.netcom.com(207.94.120.80) by dfw-ix13.ix.netcom.com via smap (V1.3) id rma013059; Fri Oct 15 03:24:57 1999 Message-ID: <3806747E.D20D4F54@ix.netcom.com> Date: Fri, 15 Oct 1999 01:25:36 +0100 From: Jeff Williams Organization: INEG. Inc. (Spokesman INEGroup) X-Mailer: Mozilla 4.08 [en] (Win16; I) MIME-Version: 1.0 To: Brian E Carpenter CC: ipng@sunroof.eng.sun.com, IFWP Discussion List , tbridis@ap.org Subject: Re: More misinformation on IPv6 References: <38053B71.D7D763D2@dnrc.bell-labs.com> <3806204F.CA060A2D@hursley.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian and all, Denial of the existing documented privacy problems with IPv6 is not going to buy you much and could bring on some discredit to the IETF and IPv6 in specific. The best thing to do is fix the problems in the spec. And having the IAB endorse anything along these lines is just window dressing. Brian E Carpenter wrote: > What we need is for someone to write a one or two page > text explaining in unemotional language why the security > and privacy issues are essentially bogus, and what the IETF > is doing for those who nevertheless remain concerned. > > A good text along these lines can be the basis for an appropriate > PR response, and I would suggest that the IAB endorse it. > > 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 > -------------------------------------------------------------------- Regards, -- Jeffrey A. Williams Spokesman INEGroup (Over 95k members strong!) CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 972-447-1894 Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 15 02:13:52 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9F9Avu05260 for ipng-dist; Fri, 15 Oct 1999 02:10:57 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9F9Alk05253 for ; Fri, 15 Oct 1999 02:10:48 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id CAA02414 for ; Fri, 15 Oct 1999 02:10:47 -0700 (PDT) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA29280 for ; Fri, 15 Oct 1999 02:10:38 -0700 (PDT) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id LAA18099; Fri, 15 Oct 1999 11:10:32 +0200 (MET DST) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id LAA10311; Fri, 15 Oct 1999 11:10:30 +0200 (MET DST) Message-Id: <199910150910.LAA10311@givry.inria.fr> From: Francis Dupont To: Richard Draves cc: "'IPng List'" Subject: Re: reconnecting an interface In-reply-to: Your message of Thu, 14 Oct 1999 23:40:33 PDT. <4D0A23B3F74DD111ACCD00805F31D81014515C20@RED-MSG-50> Date: Fri, 15 Oct 1999 11:10:30 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: My driver interface can tell me when an interface is disconnected/reconnected to its media. For example, I get an event when an ethernet cable is unplugged and then another event when it's plugged back in. => I have the same concern for mobility then my current point-of-view is: - not all interfaces tell us when they are disconnected/reconnected (ie. for some interfaces you never receive an event) - it is hard to recognize immediately a disconnect then reconnect to another media from a glitch (for instance an "auto-drop" of the cable connected to an AUI :-) - for wireless interfaces the problem is even harder... In fact the firmware of the interface has the same problem: it should renegociate speed and halt/full duplex when the interface is reconnected (of course it never does this). I believe the only correct way to play this kind of game is to shutdown the interface before disconnect it and to restart the interface after reconnect... This solves the whole problem too. I'm trying to take advantage of this in MSR IPv6. Of course I don't know if the interface reconnected to the same subnet that it left. If it did reconnect to the same subnet, then it seems reasonable for this to be minimally intrusive to applications. If it reconnected to a different subnet, then it seems reasonable to discard old information learned from auto-configuration and auto-configure anew. => it will be hard to convince people the second choice is the reasonnable one then we'll fall in the first one and we'll know the subnet is not the same at the first router advertisement, ie. too late for a DAD for instance... My preliminary thoughts are: 1. When disconnecting from the media: do nothing. Addresses on the interface survive and continue to age normally, routes on the interface survive, etc. => I agree, we can't be too aggressive here because we should not kill all the connections by a side effect. 2. When reconnecting to media: - set REACHABLE neighbor cache entries to the STALE state => why not INCOMPLETE? Until the DAD is finished we can't use our addresses. - set auto-configured unicast address lifetimes down to a small value (the length of time that we'll attempt to get an RA - max number of router solicits * solicit interval) => I do the same thing at the first router advertisement from an unknown router with new prefixes... - put all unicast addresses into the tentative state and restart duplicate address detection => this is correct but has a real impact. I believe a flag per interface is needed in order to do or not to do this. - set lifetimes of routes learned from autoconfig (default routers, on-link prefixes) down to the same small value - send out MLD reports, rejoining any multicast addresses assigned to the interface => it is possible to rely on periodic MLD queries too. - start sending router solicitations => this is the first thing to do, fortunately we don't need an address for sending a router solicitation! => what to do for a router ??? The idea being that if we did reconnect to the same subnet, then we'll get an RA that will reset all the lifetimes back to their usual values. However if we are connected to a new subnet, then the old addresses and routes will disappear and we'll have acquired new addresses and routes. However any manually configured addresses or routes will not disappear. => this is why start sending router solicitations is a key point. Does this sound reasonable? => yes if the DAD/intrusive part can be disabled. Am I missing anything? => the router case. And propose a 10kV new version of Ethernet to IEEE in order to discourage unplug/plug of Ethernets (:-)... Regards Francis.Dupont@inria.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Oct 15 02:26:41 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9F9NcD05298 for ipng-dist; Fri, 15 Oct 1999 02:23:38 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9F9NSk05291 for ; Fri, 15 Oct 1999 02:23:29 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id CAA03240; Fri, 15 Oct 1999 02:23:27 -0700 (PDT) Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA03154; Fri, 15 Oct 1999 02:23:22 -0700 (PDT) Received: from assan (assan.imag.fr [129.88.31.17]) by imag.imag.fr (8.9.3/8.8.5) with ESMTP id LAA17375; Fri, 15 Oct 1999 11:23:09 +0200 (MET DST) Message-Id: <4.2.0.58.19991015104905.00a73ab0@brahma.imag.fr> X-Sender: durand@brahma.imag.fr X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 15 Oct 1999 11:21:59 +0200 To: Richard Draves From: Alain Durand Subject: RE: (ngtrans) I-D ACTION:draft-ietf-ngtrans-6to4-03.txt Cc: "'IPng List'" , Erik Nordmark In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D81014515C06@RED-MSG-50> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 10:39 14/10/99 -0700, Richard Draves wrote: >Alain, our initial two proposals were fairly similar. However in the end I >think we need to separate the concepts of buckets and the concepts of >precedence and use both. > >First I have some confusion when I read your proposal. At some points you >use numerical inequalities eg prec(a) < prec(b). That's clear. At other >points you say "higher precedence". Does higher precedence mean lower >numerically or higher numerically? So maybe you'll have to correct my >interpretation of your proposed algorithm. I need to clarify this in my text. Guess I need to submit an ID. lowest precedence means in my text the lowest number. Guess I have to reformulate this, I may have use an incorrect english term. I fear you understand the opposite of what I meant. My fault. I will give two example of how it works. >I'd like to give the administrator the ability to configure a solution to >the other problem that you raised in Tokyo - situations where >longest-matching-prefix does not do the right thing because of mismatches >with the topology, like where one's ISP is has two separate prefixes. > >So suppose the administrator can say "give first preference to addresses in >my own site (prefix A/48), next to addresses from my ISP (prefixes A/16 and >B/16), next to all other global native addresses, next to 6to4, last to >v4-compatible". > >That sounds like a useful capability for the administrator. >Suppose the administrator tries to do this with your algorithm. > >Then a node with two source addresses, one from prefix A/48 and one 6to4, >initiates communication with another node with one destination address from >prefix B/16. > >I believe that your algorithm will select the 6to4 source address instead of >the A/48 source address - clearly the wrong thing. I do not see why. With my algorithm, node A will have both an global, non 6to4 address within A/48 and a 6to4 one. node B will have only global, non 6to4 addresses My suggested algorithm will consider the pairs: (A/48:prec=30, B/48:prec=30) (A/6to4:prec=35, B/48:prec=30). There is only one pair of common precedence, that is: (A/48:prec=30, B/48:prec=30) The lowest numerical value of precedence LP is 30. The algorithm will then select the non 6to4 addresses as source address for A. >Another situation - the source addresses are the same (prefixes A/48 and >6to4), but there are two destination addresses (prefixes B/16 and 6to4). In >this situation your algorithm will select the 6to4 source & destination >addresses instead of the two native addresses. Same thing, the algorithm will select global. we consider the pairs: (A/48:prec=30, B/48:prec=30) (A/48:prec=30, B/6to4:prec=35) (A/6to4:prec=35, B/48:prec=30) (A/6to4:prec=35, B/6to4:prec=35) the set of pairs of common precedence is (A/48:prec=30, B/48:prec=30) (A/6to4:prec=35, B/6to4:prec=35) LP (lowest numerical value of precedence) is 30, so we select the pair (A/48:prec=30, B/48:prec=30) If I redefine the definition of precedence, not for type of addresses, but with a longest prefix match with predefine prefixes as you suggested, what you define as buckets is maybe what I define as the set of pairs of the same precedence prec(FE80::/64) = 10 prec(FEC0::/64) = 20 prec(2000::/3) = 30 prec(2002::/16) = 35 prec(::/96) = 50 - Alain. - Alain. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Oct 15 03:26:16 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9FANZq05367 for ipng-dist; Fri, 15 Oct 1999 03:23:35 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9FANQk05360 for ; Fri, 15 Oct 1999 03:23:27 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id DAA06601 for ; Fri, 15 Oct 1999 03:23:25 -0700 (PDT) From: Volsinians@aol.com Received: from imo19.mx.aol.com (imo19.mx.aol.com [198.81.17.9]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA18866 for ; Fri, 15 Oct 1999 04:23:25 -0600 (MDT) Received: from Volsinians@aol.com by imo19.mx.aol.com (mail_out_v23.6.) id wVWa001795 (4332); Fri, 15 Oct 1999 06:22:28 -0400 (EDT) Message-ID: <0.30307d5b.25385a64@aol.com> Date: Fri, 15 Oct 1999 06:22:28 EDT Subject: Re: reconnecting an interface To: richdr@microsoft.com, ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Windows AOL sub 41 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In a message dated 10/15/99 2:45:43 AM Eastern Daylight Time, richdr@microsoft.com writes: > 1. When disconnecting from the media: do nothing. Addresses on the interface > survive and continue to age normally, routes on the interface survive, etc. Why not declare the interface down? Otherwise packets will be handed to the interface and held or dropped when there might be a route to the destination from another interface. > 2. When reconnecting to media: > - set REACHABLE neighbor cache entries to the STALE state > - set auto-configured unicast address lifetimes down to a small value (the > length of time that we'll attempt to get an RA - max number of router > solicits * solicit interval) > - put all unicast addresses into the tentative state and restart duplicate > address detection > - set lifetimes of routes learned from autoconfig (default routers, on-link > prefixes) down to the same small value > - send out MLD reports, rejoining any multicast addresses assigned to the > interface > - start sending router solicitations > The idea being that if we did reconnect to the same subnet, then we'll get > an RA that will reset all the lifetimes back to their usual values. However > if we are connected to a new subnet, then the old addresses and routes will > disappear and we'll have acquired new addresses and routes. However any > manually configured addresses or routes will not disappear. If the interface was declared down upon disconnection, reconnection differs in no way from initial connection. > Does this sound reasonable? Am I missing anything? Declaring disconnected interfaces simply to be down as if they had never been connected is probably a good deal more straightforward and less fraught with peril. Joachim Martillo -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 15 03:46:22 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9FAhTh05430 for ipng-dist; Fri, 15 Oct 1999 03:43:29 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9FAhHk05423 for ; Fri, 15 Oct 1999 03:43:19 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id DAA07273 for ; Fri, 15 Oct 1999 03:43:17 -0700 (PDT) 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 EAA21912 for ; Fri, 15 Oct 1999 04:43:15 -0600 (MDT) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id TAA02540; Fri, 15 Oct 1999 19:43:03 +0900 (JST) To: feico@pasta.cs.uit.no cc: "'IPng List'" In-reply-to: dillema's message of Fri, 15 Oct 1999 12:32:40 +0200. <19991015123240.L14468@acm.org> 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: reconnecting an interface From: itojun@iijlab.net Date: Fri, 15 Oct 1999 19:43:03 +0900 Message-ID: <2538.939984183@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Has this only recently been added to the Kame distribution? On >NetBSD-current-Sep-4/Kame and fairly recent FreeBSD-3.2/Kame, I noticed No, this has been in in the tree for more than a year. >that when an interface address is removed it doesn't seem to result >in removal of the associated `permanent' ND-cache entry and the >routing table entry for it. I ahven't looked into it much, I stumbled >accross it by accident last week and noticed I needed to manually >remove ND-cache and router entries. Did i miss something? I saw >this for both removal of addresses by expiration of autoconfig-ed >addresses (address became depricated) and manual removal with >`ifconfig ... delete'. Please give me more specific information. What kind of RA do you advertise from your router? Do you advertise infinite lifetime on RA? The code works like this. 1. I'm hooked to my home network, 3ffe:501:410::/48. sm1: flags=8863 mtu 1500 address: 00:00:86:05:80:fa media: Ethernet 10baseT inet 202.232.15.102 netmask 0xfffffff8 broadcast 202.232.15.103 inet6 fe80:1::200:86ff:fe05:80fa prefixlen 64 inet6 3ffe:501:410:1:200:86ff:fe05:80fa prefixlen 64 2. I move to my office, get an RA there. I get a new prefix. The address from my home will be marked as "detached" as the advertising router becomes unreachable. Detached address will not be used as source address. sm1: flags=8863 mtu 1500 address: 00:00:86:05:80:fa media: Ethernet 10baseT inet 202.232.15.102 netmask 0xfffffff8 broadcast 202.232.15.103 inet6 fe80:1::200:86ff:fe05:80fa prefixlen 64 inet6 3ffe:501:410:1:200:86ff:fe05:80fa prefixlen 64 detached inet6 3ffe:507:0:1:200:86ff:fe05:80fa prefixlen 64 3. If you look at prefix list with ndp -p, you will see "no advertising router" on the list. 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 Fri Oct 15 04:25:31 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9FBMgr05463 for ipng-dist; Fri, 15 Oct 1999 04:22:43 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9FBMXk05456 for ; Fri, 15 Oct 1999 04:22:34 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id EAA28223 for ; Fri, 15 Oct 1999 04:22:32 -0700 (PDT) Received: from krdl.org.sg (rodin.krdl.org.sg [192.122.139.27]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA29079 for ; Fri, 15 Oct 1999 05:22:31 -0600 (MDT) Received: from mailhost.krdl.org.sg (mailbox.krdl.org.sg [192.122.134.30]) by krdl.org.sg (8.9.3/8.9.3) with ESMTP id TAA07181 for ; Fri, 15 Oct 1999 19:30:02 +0800 (SGT) Received: from ronald ([192.168.136.20]) by mailhost.krdl.org.sg (8.9.3/8.9.3) with SMTP id TAA02339 for ; Fri, 15 Oct 1999 19:21:42 +0800 (SGT) Date: Fri, 15 Oct 1999 19:21:42 +0800 (SGT) Message-Id: <3.0.32.19991015193619.00a0bbe0@mailhost.krdl.org.sg> X-Sender: ckyip@mailhost.krdl.org.sg X-Mailer: Windows Eudora Pro Version 3.0 (32) To: "'IPng List'" From: Yip Chan Keong Subject: ipng software Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, I am looking for 2 pieces of software: 1. an ipv4 - ipv6 translator, preferably siit compliant. kame has indicated that work is undergoing for this pc of software. any idea what is the status? 2. an ipv6 whois and irrd server. has look thru' the various sources like kame, inria and merit but don't seem to find anything of this nature. does anyone has any idea where can i get hold of this? thanks much for your kind assistance. best regards, Yip Chan Keong SingAREN NOC Singapore -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Oct 15 05:05:29 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9FC2js05503 for ipng-dist; Fri, 15 Oct 1999 05:02:45 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9FC2Zk05496 for ; Fri, 15 Oct 1999 05:02:36 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id FAA14238 for ; Fri, 15 Oct 1999 05:02:35 -0700 (PDT) Received: from iol.unh.edu (mars.iol.unh.edu [132.177.121.222]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA17683 for ; Fri, 15 Oct 1999 05:01:47 -0700 (PDT) Received: from localhost (rglr@localhost) by iol.unh.edu (8.9.3/8.9.3) with ESMTP id IAA02158; Fri, 15 Oct 1999 08:02:50 -0400 (EDT) Date: Fri, 15 Oct 1999 08:02:49 -0400 From: Ray LaRocca To: ipng@sunroof.eng.sun.com cc: ipv6gtp@iol.unh.edu Subject: UNH IPv6 GTP Canceled Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The UNH - InterOperability Lab regrets to inform you that due to the limited number of registered attendees the upcoming IPv6 test period has been canceled. For those of you that have registered we thank you for your continued support and apologize for any inconvenience this may cause you. I will contact you all to schedule an individual testing slot. Regards, -Ray -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 15 06:48:53 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9FDkNb05716 for ipng-dist; Fri, 15 Oct 1999 06:46:23 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9FDkDk05709 for ; Fri, 15 Oct 1999 06:46:15 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id GAA13581 for ; Fri, 15 Oct 1999 06:46:05 -0700 (PDT) Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.198.195]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA23510 for ; Fri, 15 Oct 1999 06:46:04 -0700 (PDT) Received: from [171.68.181.241] (deering-dsl3.cisco.com [10.19.130.188]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id GAA14470; Fri, 15 Oct 1999 06:46:01 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D81014515C20@RED-MSG-50> References: <4D0A23B3F74DD111ACCD00805F31D81014515C20@RED-MSG-50> Date: Fri, 15 Oct 1999 06:46:02 -0700 To: Richard Draves From: Steve Deering Subject: Re: reconnecting an interface Cc: "'IPng List'" Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 11:40 PM -0700 10/14/99, Richard Draves wrote: >I'm trying to take advantage of this in MSR IPv6. Of course I don't know if >the interface reconnected to the same subnet that it left. If it did >reconnect to the same subnet, then it seems reasonable for this to be >minimally intrusive to applications. If it reconnected to a different >subnet, then it seems reasonable to discard old information learned from >auto-configuration and auto-configure anew. As I pointed out in my "Plug & Play Architecture" talk at the Tokyo meeting, there will also arise the issue of when to treat a "new" link (i.e., the appearance of a new set of routers/prefixes/etc. on an interface) as a new "home" (i.e., the case where you should forget about your previous addresses) and when to treat it as a link being temporarily visited (i.e., the case where you should invoke the IPv6 mobility mechanisms to register your new addresses with your home agent, etc.). If you haven't implemented mobile IP yet, then this issue won't arise, but you might want to keep that in mind as a possible future requirement. (I think the normal behavior when a new link appears ought to be to treat it as a transient location and invoke the mobile IPv6 mechanisms, unless the user provides an explicit indication that it should be treated as a new home, e.g., by executing some UI command, or pressing a recessed button on the side of the IPv6 cell phone, or whatever. However, this all gets a lot more complicated when you start thinking nodes with multiple physical interfaces -- I wonder if the Mobile IP WG has sorted out all the variations and permutations?) Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Oct 15 06:54:44 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9FDrb305750 for ipng-dist; Fri, 15 Oct 1999 06:53:37 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9FDrPk05743 for ; Fri, 15 Oct 1999 06:53:26 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id GAA19519 for ; Fri, 15 Oct 1999 06:53:26 -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 GAA26398 for ; Fri, 15 Oct 1999 06:53:25 -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 JAA11198; Fri, 15 Oct 1999 09:53:22 -0400 (EDT) Message-Id: <199910151353.JAA11198@ietf.org> To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: ipng@sunroof.eng.sun.com From: The IESG Subject: Protocol Action: Format for Literal IPv6 Addresses in URL's to Proposed Standard Date: Fri, 15 Oct 1999 09:53:22 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has approved the Internet-Draft 'Format for Literal IPv6 Addresses in URL's' as a Proposed Standard. This document is the product of the IPNG Working Group. The IESG contact persons are Erik Nordmark and Thomas Narten. Technical Summary This document defines the preferred format for literal IPv6 Addresses in URL's for implementation in World Wide Web browsers. This format has been implemented in the IPv6 versions of several widely deployed browsers including Microsoft Internet Explorer, Mozilla, and Lynx. It is also intended to be used in the IPv6 version of the service location protocol. This document incudes an update to the generic syntax for Uniform Resource Identifiers defined in RFC 2396. It defines a syntax for IPv6 addresses and allows the use of "[" within a URI explicitly or this reserved purpose. Working Group Summary There have been several attempts to get a format for embedding literal IPv6 addresses within URLs. All suffer from the problem that they use special characters that are objectionable to some group (i.e., they are also reserved characters in other contexts and must consequently be escaped in such environments). Thus, there appears to be no solution that appeals to everyone. The format specified in this document is deemed the least worst solution of those that have been proposed and there was strong (though rough) consensus to that effect. Protocol Quality This document has been reviewed for the IESG by Thomas Narten and Erik Nordmark. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 15 07:30:28 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9FERdg05867 for ipng-dist; Fri, 15 Oct 1999 07:27:39 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9FERUk05860 for ; Fri, 15 Oct 1999 07:27:31 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA23408 for ; Fri, 15 Oct 1999 07:27:31 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA09489 for ; Fri, 15 Oct 1999 07:27:31 -0700 (PDT) Received: from zed.isi.edu (zed-e.isi.edu [128.9.160.57]) by boreas.isi.edu (8.8.7/8.8.6) with ESMTP id HAA05787; Fri, 15 Oct 1999 07:27:30 -0700 (PDT) From: Bill Manning Received: (from bmanning@localhost) by zed.isi.edu (8.8.7/8.8.6) id HAA03930; Fri, 15 Oct 1999 07:27:29 -0700 (PDT) Message-Id: <199910151427.HAA03930@zed.isi.edu> Subject: Re: ipng software To: ckyip@krdl.org.sg (Yip Chan Keong) Date: Fri, 15 Oct 1999 07:27:29 -0700 (PDT) Cc: ipng@sunroof.eng.sun.com In-Reply-To: <3.0.32.19991015193619.00a0bbe0@mailhost.krdl.org.sg> from "Yip Chan Keong" at Oct 15, 99 07:21:42 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > 2. an ipv6 whois and irrd server. has look thru' the various sources like > kame, inria and merit but don't seem to find anything of this nature. does > anyone has any idea where can i get hold of this? > > thanks much for your kind assistance. > > best regards, > Yip Chan Keong > SingAREN NOC > Singapore We are working on an IPv6 rwhois server and I have heard some talk of plans to port the ra suite (db & tools) to IPv6. -- --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 Fri Oct 15 07:44:49 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9FEfe705909 for ipng-dist; Fri, 15 Oct 1999 07:41:40 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9FEfUk05902 for ; Fri, 15 Oct 1999 07:41:31 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA18613 for ; Fri, 15 Oct 1999 07:41:31 -0700 (PDT) Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.198.195]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA22549 for ; Fri, 15 Oct 1999 08:41:30 -0600 (MDT) Received: from [171.68.181.241] (deering-dsl3.cisco.com [10.19.130.188]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id HAA16906; Fri, 15 Oct 1999 07:40:41 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: In-Reply-To: <199910150804.KAA13928@givry.inria.fr> References: <199910150804.KAA13928@givry.inria.fr> Date: Fri, 15 Oct 1999 07:40:42 -0700 To: Francis Dupont From: Steve Deering Subject: Re: draft-ietf-ipngwg-addrconf-privacy-00.txt Cc: Thomas Narten , ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 10:04 AM +0200 10/15/99, Francis Dupont wrote: >=> this seems for me rather complex... A stupid random and dynamic >interface ID should be enough for untracebility and not worse than >current dynamic IPv4 addresses. If I'd like to have both a server >at a well known address and a personal box for XXX web browsing >(in order to get a nice picture for my screen background :-) then >I should use a second box... One IPv6 phone to place calls and one to receive calls? Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Oct 15 07:49:26 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9FEljm05935 for ipng-dist; Fri, 15 Oct 1999 07:47:45 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9FElYk05924; Fri, 15 Oct 1999 07:47:35 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA25497; Fri, 15 Oct 1999 07:47:35 -0700 (PDT) Received: from admin.cgocable.net (admin.cgocable.net [24.226.1.21]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA25064; Fri, 15 Oct 1999 08:47:34 -0600 (MDT) Received: from cgocable.net (cgowave-60-129.cgocable.net [24.226.60.129]) by admin.cgocable.net (8.9.3/8.9.3) with ESMTP id KAA09870; Fri, 15 Oct 1999 10:48:01 -0400 (EDT) Message-ID: <38073E84.2DBC2D90@cgocable.net> Date: Fri, 15 Oct 1999 10:47:32 -0400 From: ryane Reply-To: ryane@cgocable.net X-Mailer: Mozilla 4.51 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: ietf and ipv6.... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Just wondering here---but you while you guys are working on ipv6---this ietf is out proposing the PSN issue be integrated in packet sourcing. Why on earth are these guys making my computer vulnerable? Maybe pushin ipv6 to be incompatable, or at least preventing it from ietf's beliefs of what it should be, would be wise? a few problems here: 1)not everybody has a processor serial number 2)if an ip address isn't unique enough, then wait till this comes out. A serial number attached to every packet sent out would result in a greater security threat to all----If a serial number attached to a packet is recorded by somebody of malicious intentions EX: mr. internet stalker the serial number is much worse than a mac address----at least some mac addresses can be manually changed. At least ip addresses can be changed---either statically or forced through dhcp (make your address go to someone else) then renew you dynamic address lease. How many of you people out there are actually concerned that while these improvements to the internet might make things easier, they also might create a bigger gap in your computer's security? Do many of you know, how easy it is to hack a computer on a remote network, with just the knowledge of what services and os that computer has? I think ipv4 is already too revealing to remote users---but when ietf get's it's way---there'll be so many back doors to everybody's computers, that an era of infomation warfare will hit----all in the name of ease of use......let's see how easy it is when people start getting blackmailed, flourishing businesses go bankrupt faster than you can read this sentence, and internet stalkers and pedophiles having more than enough resources at their disposal to find and locate their next victim whom they met on chat a few minutes before. :P All in the name of advancement, when in fact this once slightly offensive free-speech medium will be more integrated into real life than anybody ever wanted-----and once you open up pandora's box you can never close it. Open the door once---and this internet of ours will be corrupted beyond what you engineers could have thought of, because while you (and I) are all busy thinking of ways to make things better and easier for the end user, there are people who are thinking of ways to do many other things to comprimise our efforts, to hurt people, to gain profit at others expenses, etc. Funny thing is----there may seem to be alot of us, but there are a hell of alot more people out there wanting to mis-use the internet. And the ironic part is, they are networked as well, if not better than we are networked together ourselves. So working out these tinsy little details, and setting standards is ok----but before those standards are set---I think we need a few more people thinking about the big-picture, because from what I've seen from the ietf is about enough to make me sick. This is even worse than that rather bold move of intel's with their psn. Well....big brother is watching----I hope you prefer stepping on eggshells than going out with the most bold statements possible. Ryan Elson -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 15 08:53:24 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9FFoVs06141 for ipng-dist; Fri, 15 Oct 1999 08:50:31 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9FFoJk06134 for ; Fri, 15 Oct 1999 08:50:20 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA22289 for ; Fri, 15 Oct 1999 08:50:19 -0700 (PDT) Received: from ogma (ogma.cisco.com [144.254.74.39]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA19656 for ; Fri, 15 Oct 1999 09:50:18 -0600 (MDT) Received: from london.cisco.com (london.cisco.com [144.254.32.9]) by ogma (Postfix) with ESMTP id 63FE713E for ; Fri, 15 Oct 1999 17:50:17 +0200 (MET DST) Received: from fred-pc (edi-comm-vl10-dhcp15.cisco.com [144.254.107.163]) by london.cisco.com (8.8.8+Sun/8.8.8) with SMTP id RAA13226 for ; Fri, 15 Oct 1999 17:50:16 +0200 (MET DST) Message-Id: <4.1.19991015164604.00bdcb70@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 15 Oct 1999 16:49:06 +0100 To: ipng@sunroof.eng.sun.com From: Fred Baker Subject: FYI... Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I have been sending the following email to any number of reporters and privacy advocates for the last couple of days. You may want to critique it. ------------------------------------------------------------------------- Here are some comments on the AP article, which you no doubt saw. >The IETF's top engineers acknowledge some implications for on-line privacy, >but ``I think the privacy concerns are overrated,'' said Fred Baker, the >task force's chairman. For the record, I told the AP reporter that you gained little more information from the MAC Address inside the IP6 address than you gain from having a predictable IP address, and that therefore "the [incremental] privacy concerns are overrated". From the IP Address, you learn that someone is using the numbered machine, probably the person who usually does or one of the people who usually does. For example, if you see a message from 171.69.128.117, you know that my PC is at my home, that it obtained one of a set of five addresses from a DHCP server at Cisco, and that one of a small set of people (myself or my family) are using it. From the MAC Address, you additionally learn either that the site uses locally administered addresses, or that the person bought a particular vendor's Ethernet card. At Purdue, on Tuesday, I was told of a case where a person who stole an Ethernet card from someone else's machine was tracked down because the DHCP "IP4 address license" had not yet expired and they were able to sniff for the assigned address. During the interview, the reporter kept asking "what if there was a global registry correlating people with addresses, wouldn't that be a problem?". I asked him what his system's MAC Address was, and who knew that... He didn't know and nobody else did; the global registry doesn't exist, and if it did it would be very difficult to maintain. That doesn't sound, to me, like a great increase in the privacy risk over what you learn from the IP Source Address itself. If putting the MAC Address into the IP6 address is a problem, someone should tell Novell and Xerox. The Xerox Internet Transport, which IPX copied in the design of Novell Netware, has used the MAC Address as the "host identifier" portion of the network layer address since the 1970s. DECNET IV also has always had an algorithmic relationship between the MAC Address and the network layer address, and IS-IS routable CLNS NSAPs contain the MAC Address as well - CLNS Level 1 Routing routes to the MAC Address, which it calls a Host Identifier. I haven't heard that this caused privacy issues to arise in any of those protocols, and see no reason to believe that it would do so in IP6. I agree that privacy is important; I question what is compromised by the proposal. Neither the IP Address nor the MAC address tell you who is using the machine, and both kinds of address permit you to trace the traffic originated by a machine. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 15 09:23:07 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9FGKCN06212 for ipng-dist; Fri, 15 Oct 1999 09:20:12 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9FGK1k06205 for ; Fri, 15 Oct 1999 09:20:03 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA00450 for ; Fri, 15 Oct 1999 09:20:02 -0700 (PDT) Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id KAA02250 for ; Fri, 15 Oct 1999 10:20:01 -0600 (MDT) Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Fri Oct 15 12:19:01 EDT 1999 Received: from dnrc.bell-labs.com (gja000.lra.lucent.com [135.255.17.134]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id MAA22603; Fri, 15 Oct 1999 12:18:57 -0400 (EDT) Message-ID: <3807540A.255673C9@dnrc.bell-labs.com> Date: Fri, 15 Oct 1999 09:19:22 -0700 From: Grenville Armitage Organization: Bell Laboratories, Lucent Technologies X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: More misinformation on IPv6 References: <38053B71.D7D763D2@dnrc.bell-labs.com> <3806204F.CA060A2D@hursley.ibm.com> <3806747E.D20D4F54@ix.netcom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jeff Williams wrote: [..] > Denial of the existing documented privacy problems with > IPv6 is not going to buy you much and could bring on > some discredit to the IETF and IPv6 in specific. Denial of the existing documented UFO sightings will also not stop people from theorizing about Area 51. Perhaps we need David Duchovny to come in and discover that Brian Carpenter really is the Smoking Man, and that the IESG have been in secret negotiations with off-world ISPs to control 'The Net', and ultimately inject us all with a viral serial number that robs us of our humanity. gja -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 15 09:33:42 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9FGUnn06249 for ipng-dist; Fri, 15 Oct 1999 09:30:49 -0700 (PDT) Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9FGUek06242 for ; Fri, 15 Oct 1999 09:30:41 -0700 (PDT) Received: from bcn.East.Sun.COM (bcn.East.Sun.COM [129.148.75.4]) by eastmail1.East.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA19418; Fri, 15 Oct 1999 12:30:37 -0400 (EDT) Received: from elm (elm [129.148.75.61]) by bcn.East.Sun.COM (8.9.1b+Sun/8.9.1) with SMTP id MAA00299; Fri, 15 Oct 1999 12:30:36 -0400 (EDT) Message-Id: <199910151630.MAA00299@bcn.East.Sun.COM> Date: Fri, 15 Oct 1999 12:30:35 -0400 (EDT) From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: Re: FYI... To: ipng@sunroof.eng.sun.com, fred@cisco.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: nD+9fLir/oOXqsNzDCX5Cw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.4 SunOS 5.7 sun4u sparc Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Fine note, Fred. The only two points I might add for clarification are: 1) stateless autoconfiguration with embedded MAC address is only one way of assigning addresses within IPv6, and you could have a DHCP server dynamically hand out temporary addresses if you wanted so that your address would change each time you came up, or periodically, or whatever policy people wanted. (Personally I don't see any real problem with embedded MAC addresses, but if people perceive there's a problem even if there isn't, it's probably easier to tell them they don't have to do it than to convince them it isn't a problem.) 2) the real way to maintain anonymity if you need it is with anonymizers (also called anonymous remailers) Radia -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 15 09:54:17 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9FGph406324 for ipng-dist; Fri, 15 Oct 1999 09:51:43 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9FGpXk06317 for ; Fri, 15 Oct 1999 09:51:34 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA13125 for ; Fri, 15 Oct 1999 09:51:33 -0700 (PDT) Received: from maile.surrey.ac.uk (maile.surrey.ac.uk [131.227.102.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id KAA16522 for ; Fri, 15 Oct 1999 10:51:30 -0600 (MDT) Received: from petra.ee.surrey.ac.uk by maile.surrey.ac.uk with SMTP (PP); Fri, 15 Oct 1999 17:50:38 +0100 Date: Fri, 15 Oct 1999 17:51:06 +0100 (BST) From: Lloyd Wood X-Sender: eep1lw@petra.ee.surrey.ac.uk Reply-To: Lloyd Wood To: Grenville Armitage cc: ipng@sunroof.eng.sun.com Subject: Re: More misinformation on IPv6 In-Reply-To: <3807540A.255673C9@dnrc.bell-labs.com> Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 15 Oct 1999, Grenville Armitage wrote: > Jeff Williams wrote: > [..] > > Denial of the existing documented privacy problems with > > IPv6 is not going to buy you much and could bring on > > some discredit to the IETF and IPv6 in specific. > > Denial of the existing documented UFO sightings will also > not stop people from theorizing about Area 51. > > Perhaps we need David Duchovny to come in and discover > that Brian Carpenter really is the Smoking Man, and that > the IESG have been in secret negotiations with off-world ISPs > to control 'The Net', and ultimately inject us all with a > viral serial number that robs us of our humanity. You know, I'm starting to understand why this list is archived on a machine called 'playground'. Can we, like, cut it out, please? Or take it to raven? L. PGP -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Oct 15 10:02:34 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9FGxsm06380 for ipng-dist; Fri, 15 Oct 1999 09:59:54 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9FGxik06373 for ; Fri, 15 Oct 1999 09:59:45 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA20162 for ; Fri, 15 Oct 1999 09:59:44 -0700 (PDT) Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.198.195]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA20183 for ; Fri, 15 Oct 1999 10:59:44 -0600 (MDT) Received: from [171.68.181.241] (deering-dsl3.cisco.com [10.19.130.188]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id JAA26679; Fri, 15 Oct 1999 09:59:07 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: In-Reply-To: References: Date: Fri, 15 Oct 1999 09:59:07 -0700 To: Peter Tattam From: Steve Deering Subject: Re: Comments on draft-ietf-ipngwg-addrconf-privacy-00.txt Cc: IPNG Mailing List Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 2:48 AM +1100 10/16/99, Peter Tattam wrote: > > Yep. The addresses will identify the customer subnet, but not a specific > > node within the subnet nor a specific user of a node. If the customer > > wants more privacy than that, they have the choice of using various kinds > > of anonymizer approaches, such as application relays. Maybe that would > > be a useful service for an ISP to provide for its customers. > >Are you suggesting a NAT might solve the problem? :) No. > > Can you be more specific about the difficulties you imagine? > >Well, I was thinking of the case where the ISP would filter out addresses >that didn't match the mac address that the IPv6 address was formed from. >This might be important if different customers were sharing a subnet. >Examples would be a shared cable modem segment where it would be important >to protect customer traffic by preventing spoofing of neighbor's nodes. Treating a cable segment as a subnet shared among multiple residential customers seems like a bad idea to me, for a number of reasons. I would expect each residential customer to have a router (perhaps disguised as a "set top box") between the cable and the home network(s), and the home nodes would be attached to the home networks. In that sensible arrangement, the cable segment is a multi-access link interconnecting a set of home routers with the head-end router, and each home is defended from unscrupulous neighbors by its home router. No need for anybody to filter anything based on MAC addresses. >Perhaps a clarification of what "customer" means may clear up the confusion. >Customer could be a complete subnet, but more typically in the domestic market >would be a single node. For ISP models that need to count bytes and packets >for customer billing, if an individual node can't be tracked, there is a >problem. The single-node customer is just an (uninteresting?) special case, which will become less dominant over time, as people move from having one PC at home to having a network (or internetwork) of PCs and other devices at home. Those ISPs that feel the need to bill by byte or packet can do so based on customer prefix -- whether one host sends two packets or two hosts send one packet each, it's the same cost to the ISP. >Having said that, one would hope that Ipv6 opens up a new sphere of internet by automatically providing all customers with at least a full /64 at their >disposal. Presumably this is one of the goals that auto address config >attempts to achieve. This is one of the goals of providing a bigger address space for IP. It has nothing particularly to do with auto address config. >In conclusion would it be fair to say that actual practice would imply a 1-1 >mapping between customer and prefix? Yes. (Well, actually, there might be a many-to-one mapping from prefixes to customer, in the case of customers connected to multiple ISPs.) >If so, the whole privacy argument is blown wide open again. A "customer" in this discussion is not an individual, but rather a collection of nodes operated and used by possibly many individuals, e.g., all the members of a family or all the employees of a company. So a customer prefix is not an identifier for a individual human being. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Oct 15 10:24:39 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9FHLWU06424 for ipng-dist; Fri, 15 Oct 1999 10:21:32 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9FHLMk06417 for ; Fri, 15 Oct 1999 10:21:23 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA22784 for ; Fri, 15 Oct 1999 10:21:22 -0700 (PDT) Received: from jazz-1.trumpet.com.au (jazz-1.trumpet.com.au [203.5.119.62]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA29913 for ; Fri, 15 Oct 1999 11:21:20 -0600 (MDT) Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id EAA29796; Sat, 16 Oct 1999 04:21:17 +1100 (EST) Date: Sat, 16 Oct 1999 04:21:17 +1100 (EST) From: Peter Tattam To: Steve Deering cc: IPNG Mailing List Subject: Re: Comments on draft-ietf-ipngwg-addrconf-privacy-00.txt 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 Fri, 15 Oct 1999, Steve Deering wrote: > At 2:48 AM +1100 10/16/99, Peter Tattam wrote: > > > Can you be more specific about the difficulties you imagine? > > > >Well, I was thinking of the case where the ISP would filter out addresses > >that didn't match the mac address that the IPv6 address was formed from. > >This might be important if different customers were sharing a subnet. > >Examples would be a shared cable modem segment where it would be important > >to protect customer traffic by preventing spoofing of neighbor's nodes. > > Treating a cable segment as a subnet shared among multiple residential > customers seems like a bad idea to me, for a number of reasons. It happens. I've heard stories of sites snooping neighbors traffic and even breaking into shared drives on windows based machines. Consider that the margins are low for installing this stuff. It might be plausible for a cable provider to service as many clients off the one wire as possible without much regard for security, and getting the cheapest deal on the client hardware required. > I would > expect each residential customer to have a router (perhaps disguised as > a "set top box") between the cable and the home network(s), and the home > nodes would be attached to the home networks. In that sensible > arrangement, the cable segment is a multi-access link interconnecting a > set of home routers with the head-end router, and each home is defended > from unscrupulous neighbors by its home router. No need for anybody > to filter anything based on MAC addresses. Perhaps some more enlightened members of the list would be able to shed light on what is current and best practice in the cable modem internet industry. Are these set top boxes really that smart? Peter -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 15 10:36:12 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9FHX6q06454 for ipng-dist; Fri, 15 Oct 1999 10:33:06 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9FHWuk06447 for ; Fri, 15 Oct 1999 10:32:57 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA25781 for ; Fri, 15 Oct 1999 10:32:56 -0700 (PDT) Received: from mailext02.compaq.com (mailext02.compaq.com [207.18.199.33]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA04900 for ; Fri, 15 Oct 1999 11:32:55 -0600 (MDT) Received: from mailint02.im.hou.compaq.com (mailint02.compaq.com [207.18.199.35]) by mailext02.compaq.com (Postfix) with ESMTP id 7BAA59A943; Fri, 15 Oct 1999 12:32:44 -0500 (CDT) Received: by mailint02.im.hou.compaq.com (Postfix, from userid 12345) id DCB1ABC4CC; Fri, 15 Oct 1999 12:32:24 -0500 (CDT) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint02.im.hou.compaq.com (Postfix) with ESMTP id 6A84BB2A45; Fri, 15 Oct 1999 12:32:24 -0500 (CDT) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id NAA0000002290; Fri, 15 Oct 1999 13:32:43 -0400 (EDT) From: Jim Bound Message-Id: <199910151732.NAA0000002290@quarry.zk3.dec.com> To: Radia Perlman - Boston Center for Networking Cc: ipng@sunroof.eng.sun.com, fred@cisco.com Subject: Re: FYI... In-reply-to: Your message of "Fri, 15 Oct 1999 12:30:35 EDT." <199910151630.MAA00299@bcn.East.Sun.COM> Date: Fri, 15 Oct 1999 13:32:43 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Radia, >1) stateless autoconfiguration with embedded MAC >address is only one way of assigning >addresses within IPv6, and you could have a DHCP server >dynamically hand out temporary addresses if you wanted so >that your address would change each time you came up, or >periodically, or whatever policy people wanted. (Personally >I don't see any real problem with embedded MAC addresses, >but if people perceive there's a problem even if there isn't, >it's probably easier to tell them they don't have to do it than >to convince them it isn't a problem.) Just a note. DHCPv6 (which is different than DHCPv4) uses the link-local address as part of the key for identifying clients. We will only overlay the non-link-local address for a client address. I am co-author of DHCPv6 with Charlie Perkins Nokia and Mike Carney Sun. This is work in progress. But our objective with DHCPv6 is to dovetail with stateless addrconf on an implementation. We use the fact that the client has established an EUI. Bottom line is we don't need BOOTP for DHCPv6. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Oct 15 10:47:27 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9FHiDH06515 for ipng-dist; Fri, 15 Oct 1999 10:44:13 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9FHi4k06508 for ; Fri, 15 Oct 1999 10:44:04 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA29194 for ; Fri, 15 Oct 1999 10:44:03 -0700 (PDT) Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.198.195]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA06860 for ; Fri, 15 Oct 1999 10:44:03 -0700 (PDT) Received: from [171.68.181.241] (deering-dsl3.cisco.com [10.19.130.188]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id KAA01658; Fri, 15 Oct 1999 10:43:27 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: In-Reply-To: References: Date: Fri, 15 Oct 1999 10:43:28 -0700 To: Peter Tattam From: Steve Deering Subject: Re: Comments on draft-ietf-ipngwg-addrconf-privacy-00.txt Cc: IPNG Mailing List Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 4:21 AM +1100 10/16/99, Peter Tattam wrote: > > Treating a cable segment as a subnet shared among multiple residential > > customers seems like a bad idea to me, for a number of reasons. > >It happens. I've heard stories of sites snooping neighbors traffic and even >breaking into shared drives on windows based machines. Like I said, it's a bad idea. >Consider that the margins are low for installing this stuff. It might >be plausible for a cable provider to service as many clients off the one >wire as possible without much regard for security, and getting the cheapest >deal on the client hardware required. That just means the customers will have to install their own security, e.g., by putting a router/firewall between the cable modem and their home network. Similar things are happening now, to deal with another bad idea that the ISPs are fond of, that is, only assigning one IPv4 address per household (or charging more money for more than one address); that's caused customers to deploy NAT boxes at home, and now we are starting to see similar consumer-targeted devices, such as Apple's combination wireless basestation/router/NAT thingy. In the future, I hope those devices can simply be IPv6 routers. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Oct 15 10:59:52 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9FHv7b06570 for ipng-dist; Fri, 15 Oct 1999 10:57:08 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9FHuok06554 for ; Fri, 15 Oct 1999 10:56:51 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA28940 for ; Fri, 15 Oct 1999 10:56:50 -0700 (PDT) Received: from ogma (ogma.cisco.com [144.254.74.39]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA12798 for ; Fri, 15 Oct 1999 10:56:49 -0700 (PDT) Received: from london.cisco.com (london.cisco.com [144.254.32.9]) by ogma (Postfix) with ESMTP id 8F67DCF; Fri, 15 Oct 1999 19:56:48 +0200 (MET DST) Received: from fred-pc (ams-vpdn-client-21.cisco.com [144.254.46.22]) by london.cisco.com (8.8.8+Sun/8.8.8) with SMTP id TAA09883; Fri, 15 Oct 1999 19:56:46 +0200 (MET DST) Message-Id: <4.1.19991015185228.01bee850@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 15 Oct 1999 18:56:35 +0100 To: Radia Perlman - Boston Center for Networking From: Fred Baker Subject: Re: FYI... Cc: ipng@sunroof.eng.sun.com In-Reply-To: <199910151630.MAA00299@bcn.East.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 12:30 PM 10/15/99 -0400, Radia Perlman - Boston Center for Networking wrote: >1) stateless autoconfiguration with embedded MAC >address is only one way of assigning >addresses within IPv6 >2) the real way to maintain anonymity if you need it is with >anonymizers (also called anonymous remailers) of course, no argument. One could also mention that in view of CALEA and similar other legislation, strong encryption is a good thing even with the anonymous remailer. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 15 10:59:55 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9FHuDO06551 for ipng-dist; Fri, 15 Oct 1999 10:56:13 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9FHu6k06544 for ; Fri, 15 Oct 1999 10:56:06 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.1b+Sun/8.9.1) id KAA18137 for ipng@sunroof.eng.sun.com; Fri, 15 Oct 1999 10:53:49 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9F55gk04842 for ; Thu, 14 Oct 1999 22:05:49 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id WAA07534 for ; Thu, 14 Oct 1999 22:05:19 -0700 (PDT) From: marka@isc.org Received: from bsdi.dv.isc.org (bsdi.dv.isc.org [130.155.191.233]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA19356 for ; Thu, 14 Oct 1999 22:05:16 -0700 (PDT) Received: from isc.org (marka@localhost.dv.isc.org [127.0.0.1]) by bsdi.dv.isc.org (8.8.5/8.8.5) with ESMTP id PAA00317; Fri, 15 Oct 1999 15:04:40 +1000 (EST) Message-Id: <199910150504.PAA00317@bsdi.dv.isc.org> To: Paul A Vixie cc: "Matt Crawford" , ipng@sunroof.eng.sun.com, namedroppers@internic.net Subject: Re: draft-ietf-ipngwg-dns-lookups-04.txt In-reply-to: Your message of "Thu, 14 Oct 1999 11:12:10 MST." <199910141812.LAA05216@bb.rc.vix.com> Date: Fri, 15 Oct 1999 15:04:19 +1000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Let me restate the situation. The user refers to short-form name H, > > and the resolver is configured to search domains D1, ..., Dn. > > > > As I see it, the FQDN the user is implicitly naming is the first one > > which *exists* from the sequence H.D1, ..., H.Dn. Then the resolver > > gives back whatever suitable records are listed for that FQDN, or > > some sort of error if there are none. > > we went through this in pure IPv4, too, due to early API ambiguity > between "name doesn't exist at all" and "name exists, but there are > no address records." in fact it was KRE who complained about it then, > as now. so assuming > > H.D1 IN MX 10 foo > and > H.D2 IN A 10.0.0.53 > > and a domain search list of D1,D2, it used to be that "ping h" would > return "no such host". now it pings 10.0.0.53. to me, this is the > same issue except that we're fine-pointing on the meaning of the > question "are there address records at this node?" Paul has heard my views on the behaviour in the past. i.e. I think that it is broken in the same way that RFC1535 show the old search list behaviour to be broken. I understand why the current behaviour is there, to cope with wildcard records with the old search list behaviour. To my view this is as dangerous as having the old search list behaviour. The current behaviour has it such that you can telnet to a box and then attempt to send mail to the same box and get two different fully qualified named. I for would be happy to see this behaviour change even though it may break some existing systems that are depending upon it. It is counter intuitive. It should even be possible to have to new lookup mechanisms get the new behaviour getipnodebyname() and the old gethostbyname() implement different search strategies. Mark -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.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 Fri Oct 15 11:00:11 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9FHv5p06569 for ipng-dist; Fri, 15 Oct 1999 10:57:05 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9FHuvk06562 for ; Fri, 15 Oct 1999 10:56:57 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.1b+Sun/8.9.1) id KAA18167 for ipng@sunroof.eng.sun.com; Fri, 15 Oct 1999 10:54:40 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9FAWxk05389 for ; Fri, 15 Oct 1999 03:33:00 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id DAA09982 for ; Fri, 15 Oct 1999 03:32:59 -0700 (PDT) Received: from dillema.pasta.cs.uit.no (server6.pasta.cs.UiT.No [129.242.16.231]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA20273 for ; Fri, 15 Oct 1999 04:32:52 -0600 (MDT) Received: (from dillema@localhost) by dillema.pasta.cs.uit.no (8.8.8/8.8.8) id MAA26550; Fri, 15 Oct 1999 12:32:40 +0200 (CEST) Date: Fri, 15 Oct 1999 12:32:40 +0200 From: Feico Dillema To: itojun@iijlab.net Cc: "'IPng List'" Subject: Re: reconnecting an interface Message-ID: <19991015123240.L14468@acm.org> Reply-To: feico@pasta.cs.uit.no Mail-Followup-To: itojun@iijlab.net, 'IPng List' References: <4D0A23B3F74DD111ACCD00805F31D81014515C20@RED-MSG-50> <202.939970371@coconut.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: <202.939970371@coconut.itojun.org>; from itojun@iijlab.net on Fri, Oct 15, 1999 at 03:52:51PM +0900 X-PGP-DSS-FINGERPRINT: FDA9 49C5 E7CE 7BC5 2E86 6EA4 EB62 D470 C2F8 5139 X-PGP-RSA-FINGERPRINT: 2D 67 34 85 F5 50 97 5B 94 DC 7D B5 9C 9F FD F3 X-Operating-System: NetBSD dillema.pasta.cs.uit.no 1.4K NetBSD 1.4K (DILLEMA.v6) X-DISCLAIMER: Blame society, not my employer or my parents. X-URL: http://www.pasta.cs.uit.no/ Organization: Very Little Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, Oct 15, 1999 at 03:52:51PM +0900, itojun@iijlab.net wrote: > > > >My driver interface can tell me when an interface is > >disconnected/reconnected to its media. For example, I get an event when an > >ethernet cable is unplugged and then another event when it's plugged back > >in. > > You may want to take a look at KAME nomadic node hack by Tatsuya > Jinmei, which is described in section 3.4 of the following paper: > http://www.isoc.org/inet99/proceedings/4s/4s_2.htm > The code is available in normal KAME distribution and works well. Has this only recently been added to the Kame distribution? On NetBSD-current-Sep-4/Kame and fairly recent FreeBSD-3.2/Kame, I noticed that when an interface address is removed it doesn't seem to result in removal of the associated `permanent' ND-cache entry and the routing table entry for it. I ahven't looked into it much, I stumbled accross it by accident last week and noticed I needed to manually remove ND-cache and router entries. Did i miss something? I saw this for both removal of addresses by expiration of autoconfig-ed addresses (address became depricated) and manual removal with `ifconfig ... delete'. I was wondering about the permanent entries in ND-cache like: 3ffe:2a00:100:3001:260:b0ff:f 0:60:b0:a4:da:73 le0 permanent R shouldn't permanent be changed into the lifetime of the interface address, like in: # ifconfig -L le0 le0: flags=8863 mtu 1500 ... inet6 3ffe:2a00:100:3001:260:b0ff:fea4:da73 prefixlen 64 pltime 3599988 vltime 3599988 Feico. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 15 11:00:12 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9FHvgt06579 for ipng-dist; Fri, 15 Oct 1999 10:57:42 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9FHvYk06572 for ; Fri, 15 Oct 1999 10:57:34 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.1b+Sun/8.9.1) id KAA18196 for ipng@sunroof.eng.sun.com; Fri, 15 Oct 1999 10:55:17 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9FCfYk05594 for ; Fri, 15 Oct 1999 05:41:34 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id FAA15998 for ; Fri, 15 Oct 1999 05:41:35 -0700 (PDT) Received: from dillema.pasta.cs.uit.no (server6.pasta.cs.UiT.No [129.242.16.231]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA00579 for ; Fri, 15 Oct 1999 05:41:33 -0700 (PDT) Received: (from dillema@localhost) by dillema.pasta.cs.uit.no (8.8.8/8.8.8) id OAA27080; Fri, 15 Oct 1999 14:41:28 +0200 (CEST) Date: Fri, 15 Oct 1999 14:41:27 +0200 From: Feico Dillema To: itojun@iijlab.net Cc: "'IPng List'" Subject: Re: reconnecting an interface Message-ID: <19991015144127.M14468@acm.org> Reply-To: feico@pasta.cs.uit.no Mail-Followup-To: itojun@iijlab.net, 'IPng List' References: <19991015123240.L14468@acm.org> <2538.939984183@coconut.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: <2538.939984183@coconut.itojun.org>; from itojun@iijlab.net on Fri, Oct 15, 1999 at 07:43:03PM +0900 X-PGP-DSS-FINGERPRINT: FDA9 49C5 E7CE 7BC5 2E86 6EA4 EB62 D470 C2F8 5139 X-PGP-RSA-FINGERPRINT: 2D 67 34 85 F5 50 97 5B 94 DC 7D B5 9C 9F FD F3 X-Operating-System: NetBSD dillema.pasta.cs.uit.no 1.4K NetBSD 1.4K (DILLEMA.v6) X-DISCLAIMER: Blame society, not my employer or my parents. X-URL: http://www.pasta.cs.uit.no/ Organization: Very Little Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, Oct 15, 1999 at 07:43:03PM +0900, itojun@iijlab.net wrote: > do you advertise from your router? Do you advertise infinite > lifetime on RA? No. > The code works like this. > > 1. I'm hooked to my home network, 3ffe:501:410::/48. > 2. I move to my office, get an RA there. I get a new prefix. > The address from my home will be marked as "detached" as the > advertising router becomes unreachable. Detached address > will not be used as source address. > 3. If you look at prefix list with ndp -p, you will see "no advertising > router" on the list. 1, 2 and 3 worked for me also as you described. Here's my current ndp -p on one of the hosts in question: dillema# ndp -p 3ffe:2a00:100:3002::/64 if=le0 flags=LA vltime=2592000, pltime=604800, expire=25d7h12m6s No advertising router 3ffe:2a00:100:3001::/64 if=le0 flags=LA vltime=3600000, pltime=3600000, expire=41d15h59m10s advertised by fe80::280:1cff:fe5d:301c The router on this link (NetBSD/kame) recently got an hardware upgrade, and after it was booted again it had its ethernet interfaces switched. It only advertises a prefix on one of its interfaces, so due to the switch it sent out a RA on the wrong link. The hosts on this link used this RA (prefix 3ffe:2a00:100:3002::/64) to autoconfig a second address for their interface (the first prefix 3ffe:2a00:100:3001::/64 is advertised by another router). I quickly switched the Ethernet interfaces on this router again, so that the RA were sent over the correct link once again. The `second addresses' soon were marked detached and almost everything worked just fine. Almost, because I noticed that hosts on the 3ffe:2a00:100:3001:: network (with a 3ffe:2a00:100:3002:: address marked as detached) couldn't communicate to hosts on the `real' 3ffe:2a00:100:3002:: network. A `ndp -a' on these hosts showed there was still a permanent entry for their detached 3ffe:2a00:100:3002:: address, and a tcpdump showed that these hosts still believed 3ffe:2a00:100:3002:: machines could be found on the local link by sending out neighbour solicitations for them. I fixed this manually using `ndp -d' and `route delete' on the entries for 3ffe:2a00:100:3002::. I assume these are removed automatically when the address/prefix actually expires, but not when its preferred lifetime has passed? I realize this is a weird situation (a router moved and was `mobile' for a while, instead of a host) and I'm not sure whether it can be dealt with automatically within the IPv6 specs. I'd just like to understand what and why this happened, and if it can be prevented. I can imagine that accidents or temporarily misconfiguration of routers like this might not be entirely rare, and if the consequence is that fixing such a mistake involves fixes at all autoconfig-ed hosts... Well, I guess you get the picture... Feico. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 15 11:01:30 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9FHwQ606591 for ipng-dist; Fri, 15 Oct 1999 10:58:26 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9FHwHk06584 for ; Fri, 15 Oct 1999 10:58:18 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.1b+Sun/8.9.1) id KAA18225 for ipng@sunroof.eng.sun.com; Fri, 15 Oct 1999 10:56:00 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9FENDk05848 for ; Fri, 15 Oct 1999 07:23:13 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA22980 for ; Fri, 15 Oct 1999 07:23:14 -0700 (PDT) Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.198.195]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA15859 for ; Fri, 15 Oct 1999 08:23:13 -0600 (MDT) Received: from [171.68.181.241] (deering-dsl3.cisco.com [10.19.130.188]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id HAA16083; Fri, 15 Oct 1999 07:22:36 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: In-Reply-To: References: Date: Fri, 15 Oct 1999 07:22:37 -0700 To: Peter Tattam From: Steve Deering Subject: Re: Comments on draft-ietf-ipngwg-addrconf-privacy-00.txt Cc: IPNG Mailing List Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 6:08 PM +1100 10/15/99, Peter Tattam wrote: >Given the current public concern over the privacy issue, I have decided that I >might improve our product by having an optional facility for the stack to >automatically change it's address using >draft-ietf-ipngwg-addrconf-privacy-00.txt. Peter, I think a better approach is to add the capability of *adding* additional, "transient" addresses, rather than completely replacing the stable address with a transient one. More and more devices will be required to act both as initiators of communication (for which a transient address if fine), and as targets of communication initiated by others (for which a stable address is needed). It seems feasible and reasonable to have different kinds of addresses (i.e., stable vs. transient) for those different purposes. >This raises a number of issues.. > >1. How frequent should an address change be. One could make the changes on a >regular basis, and still retain reasonable utilization of the stack. I would >suggest making it user configuarable, but there may be some practical >limitations. It could potentially be as rapid as an address change per TCP >connection. I think the ideal would be per-TCP connection (or per-"session" for those apps that have a notion of session that includes multiple TCP connections), but we will probab;y want to be less aggressive than that in order to avoid too much DAD overhead on the links. >- what load on the network would be required. Presumably only one or >two ND exchanges, as well as the duplicate detection phase. Maybe also some >dynamic DNS. Arggh! No way the DNS should be dynamically updated to track these transient addresses. Since I think they ought to be used only when acting as a "client" (initiator), they needn't have entries in the DNS. Maybe for those silly servers that refuse to serve any clients for whom a reverse mapping exists in the DNS, we need a DNS hack that will fabricate and return a dummy name to any reverse look-up of addresses within a given subrange of a customers address range (and will do the complementary thing for a forward look-up of such a dummy name). >- how long should we continue to respond to a deprecated address if there are >no active sockets bound to that address. If you buy my argument that the transient addresses are only for the purpose of initiating communication, then it should be fine to forget about a transient address as soon as all the local apps are finished with it. >Having raised both of these ISP issues, I could debunk them by the comment that >in practice, a user might be identifiable by the top 64 bits of the address >anyway. Or more generally, the customer is identified by whatever prefix was assigned to that customer -- the typical prefix lengths would be 48 and 64. > While this looks likely to be the case for PPP, I am not so sure for >other technologies like cable or xDSL. If it was indeed the case, the top 64 >bits of an IPv6 address would then degenerate into the situation we currently >have in IPv4 with privacy of addresses. Yep. The addresses will identify the customer subnet, but not a specific node within the subnet nor a specific user of a node. If the customer wants more privacy than that, they have the choice of using various kinds of anonymizer approaches, such as application relays. Maybe that would be a useful service for an ISP to provide for its customers. >The issue of auto addr conf for IPv6 may also cause difficulties for >technologies that rely on strong binding between mac addresses and IP >addresses. e.g. Cable & xDSL. Can you be more specific about the difficulties you imagine? >How does the ISP deal with this? Do they filter and account for IPv6 traffic >*only* matching the mac address of the customers equipment, or do they allow >willy nilly Ipv6 addresses using auto conf and track and account using the MAC >address on the wire which is only available at the connect point. It's none of the ISP's business to track customer machines at the granularity of individual nodes. It ought to be enough for you to do whatever tracking and accounting you need at the granularity of customer prefix. >There is a counter argument that would imply that customers would need to be >protected from each other anyway. Does this then imply that each customer >receives their own /64 presumably staticly configured at the ISP end possibily >defeating the whole purpose of address autoconfig. IPv6 autoconfig, currently, is for the purpose of assigning host addresses within a subnet, not for assigning subnet prefixes within a site or site prefixes within an NLA. Yes, each customer should be receiving a statically allocated /48 (or at the very least a /64); that static allocation does not defeat the purpose of host address autoconfig within those prefixes. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Oct 15 11:03:10 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9FHxns06609 for ipng-dist; Fri, 15 Oct 1999 10:59:49 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9FHxZk06602 for ; Fri, 15 Oct 1999 10:59:36 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.1b+Sun/8.9.1) id KAA18283 for ipng@sunroof.eng.sun.com; Fri, 15 Oct 1999 10:57:18 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9FFAuk06012; Fri, 15 Oct 1999 08:10:58 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA00480; Fri, 15 Oct 1999 08:10:57 -0700 (PDT) Received: from dillema.pasta.cs.uit.no (server6.pasta.cs.UiT.No [129.242.16.231]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA27863; Fri, 15 Oct 1999 08:10:56 -0700 (PDT) Received: (from dillema@localhost) by dillema.pasta.cs.uit.no (8.8.8/8.8.8) id RAA28422; Fri, 15 Oct 1999 17:10:48 +0200 (CEST) Date: Fri, 15 Oct 1999 17:10:48 +0200 From: Feico Dillema To: ryane Cc: ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: ietf and ipv6.... Message-ID: <19991015171048.D27673@acm.org> Reply-To: feico@pasta.cs.uit.no Mail-Followup-To: ryane , ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com References: <38073E84.2DBC2D90@cgocable.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: <38073E84.2DBC2D90@cgocable.net>; from ryane on Fri, Oct 15, 1999 at 10:47:32AM -0400 X-PGP-DSS-FINGERPRINT: FDA9 49C5 E7CE 7BC5 2E86 6EA4 EB62 D470 C2F8 5139 X-PGP-RSA-FINGERPRINT: 2D 67 34 85 F5 50 97 5B 94 DC 7D B5 9C 9F FD F3 X-Operating-System: NetBSD dillema.pasta.cs.uit.no 1.4K NetBSD 1.4K (DILLEMA.v6) X-DISCLAIMER: Blame society, not my employer or my parents. X-URL: http://www.pasta.cs.uit.no/ Organization: Very Little Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, Oct 15, 1999 at 10:47:32AM -0400, ryane wrote: > Just wondering here---but you while you guys are working on ipv6---this > ietf is out proposing the PSN issue be integrated in packet sourcing. Can we all take a deep breath and ignore this post? At least not send or CC your replies to the list? Sigh, maybe it's time for a ipng-advocacy mailing list? Feico. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 15 11:03:52 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9FI19l06653 for ipng-dist; Fri, 15 Oct 1999 11:01:09 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9FI0fk06632 for ; Fri, 15 Oct 1999 11:00:43 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.1b+Sun/8.9.1) id KAA18341 for ipng@sunroof.eng.sun.com; Fri, 15 Oct 1999 10:58:24 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9FFn1k06122 for ; Fri, 15 Oct 1999 08:49:03 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA03536 for ; Fri, 15 Oct 1999 08:49:02 -0700 (PDT) Received: from jazz-1.trumpet.com.au (jazz-1.trumpet.com.au [203.5.119.62]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA13846 for ; Fri, 15 Oct 1999 08:48:59 -0700 (PDT) Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id CAA21885; Sat, 16 Oct 1999 02:48:49 +1100 (EST) Date: Sat, 16 Oct 1999 02:48:49 +1100 (EST) From: Peter Tattam To: Steve Deering cc: IPNG Mailing List Subject: Re: Comments on draft-ietf-ipngwg-addrconf-privacy-00.txt 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 Fri, 15 Oct 1999, Steve Deering wrote: > At 6:08 PM +1100 10/15/99, Peter Tattam wrote: > >Given the current public concern over the privacy issue, I have decided that I > >might improve our product by having an optional facility for the stack to > >automatically change it's address using > >draft-ietf-ipngwg-addrconf-privacy-00.txt. > > Peter, > > I think a better approach is to add the capability of *adding* additional, > "transient" addresses, rather than completely replacing the stable address > with a transient one. More and more devices will be required to act both > as initiators of communication (for which a transient address if fine), > and as targets of communication initiated by others (for which a stable > address is needed). It seems feasible and reasonable to have different > kinds of addresses (i.e., stable vs. transient) for those different > purposes. In retrospect considering a future postings I made about having your cake and eating it, I would tend to agree with you. This would seem to be a useful extension for the purpose of privacy. > > >This raises a number of issues.. > > > >1. How frequent should an address change be. One could make the changes on a > >regular basis, and still retain reasonable utilization of the stack. I would > >suggest making it user configuarable, but there may be some practical > >limitations. It could potentially be as rapid as an address change per TCP > >connection. > > I think the ideal would be per-TCP connection (or per-"session" for those > apps that have a notion of session that includes multiple TCP connections), > but we will probab;y want to be less aggressive than that in order to > avoid too much DAD overhead on the links. One could optimize the process by doing the DAD in advance. i.e. keep so many addresses in advance by interleaving with normal traffic. > > >- what load on the network would be required. Presumably only one or > >two ND exchanges, as well as the duplicate detection phase. Maybe also some > >dynamic DNS. > > Arggh! No way the DNS should be dynamically updated to track these > transient addresses. Since I think they ought to be used only when > acting as a "client" (initiator), they needn't have entries in the DNS. > Maybe for those silly servers that refuse to serve any clients for whom > a reverse mapping exists in the DNS, we need a DNS hack that will > fabricate and return a dummy name to any reverse look-up of addresses > within a given subrange of a customers address range (and will do the > complementary thing for a forward look-up of such a dummy name). This is what I meant when I was referring to "synthesizing" DNS records at the meeting. There is a subtle difference between synthesized DNS and real DNS, although they look identical on the wire. The issue of matching DNS names will become important when IPv6 is widely deployed. It is common to be locked out of certain services if your address does not reverse. Examples are SMTP servers doing spam prevention and certain web sites. Also, often when no reverse address mapping is present, web servers have a tendency to stall while the DNS tries to resolve the address to a name. This could be a performance issue when addresses are changing rapidly, and could even cause a denial of service on a web server. > > >- how long should we continue to respond to a deprecated address if there are > >no active sockets bound to that address. > > If you buy my argument that the transient addresses are only for the > purpose of initiating communication, then it should be fine to forget > about a transient address as soon as all the local apps are finished > with it. My thoughts entirely. One might envisage a stack only containing those addresses for the duration of a TCP socket, and possible an unbounded number of pseudo addresses potentially running simultaneoulsy on the host. Heck we have 63 or so bits to play with :) Now here's a bizarre thought.... one could arrange for *only* that TCP session to respond to the transient address, it would be a pseudo extension of the srce and dest port of the TCP session. It could have the effect of fortifying the TCP session somewhat. Could this be a possible way of reducing certain types of DoS attacks like RST attacks? > > >Having raised both of these ISP issues, I could debunk them by the comment that > >in practice, a user might be identifiable by the top 64 bits of the address > >anyway. > > Or more generally, the customer is identified by whatever prefix was > assigned to that customer -- the typical prefix lengths would be 48 > and 64. > > > While this looks likely to be the case for PPP, I am not so sure for > >other technologies like cable or xDSL. If it was indeed the case, the top 64 > >bits of an IPv6 address would then degenerate into the situation we currently > >have in IPv4 with privacy of addresses. > > Yep. The addresses will identify the customer subnet, but not a specific > node within the subnet nor a specific user of a node. If the customer > wants more privacy than that, they have the choice of using various kinds > of anonymizer approaches, such as application relays. Maybe that would > be a useful service for an ISP to provide for its customers. Are you suggesting a NAT might solve the problem? :) > > >The issue of auto addr conf for IPv6 may also cause difficulties for > >technologies that rely on strong binding between mac addresses and IP > >addresses. e.g. Cable & xDSL. > > Can you be more specific about the difficulties you imagine? Well, I was thinking of the case where the ISP would filter out addresses that didn't match the mac address that the IPv6 address was formed from. This might be important if different customers were sharing a subnet. Examples would be a shared cable modem segment where it would be important to protect customer traffic by preventing spoofing of neighbor's nodes. > > >How does the ISP deal with this? Do they filter and account for IPv6 traffic > >*only* matching the mac address of the customers equipment, or do they allow > >willy nilly Ipv6 addresses using auto conf and track and account using the MAC > >address on the wire which is only available at the connect point. > > It's none of the ISP's business to track customer machines at the granularity > of individual nodes. It ought to be enough for you to do whatever tracking > and accounting you need at the granularity of customer prefix. I would beg to differ. While I don't have direct experience, Telstra Big Pond Cable here in Aus tracks individual user's bandwidth and charges accordingly. I believe they currently use DHCP to dish out Ipv4 addresses. If the user could not be tracked by Ipv6 address, this would break their charging model severely unless they allocated a /64 per customer for billing purposes. This could not work if several users are on the same logical subnet. Perhaps a clarification of what "customer" means may clear up the confusion. Customer could be a complete subnet, but more typically in the domestic market would be a single node. For ISP models that need to count bytes and packets for customer billing, if an individual node can't be tracked, there is a problem. Having said that, one would hope that Ipv6 opens up a new sphere of internet by automatically providing all customers with at least a full /64 at their disposal. Presumably this is one of the goals that auto address config attempts to achieve. > > >There is a counter argument that would imply that customers would need to be > >protected from each other anyway. Does this then imply that each customer > >receives their own /64 presumably staticly configured at the ISP end possibily > >defeating the whole purpose of address autoconfig. > > IPv6 autoconfig, currently, is for the purpose of assigning host addresses > within a subnet, not for assigning subnet prefixes within a site or > site prefixes within an NLA. Yes, each customer should be receiving a > statically allocated /48 (or at the very least a /64); that static > allocation does not defeat the purpose of host address autoconfig > within those prefixes. I wasn't even prepared to go there... but you have raised the issue of yet another layer of possible autoconfiguration :) In conclusion would it be fair to say that actual practice would imply a 1-1 mapping between customer and prefix? If so, the whole privacy argument is blown wide open again. > > Steve > > Peter -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 15 11:10:00 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9FI6Xi06767 for ipng-dist; Fri, 15 Oct 1999 11:06:33 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9FI6Nk06760 for ; Fri, 15 Oct 1999 11:06:23 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA04926 for ; Fri, 15 Oct 1999 11:06:23 -0700 (PDT) From: Volsinians@aol.com Received: from imo-d02.mx.aol.com (imo-d02.mx.aol.com [205.188.157.34]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA17480 for ; Fri, 15 Oct 1999 11:06:22 -0700 (PDT) Received: from Volsinians@aol.com by imo-d02.mx.aol.com (mail_out_v23.6.) id cTFM0dcsyz (3964); Fri, 15 Oct 1999 14:02:52 -0400 (EDT) Message-ID: <0.cf66a739.2538873a@aol.com> Date: Fri, 15 Oct 1999 09:33:46 EDT Subject: Re: FYI... To: fred@cisco.com, ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Windows AOL sub 41 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In a message dated 10/15/99 11:55:21 AM Eastern Daylight Time, fred@cisco.com writes: > If putting the MAC Address into the IP6 address is a problem, someone > should tell Novell and Xerox. The Xerox Internet Transport, which IPX > copied in the design of Novell Netware, has used the MAC Address as the > "host identifier" portion of the network layer address since the 1970s. > DECNET IV also has always had an algorithmic relationship between the MAC > Address and the network layer address, and IS-IS routable CLNS NSAPs > contain the MAC Address as well - CLNS Level 1 Routing routes to the MAC > Address, which it calls a Host Identifier. I haven't heard that this caused > privacy issues to arise in any of those protocols, and see no reason to > believe that it would do so in IP6. Is there a global IPX or XNS Internet? The observation is not necessarily pertinent. Joachim Martillo -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 15 12:53:16 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9FJnab07074 for ipng-dist; Fri, 15 Oct 1999 12:49:36 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9FJnPk07067 for ; Fri, 15 Oct 1999 12:49:25 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA26357 for ; Fri, 15 Oct 1999 12:49:25 -0700 (PDT) Received: from seattle.3com.com (seattle.3com.com [129.213.128.97]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA05185 for ; Fri, 15 Oct 1999 12:49:24 -0700 (PDT) Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by seattle.3com.com (8.8.8/8.8.8) with ESMTP id MAA28089; Fri, 15 Oct 1999 12:49:22 -0700 (PDT) Received: from chicago.nsd.3com.com (chicago.nsd.3com.com [129.213.157.11]) by new-york.3com.com (8.8.8/8.8.8) with ESMTP id MAA08725; Fri, 15 Oct 1999 12:49:22 -0700 (PDT) Received: from tellurium (lan-isdn-cmj3.nsd.3com.com [129.213.207.235]) by chicago.nsd.3com.com (8.8.8/8.8.8) with SMTP id MAA02863; Fri, 15 Oct 1999 12:49:21 -0700 (PDT) Message-Id: <3.0.2.32.19991015124524.008eb574@mailhost.ewd.3com.com> X-Sender: cmj@mailhost.ewd.3com.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.2 (32) Date: Fri, 15 Oct 1999 12:45:24 -0700 To: Fred Baker , ipng@sunroof.eng.sun.com From: Cyndi Jung Subject: Re: FYI... In-Reply-To: <4.1.19991015164604.00bdcb70@flipper.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Having an address that doesn't change so dynamically can be a good thing - much easier to associate it with a name. Also, the potential "killer app" of choice identified right now is IP Telephony, which really doesn't work too well if your addresses are changing frequently, and nobody believes that dynamic updates to DNS will make this a non-issue. I find missing in all these responses any mention of the role of DNS in the transition story of IPv6. DNS is central to the hope of IPv6 succeeding as the next generation Internet Protocol. The fact that DNS has had AAAA records in BIND for enough time to make it likely to have been installed in a non-trivial number of places in the Internet, and that it works seemlessly in the same distributed system with unmodified DNS servers that know nothing of AAAA record types is a very powerful fact. Bad press is an excellent opportunity to expound on the whole picture. The network address and autoconf is just a piece, and to confine your response to answering this one point is missing an opportunity. Cyndi -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 15 12:58:23 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9FJusg07103 for ipng-dist; Fri, 15 Oct 1999 12:56:54 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9FJugk07096 for ; Fri, 15 Oct 1999 12:56:43 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA23851 for ; Fri, 15 Oct 1999 12:56:41 -0700 (PDT) Received: from seattle.3com.com (seattle.3com.com [129.213.128.97]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA08487 for ; Fri, 15 Oct 1999 12:56:41 -0700 (PDT) Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by seattle.3com.com (8.8.8/8.8.8) with ESMTP id MAA00638; Fri, 15 Oct 1999 12:56:38 -0700 (PDT) Received: from chicago.nsd.3com.com (chicago.nsd.3com.com [129.213.157.11]) by new-york.3com.com (8.8.8/8.8.8) with ESMTP id MAA11370; Fri, 15 Oct 1999 12:56:38 -0700 (PDT) Received: from tellurium (lan-isdn-cmj3.nsd.3com.com [129.213.207.235]) by chicago.nsd.3com.com (8.8.8/8.8.8) with SMTP id MAA03051; Fri, 15 Oct 1999 12:56:37 -0700 (PDT) Message-Id: <3.0.2.32.19991015125240.008eb574@mailhost.ewd.3com.com> X-Sender: cmj@mailhost.ewd.3com.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.2 (32) Date: Fri, 15 Oct 1999 12:52:40 -0700 To: Volsinians@aol.com, fred@cisco.com, ipng@sunroof.eng.sun.com From: Cyndi Jung Subject: Re: FYI... In-Reply-To: <0.cf66a739.2538873a@aol.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >> If putting the MAC Address into the IP6 address is a problem, someone >> should tell Novell and Xerox. ... > >Is there a global IPX or XNS Internet? The observation is not necessarily >pertinent. > But not for lack of trying. Novell and AT&T put together an IP/IPX "Internet" service, though I think they only attracted a handful of customers - less than 10, I heard, before they pulled the plug. But again, an excellent example of a protocol architecture that had no comparable distributed name system to the DNS. Even with the Novell Directory Services, there was no way that a global IPX Internet could have been constructed. Cyndi -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 15 13:07:46 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9FK2ku07153 for ipng-dist; Fri, 15 Oct 1999 13:02:46 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9FK2Vk07146 for ; Fri, 15 Oct 1999 13:02:32 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA25033 for ; Fri, 15 Oct 1999 13:02:31 -0700 (PDT) Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA08167 for ; Fri, 15 Oct 1999 14:02:30 -0600 (MDT) Received: from postal.research.att.com (postal.research.att.com [135.207.23.30]) by mail-green.research.att.com (Postfix) with ESMTP id 68C861E01D for ; Fri, 15 Oct 1999 16:02:29 -0400 (EDT) Received: from SIGABA.research.att.com (sigaba.research.att.com [135.207.23.169]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id QAA18889 for ; Fri, 15 Oct 1999 16:02:20 -0400 (EDT) Received: by SIGABA.research.att.com (Postfix, from userid 54047) id 6DDF841F16; Fri, 15 Oct 1999 16:02:28 -0400 (EDT) Received: from roc (localhost [127.0.0.1]) by SIGABA.research.att.com (Postfix) with ESMTP id 5EE23400B4 for ; Fri, 15 Oct 1999 16:02:23 -0400 (EDT) X-Mailer: exmh version 2.0.2 2/24/98 From: "Steven M. Bellovin" To: IPNG Mailing List Subject: Re: Comments on draft-ietf-ipngwg-addrconf-privacy-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 15 Oct 1999 16:02:23 -0400 Message-Id: <19991015200228.6DDF841F16@SIGABA.research.att.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'm replying to a couple of posts from different individuals here. > >Customer could be a complete subnet, but more typically in the domestic mark > et > >would be a single node. For ISP models that need to count bytes and packets > >for customer billing, if an individual node can't be tracked, there is a > >problem. > > The single-node customer is just an (uninteresting?) special case, which > will become less dominant over time, as people move from having one PC at > home to having a network (or internetwork) of PCs and other devices at > home. Those ISPs that feel the need to bill by byte or packet can do so > based on customer prefix -- whether one host sends two packets or two hosts > send one packet each, it's the same cost to the ISP. Billing isn't the issue; authorization is. Anyone can (and has) hooked a box up to a cable segment. Verifying that that customer is authorized -- and that includes "has paid their most recent bill, and not offended the AUP by ping-flooding their neighbors" -- is essential before they're allowed to send or receive packets. > Perhaps some more enlightened members of the list would be able to shed light > on what is current and best practice in the cable modem internet industry. > Are these set top boxes really that smart? Today's boxes are more like bridges than routers -- but yes, they're pretty smart and getting smarter. The cable modems I'm familiar with don't act like Ethernet transceivers. A cable segment is logically composed of an upstream section and a downstream section. When you send a packet to your neighbor, it goes all the way upstream to the CMTS (cable modem termination system), before being retransmitted downstream. All sorts of filtering can and does take place at the CMTS. Traffic is often link-encrypted today, and will always be link-encrypted in the very near future. As far as cost is concerned -- yes, everyone wants everything to be cheap. But the most expensive thing is providing customer care, which is why NATs are being rejected by some ISPs (broken applications make customers call up and complain, and it takes a Tier II or Tier III support person to realize that it's a NAT-induced failure). Dealing with customer complaints about their machines being hacked -- even if the fault is really their drain-bamaged host software or their own (lack) of system administration skills -- is expensive, too. --Steve Bellovin -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 15 15:36:19 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9FMWqF07457 for ipng-dist; Fri, 15 Oct 1999 15:32:52 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9FMWgk07450 for ; Fri, 15 Oct 1999 15:32:42 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id PAA25894 for ; Fri, 15 Oct 1999 15:32:42 -0700 (PDT) Received: from dfw-ix8.ix.netcom.com (dfw-ix8.ix.netcom.com [206.214.98.8]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA05724 for ; Fri, 15 Oct 1999 16:32:41 -0600 (MDT) Received: (from smap@localhost) by dfw-ix8.ix.netcom.com (8.8.4/8.8.4) id RAA09843; Fri, 15 Oct 1999 17:32:27 -0500 (CDT) Received: from dal-tx46-23.ix.netcom.com(198.211.44.151) by dfw-ix8.ix.netcom.com via smap (V1.3) id rma009662; Fri Oct 15 17:31:48 1999 Message-ID: <380721CC.5D78E9B1@ix.netcom.com> Date: Fri, 15 Oct 1999 13:45:02 +0100 From: Jeff Williams Organization: INEG. Inc. (Spokesman INEGroup) X-Mailer: Mozilla 4.08 [en] (Win16; I) MIME-Version: 1.0 To: marka@isc.org CC: Paul A Vixie , Matt Crawford , ipng@sunroof.eng.sun.com, namedroppers@internic.net Subject: Re: draft-ietf-ipngwg-dns-lookups-04.txt References: <199910150504.PAA00317@bsdi.dv.isc.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk mark and all, Good points here mark, and I agree essentially with you contention. But why not provide for this as an option so that a transition can be made? Follow me? >;) We did this in our "Interface Facility". Thought it did required for us to make some changes to our "BindPlus", but they were minor. marka@isc.org wrote: > > > Let me restate the situation. The user refers to short-form name H, > > > and the resolver is configured to search domains D1, ..., Dn. > > > > > > As I see it, the FQDN the user is implicitly naming is the first one > > > which *exists* from the sequence H.D1, ..., H.Dn. Then the resolver > > > gives back whatever suitable records are listed for that FQDN, or > > > some sort of error if there are none. > > > > we went through this in pure IPv4, too, due to early API ambiguity > > between "name doesn't exist at all" and "name exists, but there are > > no address records." in fact it was KRE who complained about it then, > > as now. so assuming > > > > H.D1 IN MX 10 foo > > and > > H.D2 IN A 10.0.0.53 > > > > and a domain search list of D1,D2, it used to be that "ping h" would > > return "no such host". now it pings 10.0.0.53. to me, this is the > > same issue except that we're fine-pointing on the meaning of the > > question "are there address records at this node?" > > Paul has heard my views on the behaviour in the past. i.e. I think > that it is broken in the same way that RFC1535 show the old search > list behaviour to be broken. > > I understand why the current behaviour is there, to cope with > wildcard records with the old search list behaviour. > > To my view this is as dangerous as having the old search list > behaviour. > > The current behaviour has it such that you can telnet to a box > and then attempt to send mail to the same box and get two different > fully qualified named. > > I for would be happy to see this behaviour change even though it > may break some existing systems that are depending upon it. It is > counter intuitive. It should even be possible to have to new lookup > mechanisms get the new behaviour getipnodebyname() and the old > gethostbyname() implement different search strategies. > > Mark > -- > Mark Andrews, Internet Software Consortium > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.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 > -------------------------------------------------------------------- Regards, -- Jeffrey A. Williams Spokesman INEGroup (Over 95k members strong!) CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 972-447-1894 Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 15 15:36:22 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9FMY3T07479 for ipng-dist; Fri, 15 Oct 1999 15:34:03 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9FMXkk07471 for ; Fri, 15 Oct 1999 15:33:47 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id PAA00155 for ; Fri, 15 Oct 1999 15:33:47 -0700 (PDT) Received: from dfw-ix8.ix.netcom.com (dfw-ix8.ix.netcom.com [206.214.98.8]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA06049 for ; Fri, 15 Oct 1999 16:33:45 -0600 (MDT) Received: (from smap@localhost) by dfw-ix8.ix.netcom.com (8.8.4/8.8.4) id RAA10121; Fri, 15 Oct 1999 17:33:04 -0500 (CDT) Received: from dal-tx46-23.ix.netcom.com(198.211.44.151) by dfw-ix8.ix.netcom.com via smap (V1.3) id rma009884; Fri Oct 15 17:32:24 1999 Message-ID: <380730F9.C0FAA9D2@ix.netcom.com> Date: Fri, 15 Oct 1999 14:49:47 +0100 From: Jeff Williams Organization: INEG. Inc. (Spokesman INEGroup) X-Mailer: Mozilla 4.08 [en] (Win16; I) MIME-Version: 1.0 To: Grenville Armitage CC: ipng@sunroof.eng.sun.com Subject: Re: More misinformation on IPv6 References: <38053B71.D7D763D2@dnrc.bell-labs.com> <3806204F.CA060A2D@hursley.ibm.com> <3806747E.D20D4F54@ix.netcom.com> <3807540A.255673C9@dnrc.bell-labs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Grenville and all, I was going to ignore this response here, but thought it might worth a try anyway to at least, yet again straighten Grenville out just a bit. >;) UFO's and area 51 (Which I worked at once upon a time) has little to do with my comment or is even remotely related to privacy concerns and holes in IPv6 presently. The rest of your comment is so visceral that I think it is or should be plainly obvious to most anyway as to it's actual intent. Grenville Armitage wrote: > Jeff Williams wrote: > [..] > > Denial of the existing documented privacy problems with > > IPv6 is not going to buy you much and could bring on > > some discredit to the IETF and IPv6 in specific. > > Denial of the existing documented UFO sightings will also > not stop people from theorizing about Area 51. > > Perhaps we need David Duchovny to come in and discover > that Brian Carpenter really is the Smoking Man, and that > the IESG have been in secret negotiations with off-world ISPs > to control 'The Net', and ultimately inject us all with a > viral serial number that robs us of our humanity. > > gja > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- Regards, -- Jeffrey A. Williams Spokesman INEGroup (Over 95k members strong!) CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 972-447-1894 Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 15 15:36:31 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9FMY1807478 for ipng-dist; Fri, 15 Oct 1999 15:34:01 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9FMXhk07463 for ; Fri, 15 Oct 1999 15:33:44 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id PAA26026 for ; Fri, 15 Oct 1999 15:33:44 -0700 (PDT) Received: from dfw-ix8.ix.netcom.com (dfw-ix8.ix.netcom.com [206.214.98.8]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA14441 for ; Fri, 15 Oct 1999 15:33:43 -0700 (PDT) Received: (from smap@localhost) by dfw-ix8.ix.netcom.com (8.8.4/8.8.4) id RAA10004; Fri, 15 Oct 1999 17:32:47 -0500 (CDT) Received: from dal-tx46-23.ix.netcom.com(198.211.44.151) by dfw-ix8.ix.netcom.com via smap (V1.3) id rma009675; Fri Oct 15 17:31:55 1999 Message-ID: <380725B8.7F1B3A46@ix.netcom.com> Date: Fri, 15 Oct 1999 14:01:45 +0100 From: Jeff Williams Organization: INEG. Inc. (Spokesman INEGroup) X-Mailer: Mozilla 4.08 [en] (Win16; I) MIME-Version: 1.0 To: Peter Tattam CC: IPNG Mailing List , Vinton Cref , Scott Bradner Subject: Re: Comments on draft-ietf-ipngwg-addrconf-privacy-00.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Peter and all, Peter Tattam wrote: > Hi all. > > Just weighing in on this topic, I have the following to say, and apologies if > it overlaps or has been said before. > > I believe I raised the topic several months ago, but nobody seemed to take much > notice, but I'm glad that the issues have now been discussed in more detail. > Mind you there has been little outcome except > draft-ietf-ipngwg-addrconf-privacy-00.txt which I think answers the technical > issue elegantly. Agreed and true that these issues were raised some months ago as I believe I was the first on to raised them on this list anyway. But it seems still that they are not yet viewed by someone as being critical. I of course disagree with this for obvious business and technical reasons, not to mention possible legal concerns that are bound to crop up if not addressed before large scale deployment as it seems that MCI/SPRINT and Vinton Cerf seems to be advocating. It would also seem from Scott Bradner's post yesterday, that he prefers a PR campaign rather than a technical solution. Not a wise move in my humble opinion, FWIW. > > > Given the current public concern over the privacy issue, I have decided that I > might improve our product by having an optional facility for the stack to > automatically change it's address using > draft-ietf-ipngwg-addrconf-privacy-00.txt. Ok, this seems like a reasonable starting point approach at least. > > > This raises a number of issues.. > > 1. How frequent should an address change be. One could make the changes on a > regular basis, and still retain reasonable utilization of the stack. I would > suggest making it user configuarable, but there may be some practical > limitations. It could potentially be as rapid as an address change per TCP > connection. Ok I agree completely and this is what I suggested some months ago essentially. But it went ignored and a few opposed this just recently. Per TCP connection should be adequate, unless you are doing multiple TCP connections per connection. ANd yes this should be user configurable and also default in autoconfiguration. > > > The issues to consider would be > > - what should be the minimum time between address changes Per TCP connection or per change of connection within a session should be adequate. > > > - what load on the network would be required. Presumably only one or > two ND exchanges, as well as the duplicate detection phase. Maybe also some > dynamic DNS. The address change could be scheduled to happen in advance if > necessary. Exactly right. > > > - how should the old addresses in the sequence be deprecated, presumably active > sockets should continue to work, but new connections should only use the new > address. Ok this seems adequate in most instances. > > > - how long should we continue to respond to a deprecated address if there are > no active sockets bound to that address. 20 to 30msec. > > > In all these areas, I presume there would be similar semantics to multihoming. > > 2. With my ISP hat on, there might be significant security issues with > allowing this type of mechanism to be common place, and it also brings into the > spotlght address auto config even without the random address assignment. It is > important for ISPs to track which user is one which address for accounting > reasons and also for security reasons. I don't agree here. Accounting can be done on the user him/herself not on the IP assigned at connect time. > > > >From the accounting side, if an ISP can't tell which user is using which > address, some traffic might be untraceable. Systems for logging traffic might > result in incorrect records, and there might also be implications for protocols > like RADIUS. RADIUS can indeed handle this given some modification (Minimal) > > > >From the security side, an ISP must have the ability to locate and filter a > user based on IP address since a potentially hostile user may be mounting a > network attack, and often the only way of locating the user is by IP address. > Having a random component in the address could be problematic. > > Having raised both of these ISP issues, I could debunk them by the comment that > in practice, a user might be identifiable by the top 64 bits of the address > anyway. While this looks likely to be the case for PPP, I am not so sure for > other technologies like cable or xDSL. If it was indeed the case, the top 64 > bits of an IPv6 address would then degenerate into the situation we currently > have in IPv4 with privacy of addresses. > > The issue of auto addr conf for IPv6 may also cause difficulties for > technologies that rely on strong binding between mac addresses and IP > addresses. e.g. Cable & xDSL. > > How does the ISP deal with this? Do they filter and account for IPv6 traffic > *only* matching the mac address of the customers equipment, or do they allow > willy nilly Ipv6 addresses using auto conf and track and account using the MAC > address on the wire which is only available at the connect point. > > This hasn't been an issue in v4 because addresses are so scarce that the ISP > can dictate to the customer which Ipv4 address they must use. Not so in IPv6. > Typically tools for logging are based on IP addresses which is usefule because > the logs can be applied at all parts of the network. Having to do it by mac > address means that the logging would need to be done closer to the client which > might be impractical under some circumstances. > > There is a counter argument that would imply that customers would need to be > protected from each other anyway. Does this then imply that each customer > receives their own /64 presumably staticly configured at the ISP end possibily > defeating the whole purpose of address autoconfig. > > Regards > > Peter > -- > Peter R. Tattam peter@trumpet.com > Managing Director, Trumpet Software International Pty Ltd > Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- Regards, -- Jeffrey A. Williams Spokesman INEGroup (Over 95k members strong!) CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 972-447-1894 Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 15 15:37:00 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9FMYwi07488 for ipng-dist; Fri, 15 Oct 1999 15:34:58 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9FMYek07481 for ; Fri, 15 Oct 1999 15:34:40 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id PAA26952 for ; Fri, 15 Oct 1999 15:34:40 -0700 (PDT) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id PAA14828 for ; Fri, 15 Oct 1999 15:34:40 -0700 (PDT) Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 15 Oct 1999 15:00:12 -0700 (Pacific Daylight Time) Received: by INET-IMC-03 with Internet Mail Service (5.5.2650.21) id <454GZVB0>; Fri, 15 Oct 1999 15:00:11 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D81014515C2C@RED-MSG-50> From: Richard Draves To: "'itojun@iijlab.net'" Cc: "'IPng List'" Subject: RE: reconnecting an interface Date: Fri, 15 Oct 1999 14:59:12 -0700 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > You may want to take a look at KAME nomadic node hack by Tatsuya > Jinmei, which is described in section 3.4 of the > following paper: > http://www.isoc.org/inet99/proceedings/4s/4s_2.htm > The code is available in normal KAME distribution and > works well. I worry that there could be an accumulation of detached prefixes and addresses... It's not clear to me what happens to UDP/TCP sockets that are using an address that becomes detached? The paper says: "One simple solution to these problems is to force the node to discard the old prefix and the old address after moving. But this approach may cause an unexpected deletion of prefixes and addresses that should remain valid. For instance, suppose that there is a failure of the router on a network while a laptop computer is suspended. When the laptop's operation is resumed, it should discard the prefix and the address that were advertised before suspension, because there is a possibility that the laptop has moved from the network. The laptop, however, cannot get a prefix anymore because the router has already stopped; it therefore fails to communicate with any nodes, even with those within the network." So the problem is that the router's down, so communication fails. That sounds like expected behavior, why is it a problem to fix? 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 15 15:37:52 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9FMZof07497 for ipng-dist; Fri, 15 Oct 1999 15:35:50 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9FMZTk07490 for ; Fri, 15 Oct 1999 15:35:29 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id PAA26354 for ; Fri, 15 Oct 1999 15:35:30 -0700 (PDT) Received: from dfw-ix8.ix.netcom.com (dfw-ix8.ix.netcom.com [206.214.98.8]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA06626 for ; Fri, 15 Oct 1999 16:35:29 -0600 (MDT) Received: (from smap@localhost) by dfw-ix8.ix.netcom.com (8.8.4/8.8.4) id RAA10470; Fri, 15 Oct 1999 17:34:33 -0500 (CDT) Received: from dal-tx46-23.ix.netcom.com(198.211.44.151) by dfw-ix8.ix.netcom.com via smap (V1.3) id rma010073; Fri Oct 15 17:32:51 1999 Message-ID: <3807338A.A0D9F2F5@ix.netcom.com> Date: Fri, 15 Oct 1999 15:00:43 +0100 From: Jeff Williams Organization: INEG. Inc. (Spokesman INEGroup) X-Mailer: Mozilla 4.08 [en] (Win16; I) MIME-Version: 1.0 To: Peter Tattam CC: Steve Deering , IPNG Mailing List Subject: Re: Comments on draft-ietf-ipngwg-addrconf-privacy-00.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Peter Steve and all, Peter Tattam wrote: > On Fri, 15 Oct 1999, Steve Deering wrote: > > > At 2:48 AM +1100 10/16/99, Peter Tattam wrote: > > > > > Can you be more specific about the difficulties you imagine? > > > > > >Well, I was thinking of the case where the ISP would filter out addresses > > >that didn't match the mac address that the IPv6 address was formed from. > > >This might be important if different customers were sharing a subnet. > > >Examples would be a shared cable modem segment where it would be important > > >to protect customer traffic by preventing spoofing of neighbor's nodes. > > > > Treating a cable segment as a subnet shared among multiple residential > > customers seems like a bad idea to me, for a number of reasons. > > It happens. I've heard stories of sites snooping neighbors traffic and even > breaking into shared drives on windows based machines. Consider that the > margins are low for installing this stuff. It might be plausible for a cable > provider to service as many clients off the one wire as possible without much > regard for security, and getting the cheapest deal on the client hardware > required. It indeed has happened more times that the media has reported BTW. > > > > I would > > expect each residential customer to have a router (perhaps disguised as > > a "set top box") between the cable and the home network(s), and the home > > nodes would be attached to the home networks. In that sensible > > arrangement, the cable segment is a multi-access link interconnecting a > > set of home routers with the head-end router, and each home is defended > > from unscrupulous neighbors by its home router. No need for anybody > > to filter anything based on MAC addresses. > > Perhaps some more enlightened members of the list would be able to shed light > on what is current and best practice in the cable modem internet industry. Are > these set top boxes really that smart? Some are, yes. But most aren't but can be made to be. > > > Peter > > -- > Peter R. Tattam peter@trumpet.com > Managing Director, Trumpet Software International Pty Ltd > Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- Regards, -- Jeffrey A. Williams Spokesman INEGroup (Over 95k members strong!) CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 972-447-1894 Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 15 16:01:46 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9FMwPL07561 for ipng-dist; Fri, 15 Oct 1999 15:58:25 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9FMwFk07554 for ; Fri, 15 Oct 1999 15:58:16 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id PAA05161 for ; Fri, 15 Oct 1999 15:58:16 -0700 (PDT) Received: from epilogue.com (thunk-office.epilogue.com [128.224.1.199]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA13727 for ; Fri, 15 Oct 1999 16:58:15 -0600 (MDT) Received: from thunk.epilogue.com (localhost [[UNIX: localhost]]) by epilogue.com (8.8.8/8.8.8) with ESMTP id SAA02883; Fri, 15 Oct 1999 18:58:01 -0400 (EDT) Message-Id: <199910152258.SAA02883@epilogue.com> From: Bill Sommerfeld To: Richard Draves cc: "'itojun@iijlab.net'" , "'IPng List'" Subject: Re: reconnecting an interface In-Reply-To: Message from Richard Draves of "Fri, 15 Oct 1999 14:59:12 PDT." <4D0A23B3F74DD111ACCD00805F31D81014515C2C@RED-MSG-50> Date: Fri, 15 Oct 1999 18:58:01 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > It's not clear to me what happens to UDP/TCP sockets that are using an > address that becomes detached? Ideally nothing, because someone could have tripped over the LAN cable or the hub's power cable and it should all come back once I notice the failure and plug it back in. > So the problem is that the router's down, so communication fails. That > sounds like expected behavior, why is it a problem to fix? The laptop should still be able to talk to other nodes on the same subnet even if the router's down, but it may only know them by their global address rather than their link-local address.. - 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 Fri Oct 15 16:03:36 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9FN29007579 for ipng-dist; Fri, 15 Oct 1999 16:02:10 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9FN1vk07567 for ; Fri, 15 Oct 1999 16:01:59 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id QAA04949 for ; Fri, 15 Oct 1999 16:01:58 -0700 (PDT) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id QAA24969 for ; Fri, 15 Oct 1999 16:01:58 -0700 (PDT) Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 15 Oct 1999 15:19:18 -0700 (Pacific Daylight Time) Received: by INET-IMC-03 with Internet Mail Service (5.5.2650.21) id <454GZXFF>; Fri, 15 Oct 1999 15:19:18 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D81014515C2F@RED-MSG-50> From: Richard Draves To: "'Francis Dupont'" Cc: "'IPng List'" Subject: RE: reconnecting an interface Date: Fri, 15 Oct 1999 15:19:07 -0700 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > 2. When reconnecting to media: > - set REACHABLE neighbor cache entries to the STALE state > > => why not INCOMPLETE? Until the DAD is finished we can't use > our addresses. INCOMPLETE seems too strong, it means that you don't have a clue about the link-layer address. STALE means you know a link-layer address but it has not been validated recently. Seems more appropriate. > - set auto-configured unicast address lifetimes down to a > small value (the > length of time that we'll attempt to get an RA - max > number of router > solicits * solicit interval) > > => I do the same thing at the first router advertisement from > an unknown > router with new prefixes... In the course of normal operation??? So if I configure a new router to advertise a new prefix, then it disrupts the old prefix being advertised by the old router? Seems wrong. > - put all unicast addresses into the tentative state and > restart duplicate > address detection > > => this is correct but has a real impact. I believe a flag > per interface > is needed in order to do or not to do this. The impact (that the addresses are unusable until DAD finishes) concerned me also, until I realized that it's only a second (assuming default values for RetransTimer and DupAddrDetectTransmits). So the user plugs the cable back in to the same link, and a second later TCP & UDP sockets start working again. I don't think a user will notice that latency. > => what to do for a router ??? Send an RA immediately when reconnecting an advertising interface. 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 15 16:52:05 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9FNnBr07647 for ipng-dist; Fri, 15 Oct 1999 16:49:11 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9FNn2k07640 for ; Fri, 15 Oct 1999 16:49:03 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id QAA14772 for ; Fri, 15 Oct 1999 16:49:02 -0700 (PDT) Received: from chmls06.mediaone.net (chmls06.mediaone.net [24.128.1.71]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA26868 for ; Fri, 15 Oct 1999 17:49:02 -0600 (MDT) Received: from gateway (loshin.ne.mediaone.net [24.128.200.158]) by chmls06.mediaone.net (8.8.7/8.8.7) with SMTP id TAA12915 for ; Fri, 15 Oct 1999 19:49:01 -0400 (EDT) Message-Id: <4.1.19991015194009.0099f280@pop.ne.mediaone.net> X-Sender: loshin@pop.ne.mediaone.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 15 Oct 1999 19:45:56 -0400 To: ipng@sunroof.eng.sun.com From: Pete Loshin Subject: "new" article on IPv6 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Data Communications is finally the article I turned in on IPv6 about half a year ago; here's the URL: http://www.data.com/issue/991021/ipv6.html After a cursory look, it seems that some direct quotes may have gotten turned into paraphrases; the editors there may have done other things to it as well. I'd appreciate any comments about accuracy or topicality (though any complaints should be copied to whoever is now handling editorial content for that website at CMP/Miller Freeman). Thanks! -pl +-------------------------------------------------------------+ | Pete Loshin http://Internet-Standard.com | | | | _IPv6 Clearly Explained_ Morgan Kaufmann January 1999 | | _TCP/IP Clearly Explained_ 3rd ed Morgan Kaufmann June 1999 | | | +-------------------------------------------------------------+ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 15 16:59:48 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9FNwTP07684 for ipng-dist; Fri, 15 Oct 1999 16:58:29 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9FNwLk07677 for ; Fri, 15 Oct 1999 16:58:21 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id QAA16430 for ; Fri, 15 Oct 1999 16:58:21 -0700 (PDT) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id QAA14207 for ; Fri, 15 Oct 1999 16:58:21 -0700 (PDT) Received: from 157.54.9.101 by mail1.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 15 Oct 1999 14:27:55 -0700 (Pacific Daylight Time) Received: by INET-IMC-01 with Internet Mail Service (5.5.2650.21) id <498YCXG1>; Fri, 15 Oct 1999 14:27:54 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D81014515C2B@RED-MSG-50> From: Richard Draves To: "'Steve Deering'" Cc: "'IPng List'" Subject: RE: reconnecting an interface Date: Fri, 15 Oct 1999 14:27:49 -0700 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Yes, I am thinking ahead to the day when we will want mobile-node support in MSR IPv6. My thoughts so far: Suppose mobility has been enabled and there was a home agent on the old link. Then when reconnecting to a link, do accelerated lifetime expiration for the old addresses. If an RA arrives and extends the lifetimes, great, mobility is not needed. However if an accelerated lifetime expires (but not if an address lifetime expires normally), then the old address is a candidate for becoming a home address. At this point I'm not sure if the old address should just become a home address automatically, or if there should be a UI to let the user confirm they want this. Maybe there should be a different levels of mobility support - never act as a mobile node, query the user when visiting a new link, vs always act as a mobile node. It can get complicated - what if the mobile node starts at a link A with a home agent, moves to a link B with a home agent, then moves to a link C? Does the link B address become a home address, so now it has home addresses from link A and link B? When does a home address go away? Of course, people don't always leave their machine turned on (or hibernated or suspended) while wandering around, sometimes they actually shut them down. We will have to store addresses in stable storage when shutting down and then bring them back as home-address candidates when starting up. I would be very interested in hearing from users & implementors of existing mobile v6/v4 nodes. I suspect the current solutions involve lots of manual configuration. In any case, I think my plan for handling disconnection/reconnection can evolve to handle mobility. Rich > -----Original Message----- > From: Steve Deering [mailto:deering@cisco.com] > Sent: Friday, October 15, 1999 6:46 AM > To: Richard Draves > Cc: 'IPng List' > Subject: Re: reconnecting an interface > > > At 11:40 PM -0700 10/14/99, Richard Draves wrote: > >I'm trying to take advantage of this in MSR IPv6. Of course > I don't know if > >the interface reconnected to the same subnet that it left. If it did > >reconnect to the same subnet, then it seems reasonable for this to be > >minimally intrusive to applications. If it reconnected to a different > >subnet, then it seems reasonable to discard old information > learned from > >auto-configuration and auto-configure anew. > > As I pointed out in my "Plug & Play Architecture" talk at the Tokyo > meeting, there will also arise the issue of when to treat a > "new" link > (i.e., the appearance of a new set of routers/prefixes/etc. on an > interface) as a new "home" (i.e., the case where you should forget > about your previous addresses) and when to treat it as a link being > temporarily visited (i.e., the case where you should invoke the > IPv6 mobility mechanisms to register your new addresses with your > home agent, etc.). If you haven't implemented mobile IP yet, then > this issue won't arise, but you might want to keep that in mind as > a possible future requirement. > > (I think the normal behavior when a new link appears ought to be to > treat it as a transient location and invoke the mobile IPv6 > mechanisms, > unless the user provides an explicit indication that it should be > treated as a new home, e.g., by executing some UI command, or pressing > a recessed button on the side of the IPv6 cell phone, or whatever. > However, this all gets a lot more complicated when you start thinking > nodes with multiple physical interfaces -- I wonder if the Mobile IP > WG has sorted out all the variations and permutations?) > > Steve > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Oct 15 17:33:26 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9G0T8S07729 for ipng-dist; Fri, 15 Oct 1999 17:29:09 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9G0Sxk07722 for ; Fri, 15 Oct 1999 17:29:00 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id RAA15985 for ; Fri, 15 Oct 1999 17:28:59 -0700 (PDT) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id RAA24458 for ; Fri, 15 Oct 1999 17:28:59 -0700 (PDT) Received: from 157.54.9.108 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 15 Oct 1999 16:07:37 -0700 (Pacific Daylight Time) Received: by INET-IMC-05 with Internet Mail Service (5.5.2650.21) id <4625DHLD>; Fri, 15 Oct 1999 16:07:37 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D81014515C34@RED-MSG-50> From: Richard Draves To: "'Bill Sommerfeld'" Cc: "'itojun@iijlab.net'" , "'IPng List'" Subject: RE: reconnecting an interface Date: Fri, 15 Oct 1999 16:07:33 -0700 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > So the problem is that the router's down, so communication > fails. That > > sounds like expected behavior, why is it a problem to fix? > > The laptop should still be able to talk to other nodes on the same > subnet even if the router's down, but it may only know them by their > global address rather than their link-local address.. That should work fine without any special support for "detached" prefixes & addresses. When sending to a global address, if there aren't any default routers or on-link prefixes the default is to assume it is on-link. So the laptop will be able to communicate with its neighbors using their global or link-local addresses and its own link-local address. The only problem is the laptop's own auto-configured global address(es), in my scheme they will disappear when the cable is plugged back in if the router is not available to send an RA while in the KAME scheme they will persist and be usable *if* there are no other reachable routers. I still don't see this as a big problem. 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 15 17:39:03 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9G0btr07752 for ipng-dist; Fri, 15 Oct 1999 17:37:55 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9G0bik07745 for ; Fri, 15 Oct 1999 17:37:44 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id RAA17829 for ; Fri, 15 Oct 1999 17:37:44 -0700 (PDT) Received: from newdev.harvard.edu (newdev.harvard.edu [128.103.207.76]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA09224 for ; Fri, 15 Oct 1999 18:37:44 -0600 (MDT) Received: (from sob@localhost) by newdev.harvard.edu (8.9.3/8.9.3) id UAA07572 for ipng@sunroof.eng.sun.com; Fri, 15 Oct 1999 20:37:42 -0400 (EDT) Date: Fri, 15 Oct 1999 20:37:42 -0400 (EDT) From: Scott Bradner Message-Id: <199910160037.UAA07572@newdev.harvard.edu> To: ipng@sunroof.eng.sun.com Subject: Re: Re: Comments on draft-ietf-ipngwg-addrconf-privacy-00.txt Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jeff Williams sez: > Not a wise move in my humble opinion, FWIW. for list readers who do not know Jeff & the value of his opinions http://www.gtld-mou.org/gtld-discuss/mail-archive/08000.html http://www.gtld-mou.org/gtld-discuss/mail-archive/08015.html -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Oct 15 18:02:38 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9G0uqe07774 for ipng-dist; Fri, 15 Oct 1999 17:56:52 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9G0uik07767 for ; Fri, 15 Oct 1999 17:56:44 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id RAA19991 for ; Fri, 15 Oct 1999 17:56:44 -0700 (PDT) Received: from dfw-ix7.ix.netcom.com (dfw-ix7.ix.netcom.com [206.214.98.7]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA12988 for ; Fri, 15 Oct 1999 18:56:43 -0600 (MDT) Received: (from smap@localhost) by dfw-ix7.ix.netcom.com (8.8.4/8.8.4) id TAA23361; Fri, 15 Oct 1999 19:55:59 -0500 (CDT) Received: from dal-tx49-29.ix.netcom.com(198.211.45.157) by dfw-ix7.ix.netcom.com via smap (V1.3) id rma023289; Fri Oct 15 19:55:32 1999 Message-ID: <38075CA7.B83C10F@ix.netcom.com> Date: Fri, 15 Oct 1999 17:56:09 +0100 From: Jeff Williams Organization: INEG. Inc. (Spokesman INEGroup) X-Mailer: Mozilla 4.08 [en] (Win16; I) MIME-Version: 1.0 To: Scott Bradner CC: ipng@sunroof.eng.sun.com Subject: Re: Comments on draft-ietf-ipngwg-addrconf-privacy-00.txt References: <199910160037.UAA07572@newdev.harvard.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Scott and all, Well it the first of you links to the GTLD-MoU archives there were some claimes made that I said that I did not make related to Dave Farber for instance. However all of wht I actually did say is essentially correct. Scott Bradner wrote: > Jeff Williams sez: > > Not a wise move in my humble opinion, FWIW. > > for list readers who do not know Jeff & the value of his opinions > > http://www.gtld-mou.org/gtld-discuss/mail-archive/08000.html > http://www.gtld-mou.org/gtld-discuss/mail-archive/08015.html > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- Regards, -- Jeffrey A. Williams Spokesman INEGroup (Over 95k members strong!) CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 972-447-1894 Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 15 18:45:09 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9G1gSF07803 for ipng-dist; Fri, 15 Oct 1999 18:42:28 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9G1gIk07796 for ; Fri, 15 Oct 1999 18:42:20 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id SAA01057 for ; Fri, 15 Oct 1999 18:42:18 -0700 (PDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id SAA13580 for ; Fri, 15 Oct 1999 18:42:18 -0700 (PDT) Received: from 157.54.9.103 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 15 Oct 1999 15:42:33 -0700 (Pacific Daylight Time) Received: by INET-IMC-04 with Internet Mail Service (5.5.2650.21) id <48DD8PFD>; Fri, 15 Oct 1999 15:42:32 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D81014515C32@RED-MSG-50> From: Richard Draves To: "'Alain Durand'" Cc: "'IPng List'" Subject: RE: (ngtrans) I-D ACTION:draft-ietf-ngtrans-6to4-03.txt Date: Fri, 15 Oct 1999 15:42:27 -0700 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >So suppose the administrator can say "give first preference > to addresses in > >my own site (prefix A/48), next to addresses from my ISP > (prefixes A/16 and > >B/16), next to all other global native addresses, next to > 6to4, last to > >v4-compatible". > > > >That sounds like a useful capability for the administrator. > >Suppose the administrator tries to do this with your algorithm. > > > >Then a node with two source addresses, one from prefix A/48 > and one 6to4, > >initiates communication with another node with one > destination address from > >prefix B/16. > > > >I believe that your algorithm will select the 6to4 source > address instead of > >the A/48 source address - clearly the wrong thing. > > I do not see why. With my algorithm, node A will have both an > global, non 6to4 > address within A/48 and a 6to4 one. node B will have only > global, non 6to4 > addresses > > My suggested algorithm will consider the pairs: > (A/48:prec=30, B/48:prec=30) > (A/6to4:prec=35, B/48:prec=30). > There is only one pair of common precedence, that is: > (A/48:prec=30, B/48:prec=30) > The lowest numerical value of precedence LP is 30. > The algorithm will then select the non 6to4 addresses as > source address for A. Yes, if all global native addresses have the same precedence value of 30. My point is that we have a system that lets administrators give precedences to different sets of addresses (and it would be good thing to give administrators that level of control), then administrator might want for example to give A/48 precedence 25, give A/16 and B/16 precedence 28, and all other global native addresses precedence 30. > >Another situation - the source addresses are the same > (prefixes A/48 and > >6to4), but there are two destination addresses (prefixes > B/16 and 6to4). In > >this situation your algorithm will select the 6to4 source & > destination > >addresses instead of the two native addresses. > > Same thing, the algorithm will select global. Again, I'm trying to accomodate policies that will give A/48 and B/16 different precedences. In that case, your algorithm will select the two 6to4 addresses instead of the two native addresses. 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 15 18:53:16 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9G1pqI07821 for ipng-dist; Fri, 15 Oct 1999 18:51:52 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9G1pgk07814 for ; Fri, 15 Oct 1999 18:51:44 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id SAA25156 for ; Fri, 15 Oct 1999 18:51:42 -0700 (PDT) Received: from epilogue.com (thunk-office.epilogue.com [128.224.1.199]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA15827 for ; Fri, 15 Oct 1999 18:51:41 -0700 (PDT) Received: from thunk.epilogue.com (localhost [[UNIX: localhost]]) by epilogue.com (8.8.8/8.8.8) with ESMTP id VAA02985; Fri, 15 Oct 1999 21:51:30 -0400 (EDT) Message-Id: <199910160151.VAA02985@epilogue.com> From: Bill Sommerfeld To: Richard Draves cc: "'Bill Sommerfeld'" , "'itojun@iijlab.net'" , "'IPng List'" Subject: Re: reconnecting an interface In-Reply-To: Message from Richard Draves of "Fri, 15 Oct 1999 16:07:33 PDT." <4D0A23B3F74DD111ACCD00805F31D81014515C34@RED-MSG-50> Date: Fri, 15 Oct 1999 21:51:30 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The only problem is the laptop's own auto-configured global address(es), in > my scheme they will disappear when the cable is plugged back in if the > router is not available to send an RA while in the KAME scheme they will > persist and be usable *if* there are no other reachable routers. I think this is a crucial difference -- consider the case where the system which got unplugged was a *server*, not a client (think of the "someone tripped over the hub's power cord" case). If it got unplugged/replugged while the router was down, nobody on the LAN can use its services until the router comes back? Seems pretty fragile to me.. - 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 Sat Oct 16 03:37:26 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9GAZ0u08005 for ipng-dist; Sat, 16 Oct 1999 03:35:00 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9GAYnk07998 for ; Sat, 16 Oct 1999 03:34:50 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id DAA13435 for ; Sat, 16 Oct 1999 03:34:45 -0700 (PDT) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id DAA16289 for ; Sat, 16 Oct 1999 03:34:40 -0700 (PDT) Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id KA00211; Sat, 16 Oct 1999 20:34:02 +1000 (from kre@munnari.OZ.AU) From: Robert Elz To: marka@isc.org Cc: Paul A Vixie , "Matt Crawford" , ipng@sunroof.eng.sun.com, namedroppers@internic.net Subject: Re: draft-ietf-ipngwg-dns-lookups-04.txt In-Reply-To: Your message of "Fri, 15 Oct 1999 15:04:19 +1000." <199910150504.PAA00317@bsdi.dv.isc.org> Date: Sat, 16 Oct 1999 20:34:01 +1000 Message-Id: <27969.940070041@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 15 Oct 1999 15:04:19 +1000 From: marka@isc.org Message-ID: <199910150504.PAA00317@bsdi.dv.isc.org> | I understand why the current behaviour is there, to cope with | wildcard records with the old search list behaviour. While the old search list behaviour probably made it more necessary, the two aren't really directly related. In fact, as personal domains become more prevalent, where users want mail to anyuser@anything.my.domain delivered to them, and hence wildcard MX's perhaps become prevalent again - and also want their search list to start with my.domain (because it is their local domain) but to probably also include their ISP's domain (so they can easily refer to pop servers, news servers, http caches, etc) they aren't really going to want the wildcard MX to completely defeat their search list. Wildcards are useful - they're also a pain sometimes (or perhaps frequently). | The current behaviour has it such that you can telnet to a box | and then attempt to send mail to the same box and get two different | fully qualified named. Yes. Good. A per protocol search list would suit me just fine (even better than just per type). The set of hosts that I want to telnet to are typically a completely disjoint set from the ones that I want to send e-mail to, which are again disjoint from the ones I want to http or ftp to, and those aren't the same as the set I want to send rwhois or DNS or TFTP packets at. For mail, I actually don't like the search list at all, and certainly not when it is implemented in the MTA (as distinct from the user agent). MTA's have no good way to get the user's desired search list (the mail may have been relayed several times already - by mailers which aren't completing the domain name, even though they should) - I disable all implicit domain searching in my sendmail. So whatever rules the resolver applies to other lookups, mail (sendmail anyway) is never going to be the same. Most UA's I have seen just do the same gethostbyname() as everyone else does. On the other hand, the "desire" as Matt first stated it, as it applies to "address" type records seems fairly reasonable to me, I doubt it would be terribly useful to have "any IPv4 host on the search path is found ahead of any IPv6 host" (or vice versa) as the mechanism, if some rational and implementable way to avoid that can be found. 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 Sat Oct 16 05:32:41 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9GCUGK08123 for ipng-dist; Sat, 16 Oct 1999 05:30:16 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9GCU6k08116 for ; Sat, 16 Oct 1999 05:30:07 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id FAA15800 for ; Sat, 16 Oct 1999 05:30:07 -0700 (PDT) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA29734 for ; Sat, 16 Oct 1999 06:30:06 -0600 (MDT) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id OAA18258; Sat, 16 Oct 1999 14:29:52 +0200 (MET DST) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id OAA10447; Sat, 16 Oct 1999 14:29:51 +0200 (MET DST) Message-Id: <199910161229.OAA10447@givry.inria.fr> From: Francis Dupont To: Richard Draves cc: "'IPng List'" Subject: Re: reconnecting an interface In-reply-to: Your message of Fri, 15 Oct 1999 15:19:07 PDT. <4D0A23B3F74DD111ACCD00805F31D81014515C2F@RED-MSG-50> Date: Sat, 16 Oct 1999 14:29:50 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: => to do the best choices something like a layer 2 link identifier is needed (because it is the right way to know if the link is the same or another one). Of course there is no such thing for Ethernet but IEEE 802.11 has an IBSS name. > 2. When reconnecting to media: > - set REACHABLE neighbor cache entries to the STALE state > > => why not INCOMPLETE? Until the DAD is finished we can't use > our addresses. STALE means you know a link-layer address... => but you don't know if you are on the same link... INCOMPLETE is just more aggressive than STALE, if you are on the same link you'll get extra traffic (no upper-layer reachability confirmation for instance), if you aren't on the same link STALE will lost some seconds in the DELAY state. > - set auto-configured unicast address lifetimes down to a > small value (the > length of time that we'll attempt to get an RA - max > number of router > solicits * solicit interval) > > => I do the same thing at the first router advertisement from > an unknown router with new prefixes... In the course of normal operation??? => only when mobility support and unplug/plug game on the interface are enabled. So if I configure a new router to advertise a new prefix, then it disrupts the old prefix being advertised by the old router? => if a junk new router is badly configurated in order to announce junk new prefixes then I'll give short lifetimes to old prefixes, etc. (see after for the meaning of short here) Seems wrong. => and of course I send some router solicitations then if the old router with the old prefixes is still there I'll receive soon (ie. before expiration) a good router advertisement with the old prefixes (ie. a confirmation). When this kind of movement detection is used for a mobile node the RS/RA procedure gives to you the good timing, below you can detect spurious movements, over it takes too much time to detect a real one. > - put all unicast addresses into the tentative state and > restart duplicate > address detection > > => this is correct but has a real impact. I believe a flag > per interface > is needed in order to do or not to do this. The impact (that the addresses are unusable until DAD finishes) concerned me also, until I realized that it's only a second (assuming default values for RetransTimer and DupAddrDetectTransmits). => it is a bit more because you should wait a bit before launching the DAD because if there is a real problem on a shared device you must avoid synchronization (for instance some hubs drop the carrier when the uplink is down, a unplug/plug on the uplink of such a hub will give simultaneous unplug/plug indications for a possibly large number of nodes). (the recommended value is between 0 and MAX_RTR_SOLICITATION_DELAY=1) So the user plugs the cable back in to the same link, and a second later TCP & UDP sockets start working again. I don't think a user will notice that latency. => it depends... You should give the choice to the user. (imagine the host is a dual-interface Web proxy, you should not put all the addresses of the interface to the Internet in the tentavive state even for one second) > => what to do for a router ??? Send an RA immediately when reconnecting an advertising interface. => this is the right thing if you are on the same link and the wrong thing if you are on another link... Again! Regards Francis.Dupont@inria.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Oct 16 07:49:18 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9GEkuA08207 for ipng-dist; Sat, 16 Oct 1999 07:46:56 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9GEkhk08200 for ; Sat, 16 Oct 1999 07:46:45 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA22252 for ; Sat, 16 Oct 1999 07:46:44 -0700 (PDT) Received: from ogma (ogma.cisco.com [144.254.74.39]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA11358 for ; Sat, 16 Oct 1999 07:46:43 -0700 (PDT) Received: from london.cisco.com (london.cisco.com [144.254.32.9]) by ogma (Postfix) with ESMTP id CAF5F9D; Sat, 16 Oct 1999 16:46:38 +0200 (MET DST) Received: from fred-pc (ams-vpdn-client-21.cisco.com [144.254.46.22]) by london.cisco.com (8.8.8+Sun/8.8.8) with SMTP id QAA18414; Sat, 16 Oct 1999 16:46:32 +0200 (MET DST) Message-Id: <4.1.19991016152409.009f5460@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Sat, 16 Oct 1999 15:25:12 +0100 To: Volsinians@aol.com From: Fred Baker Subject: Re: FYI... Cc: ipng@sunroof.eng.sun.com In-Reply-To: <0.cf66a739.2538873a@aol.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 09:33 AM 10/15/99 -0400, Volsinians@aol.com wrote: >Is there a global IPX or XNS Internet? The observation is not necessarily >pertinent. there is indeed a global CLNS internet routed via IS-IS - that's how they connect to telco switches for management purposes, I'm told. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Oct 16 12:46:52 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9GJi5408292 for ipng-dist; Sat, 16 Oct 1999 12:44:05 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9GJhrk08285 for ; Sat, 16 Oct 1999 12:43:54 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA05040 for ; Sat, 16 Oct 1999 12:43:52 -0700 (PDT) Received: from seattle.3com.com (seattle.3com.com [129.213.128.97]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA19796 for ; Sat, 16 Oct 1999 12:43:52 -0700 (PDT) Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by seattle.3com.com (8.8.8/8.8.8) with ESMTP id MAA09902; Sat, 16 Oct 1999 12:43:44 -0700 (PDT) Received: from chicago.nsd.3com.com (chicago.nsd.3com.com [129.213.157.11]) by new-york.3com.com (8.8.8/8.8.8) with ESMTP id MAA06042; Sat, 16 Oct 1999 12:43:44 -0700 (PDT) Received: from tellurium (lan-isdn-cmj3.nsd.3com.com [129.213.207.235]) by chicago.nsd.3com.com (8.8.8/8.8.8) with SMTP id MAA21489; Sat, 16 Oct 1999 12:43:43 -0700 (PDT) Message-Id: <3.0.2.32.19991016123947.00923f44@mailhost.ewd.3com.com> X-Sender: cmj@mailhost.ewd.3com.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.2 (32) Date: Sat, 16 Oct 1999 12:39:47 -0700 To: Fred Baker , Volsinians@aol.com From: Cyndi Jung Subject: Re: FYI... Cc: ipng@sunroof.eng.sun.com In-Reply-To: <4.1.19991016152409.009f5460@flipper.cisco.com> References: <0.cf66a739.2538873a@aol.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I think you could call that really an intranet - unless it ran a BGP-type protocol between multiple administrative domains that in fact compete for the user market, it is really just a large intranet. Cyndi At 03:25 PM 10/16/99 +0100, Fred Baker wrote: >At 09:33 AM 10/15/99 -0400, Volsinians@aol.com wrote: >>Is there a global IPX or XNS Internet? The observation is not necessarily >>pertinent. > >there is indeed a global CLNS internet routed via IS-IS - that's how they >connect to telco switches for management purposes, I'm told. >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home 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 Sat Oct 16 16:20:09 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9GNGxt08376 for ipng-dist; Sat, 16 Oct 1999 16:16:59 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9GNGmk08369 for ; Sat, 16 Oct 1999 16:16:50 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id QAA20555 for ; Sat, 16 Oct 1999 16:16:04 -0700 (PDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id RAA27110 for ; Sat, 16 Oct 1999 17:16:02 -0600 (MDT) Received: from 157.54.9.103 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Sat, 16 Oct 1999 16:15:30 -0700 (Pacific Daylight Time) Received: by INET-IMC-04 with Internet Mail Service (5.5.2650.21) id <48DD0GN9>; Sat, 16 Oct 1999 16:15:30 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D81014515C36@RED-MSG-50> From: Richard Draves To: "'Francis Dupont'" Cc: "'IPng List'" Subject: RE: reconnecting an interface Date: Sat, 16 Oct 1999 16:15:29 -0700 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > 2. When reconnecting to media: > > - set REACHABLE neighbor cache entries to the STALE state > > > > => why not INCOMPLETE? Until the DAD is finished we can't use > > our addresses. > > STALE means you know a link-layer address... > > => but you don't know if you are on the same link... > INCOMPLETE is just > more aggressive than STALE, if you are on the same link > you'll get extra > traffic (no upper-layer reachability confirmation for instance), > if you aren't on the same link STALE will lost some seconds in > the DELAY state. Hmm, let me think this through... For a global-scope destination address in the neighbor cache: If you reconnected to a different link, then hopefully the routing for that destination will not think the address is on-link! (Ie the on-link prefix list will change.) If routing does still treat the destination as on-link, then it probably either is present and has the same link-layer address as before, or it is not present at all. So maybe it's OK to leave the ND state of global-scope neighbors unchanged. The main argument that I can think of for being more cautious is that while disconnected you might have missed an unsolicited NA. Changing global-scope REACHABLE neighbors to STALE seems like a conservative thing to do. For a link-local destination address: I agree more caution is warranted, because a neighbor on the new link might be using the same link-local address as a neighbor on the old link, but have a different link-layer address. So either delete the neighbor cache entry entirely, or reset to INCOMPLETE and clear the IsRouter bit, to be safe. For a site-local destination address: You don't know that you are reconnecting to the same link, or a link in the same site, so the analysis for link-local applies. For an anycast destination address: An anycast address looks like it's global scope, but it might resolve to a different link-layer address on a new link. In that situation, setting the neighbor cache entry to STALE would introduce the latency of going through the DELAY state before connectivity to the anycast destination address would be restored. So the bottom line... I agree, deleting all the neighbor cache entries (or setting to INCOMPLETE and clearing IsRouter) seems like the best thing. The penalty (vs the alternative of using STALE for global-scope neighbors) is extra network traffic when reconnecting to the same link. But it will avoid the latency of the DELAY state in some cases and the extra traffic should be relatively infrequent. > > - put all unicast addresses into the tentative state and > > restart duplicate > > address detection > > > > => this is correct but has a real impact. I believe a flag > > per interface > > is needed in order to do or not to do this. > > The impact (that the addresses are unusable until DAD > finishes) concerned me > also, until I realized that it's only a second (assuming > default values for > RetransTimer and DupAddrDetectTransmits). > > => it is a bit more because you should wait a bit before launching > the DAD because if there is a real problem on a shared device you must > avoid synchronization (for instance some hubs drop the carrier when > the uplink is down, a unplug/plug on the uplink of such a hub > will give > simultaneous unplug/plug indications for a possibly large > number of nodes). > (the recommended value is between 0 and MAX_RTR_SOLICITATION_DELAY=1) Good point, so if the user plugs a cable back in the latency until the interface addresses become usable again would be between one and two seconds. > So the user plugs the cable back > in to the same link, and a second later TCP & UDP sockets > start working > again. I don't think a user will notice that latency. > > => it depends... You should give the choice to the user. Not another knob... this is not nearly important enough. > (imagine the host is a dual-interface Web proxy, you should not put > all the addresses of the interface to the Internet in the > tentavive state > even for one second) Why not? If I trip over the cable and get it plugged back in ten seconds later, do I really care that there is a twelve-second outage instead of a ten-second outage? > > => what to do for a router ??? > > Send an RA immediately when reconnecting an advertising interface. > > => this is the right thing if you are on the same link and > the wrong thing > if you are on another link... Again! I disagree, if the admin plugs the router interface into a new link, I would assume that she knows she's doing. Perhaps while the interface was unplugged, the admin reconfigured the router so the RA will carry different information. In any case, best to send an RA quickly so the router becomes visible on the link, whether it's the same link or a new link. Thanks, Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Oct 16 17:01:47 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9GNwjo08425 for ipng-dist; Sat, 16 Oct 1999 16:58:45 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9GNwZk08418 for ; Sat, 16 Oct 1999 16:58:36 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id QAA21783 for ; Sat, 16 Oct 1999 16:58:35 -0700 (PDT) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id RAA01260 for ; Sat, 16 Oct 1999 17:58:34 -0600 (MDT) Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Sat, 16 Oct 1999 16:53:42 -0700 (Pacific Daylight Time) Received: by INET-IMC-03 with Internet Mail Service (5.5.2650.21) id <454G6SX6>; Sat, 16 Oct 1999 16:53:42 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D81014515C37@RED-MSG-50> From: Richard Draves To: "'Bill Sommerfeld'" Cc: "'itojun@iijlab.net'" , "'IPng List'" Subject: RE: reconnecting an interface Date: Sat, 16 Oct 1999 16:53:40 -0700 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I think this is a crucial difference -- consider the case where the > system which got unplugged was a *server*, not a client (think of the > "someone tripped over the hub's power cord" case). If it got > unplugged/replugged while the router was down, nobody on the LAN can > use its services until the router comes back? Seems pretty fragile to > me.. I still think it's silly to expect the network (and in particular autoconfigured global addresses) to work normally while the only router is down. A server's manually configured global addresses would not be affected by the mechanisms under discussion. However... I have a modification that would do you want in this case and also help with something that's been bothering me. So now my plan for handling reconnect of a host interface is: - delete all neighbor cache entries - start sending router solicitations - send out MLD reports, rejoining any multicast addresses assigned to the interface - put all unicast addresses into the tentative state and restart duplicate address detection - when the first RA is received, before processing it, set lifetimes of everything learned previously from autoconfig (addresses, default routers, on-link prefixes) down to a small value, accelerating the expiration of potentially stale information - if an address becomes invalid from accelerated lifetime expiration, then it's a candidate for becoming a home address So if you reconnect to the same link and the only router is temporily down, then your autoconfigured addresses will remain valid, at least until their lifetimes expire normally. The other reason I like this is that I think the time constants can be such that stale information will disappear sooner. Before I proposed using an accelerated lifetime of MAX_RTR_SOLICITATIONS * RTR_SOLICITATION_INTERVAL, plus I should have accounted for MAX_RTR_SOLICITATION_DELAY - so up to 13 seconds with default values. When connecting to a new link, until the stale information is gone the interface will not be very functional - best to get rid of the stale information quickly. Once an RA has arrived, the only issue is waiting for additional RAs that might carry additional prefixes. I think it would be OK to use a smaller default - say twice MAX_RA_DELAY_TIME, or one second. 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 Sun Oct 17 08:56:39 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9HFs2208732 for ipng-dist; Sun, 17 Oct 1999 08:54:02 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9HFrrk08725 for ; Sun, 17 Oct 1999 08:53:54 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA16960 for ; Sun, 17 Oct 1999 08:53:53 -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 IAA04734 for ; Sun, 17 Oct 1999 08:53:52 -0700 (PDT) Received: from new (Ihinden-3.iprg.nokia.com [205.226.22.76]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with ESMTP id IAA22552; Sun, 17 Oct 1999 08:53:50 -0700 (PDT) Message-Id: <4.2.0.58.19991017084430.03ae07f0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Sun, 17 Oct 1999 08:53:18 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: Response to IPv6 Address Privacy Issue Cc: hinden@iprg.nokia.com, deering@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Recent press reports concerning the use of "unique serial numbers" in IPv6 addresses, and the privacy consequences thereof, have been inaccurate and misleading. Yes, one of the several methods of assigning IPv6 addresses uses factory-assigned, unique serial numbers as part of the address, but NO, not all IPv6 packets are required to carry such addresses. In particular, communication initiated by an IPv6 device, such as requesting a web page or accessing an email server, is NOT required to include or reveal any unique serial numbers of the initiating device. As an alternative to the kind of address that contains a serial number, the initiating device may use any of the kinds of addresses currently used in IPv4, e.g., manually assigned, or dynamically assigned -- perhaps only temporarily -- by an address server such as DHCP or by a dial-up ISP. It may also use a new kind of address, available only in IPv6, that contains a random number in place of the factory-assigned serial number. The kind of IPv6 address that contains a random number was introduced into the IPv6 development process earlier this year, precisely because of concerns in the Internet Engineering Task Force (IETF) about the same privacy issues that have more recently been raised in the press. The full details of how and when this new kind of address will be used have not been standardized as yet (perhaps this is why the writers of some of the recent press articles were apparently unaware of it), but we expect that to happen soon, and to be widely implemented by vendors of IPv6-capable devices well before widespread deployment of IPv6. For more information about this new kind of address, see: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-addrconf-privacy-00.txt Additional Technical Discussion It is important to understand that in most Internet communication, there is an "initiator" (the device that starts the communication session) and a "target" (the device to which the communication is directed). For example, when fetching a web page, the computer on which the browser is running is the initiator, and the server on which the web page resides is the target. This is similar to the distinction between the "calling party" and the "called party" in a telephone call. An Internet device that is intended to be a target of communication initiated by other devices must have a unique IP address that is stable over a relatively long period of time, just like anyone wishing to receive telephone calls must have a unique and stable telephone number, and anyone wishing to receive postal mail delivery must have a unique and stable postal address. The presence of unique, factory-assigned serial numbers on common LAN adapters, such as Ethernet adaptors, makes it possible to reliably generate unique, stable IPv6 addresses for such devices, without requiring either manual configuration or separate address-assignment servers. An Internet device that is NOT intended to be a target of communication, i.e., a device that is only an initiator of communication, may also have a unique, stable IP address, but is not required to do so. It is sufficient for such a device to have a temporary address that is valid only for as long as a specific communication session, and that address may be shared among a number of different, initiator-only devices at different times. In today's Internet, many devices are initiators only. The most common example of this is the dial-up home PC. (Dial-up devices are not very useful as targets, since they are disconnected from the Internet most of the time.) However, we expect that situation to become less common in the future, as dial-up Internet access is replaced by "always on" access technologies like cable and DSL, enabling consumers to run their own Internet-visible servers, and as new applications like IP telephony are deployed, in which many more devices become potential targets for communication. Therefore, in the future IPv6-based Internet, we expect many devices to have two kinds of IP addresses: (1) unique, stable addresses, assigned in any of several possible ways (e.g., by manual configuration, by an address server like DHCP, or by auto-configuration using embedded, factory-assigned LAN addresses), for the purpose of being a target, and for use when initiating communication to other, trusted targets, such as targets within the same home or enterprise. (2) temporary, transient addresses, such as those containing a random number in place of a factory-assigned serial number, for use when initiating communication to less trusted targets, such as public web servers. The choice of which kind of address to use when initiating communication is somewhat analogous to the choice that must be made when placing a telephone call in the presence of the "Caller ID" feature, i.e., whether or not to reveal the calling party's number to the called party. IPv6 addresses offer both choices. Steve Deering & Bob Hinden Co-Chairs of the IETF's IP Next Generation Working Group October 17, 1999 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 17 17:15:25 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9I0D0c09038 for ipng-dist; Sun, 17 Oct 1999 17:13:00 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9I0Cok09031 for ; Sun, 17 Oct 1999 17:12:52 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id RAA20998 for ; Sun, 17 Oct 1999 17:12:51 -0700 (PDT) Received: from ygmail.kt.co.kr (ygmail_kt.kotel.co.kr [147.6.3.33]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA02457 for ; Sun, 17 Oct 1999 17:12:34 -0700 (PDT) Received: from kt.co.kr ([147.6.65.78]) by ygmail.kt.co.kr (8.8.8/8.8.8) with ESMTP id JAA22186; Mon, 18 Oct 1999 09:14:56 +0900 (KST) Message-ID: <380A6715.F4AF4F70@kt.co.kr> Date: Mon, 18 Oct 1999 09:17:25 +0900 From: ksb Reply-To: ksbn@kt.co.kr Organization: Korea Telecom X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: "6Bone(Int)" <6bone@isi.edu>, "6Bone(WIDE)" <6bone-jp@wide.ad.jp> CC: IETF ipng Subject: RSIP merit Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk How are you? Using proxy server, NAT, CIDR, and DHCP, there are many efforts to solve the IP address problem. But IPv6 is the best solution for the IP address problem. Nowadays, some IP researchers say 'Realm Specific IP' is one of good solution for IP address exhaustion problem. If you know RSIP, will you explain about it? What is the merit of RSIP for NAT? Thanks. -- Kim, Sahng-Beom / Korea Telecom TEL : +82-42-870-8322 FAX : +82-42-870-8329 E-mail : ksbn@kt.co.kr -- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 17 21:45:21 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9I4gx809230 for ipng-dist; Sun, 17 Oct 1999 21:42:59 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9I4gnk09223 for ; Sun, 17 Oct 1999 21:42:50 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id VAA02280 for ; Sun, 17 Oct 1999 21:42:49 -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 WAA10809 for ; Sun, 17 Oct 1999 22:42:48 -0600 (MDT) Received: from new (Ihinden-3.iprg.nokia.com [205.226.22.76]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with ESMTP id VAA26282; Sun, 17 Oct 1999 21:42:47 -0700 (PDT) Message-Id: <4.2.0.58.19991017213949.03b5c100@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Sun, 17 Oct 1999 21:42:15 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: Statment on IPv6 Address Privacy Issue on IPng Web Site Cc: hinden@iprg.nokia.com, deering@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The "Statement on IPv6 Address Privacy" is now available on the IPng web site at: http://playground.sun.com/ipng I also added three presentations from the interim meeting. 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 Sun Oct 17 22:49:38 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9I5lEQ09292 for ipng-dist; Sun, 17 Oct 1999 22:47:14 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9I5l4k09285 for ; Sun, 17 Oct 1999 22:47:05 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id WAA00764 for ; Sun, 17 Oct 1999 22:47:03 -0700 (PDT) Received: from inet-vrs-02.microsoft.com (mail2.microsoft.com [131.107.3.124]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id WAA21138 for ; Sun, 17 Oct 1999 22:47:03 -0700 (PDT) Received: from 157.54.9.104 by inet-vrs-02.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 17 Oct 1999 22:47:00 -0700 (Pacific Daylight Time) Received: by INET-IMC-02 with Internet Mail Service (5.5.2650.21) id <4705NYKB>; Sun, 17 Oct 1999 22:46:59 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D81014515C3D@RED-MSG-50> From: Richard Draves To: "'IPng List'" Subject: deprecated source addresses Date: Sun, 17 Oct 1999 22:46:56 -0700 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk One of the issues that we discussed in Tokyo was when a node that is initiating communication might use a deprecated address as a source address. RFC 2462 (stateless addr conf) says in section 5.5.4: A preferred address becomes deprecated when its preferred lifetime expires. A deprecated address SHOULD continue to be used as a source address in existing communications, but SHOULD NOT be used in new communications if an alternate (non-deprecated) address is available and has sufficient scope. IP and higher layers (e.g., TCP, UDP) MUST continue to accept datagrams destined to a deprecated address since a deprecated address is still a valid address for the interface. An implementation MAY prevent any new communication from using a deprecated address, but system management MUST have the ability to disable such a facility, and the facility MUST be disabled by default. At the meeting, Steve Deering and some others were arguing strenously for a harder stance - not allowing the use of a deprecated source address in new communication at all. The argument being that if an administrator deprecates a prefix, it's because they don't want it to be used anymore, period. If that breaks something, better to know about it sooner than later. This argument had almost carried the day when Peter Tattam noted that this would introduce a new denial-of-service possibility - a bad guy could deprecate everyone's addresses and prevent new communication. Or more accurately, prevent new off-link communication, because link-local source addresses would still be available. This seemed to reopen the issue in people's minds. [Btw, I tried this denial-of-service attack in the meeting hall as an experiment, and nobody noticed. All the implementations there seemed to give scope considerations more importance in their source address selection, so they continued to use their deprecated global addresses for global destinations.] I think the order implied by the quoted paragraph above is to prefer 1. non-deprecated addresses of sufficient scope 2. deprecated addreses of sufficient scope 3. non-deprecated addresses of insufficient scope 4. deprecated addresses of insufficient scope This is the almost the order currently specified in draft-draves-ipngwg-simple-srcaddr-01. The only difference is I believe - if the destination is global scope, and the two candidate source addresses are A - deprecated site-local and B - non-deprecated link-local, my draft says to choose A instead of B. What do people on the list think about this? In the forthcoming revision of my draft, should I change this aspect of source address selection? 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 Sun Oct 17 22:57:13 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9I5tgp09319 for ipng-dist; Sun, 17 Oct 1999 22:55:42 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9I5tXk09312 for ; Sun, 17 Oct 1999 22:55:33 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id WAA10454 for ; Sun, 17 Oct 1999 22:55:32 -0700 (PDT) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id WAA23365 for ; Sun, 17 Oct 1999 22:55:32 -0700 (PDT) Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 17 Oct 1999 22:48:22 -0700 (Pacific Daylight Time) Received: by INET-IMC-03 with Internet Mail Service (5.5.2650.21) id <454G818H>; Sun, 17 Oct 1999 22:48:22 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D81014515C3E@RED-MSG-50> From: Richard Draves To: "'Jim Bound'" Cc: "'IPng List'" Subject: RE: (ngtrans) I-D ACTION:draft-ietf-ngtrans-6to4-03.txt Date: Sun, 17 Oct 1999 22:48:21 -0700 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Also lets add to the ruleset some type of preference that when the dst > address is on the same subnet (link) we use a prefix on link. > I know MS > does this for IPv4 and UNIX vendors can do it via DNS > resolver via BIND. Isn't this just a special case of what longest-matching-prefix preferences will do? 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 Sun Oct 17 23:03:22 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9I61SE09337 for ipng-dist; Sun, 17 Oct 1999 23:01:28 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.83.130] (may be forged)) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9I61Hk09330 for ; Sun, 17 Oct 1999 23:01:17 -0700 (PDT) Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id XAA427407; Sun, 17 Oct 1999 23:01:14 -0700 (PDT) Date: Sun, 17 Oct 1999 22:58:44 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: deprecated source addresses To: Richard Draves Cc: "'IPng List'" In-Reply-To: "Your message with ID" <4D0A23B3F74DD111ACCD00805F31D81014515C3D@RED-MSG-50> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I think the order implied by the quoted paragraph above is to prefer > 1. non-deprecated addresses of sufficient scope > 2. deprecated addreses of sufficient scope > 3. non-deprecated addresses of insufficient scope > 4. deprecated addresses of insufficient scope "sufficent" is really an assumption. I think it would be more accurate to use the terms "same or larger scope than the scope of the destination address". > This is the almost the order currently specified in > draft-draves-ipngwg-simple-srcaddr-01. The only difference is I believe - if > the destination is global scope, and the two candidate source addresses are > A - deprecated site-local and B - non-deprecated link-local, my draft says > to choose A instead of B. Sounds fine. > What do people on the list think about this? In the forthcoming revision of > my draft, should I change this aspect of source address selection? One could also envision that rule 1 and 2 find the an address of the same or larger scope but preferring a scope "closer" to the scope of the destination (i.e. searching through increasing scope values). Similarly, rule 3 and 4 could search through decreasing scope values. 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 Sun Oct 17 23:10:50 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9I69ja09372 for ipng-dist; Sun, 17 Oct 1999 23:09:45 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9I69Zk09365 for ; Sun, 17 Oct 1999 23:09:37 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id XAA06254 for ; Sun, 17 Oct 1999 23:09:37 -0700 (PDT) Received: from inet-vrs-02.microsoft.com (mail2.microsoft.com [131.107.3.124]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id XAA27498 for ; Sun, 17 Oct 1999 23:09:36 -0700 (PDT) Received: from 157.54.9.104 by inet-vrs-02.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 17 Oct 1999 23:09:26 -0700 (Pacific Daylight Time) Received: by INET-IMC-02 with Internet Mail Service (5.5.2650.21) id <4705NZ25>; Sun, 17 Oct 1999 23:09:25 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D81014515C40@RED-MSG-50> From: Richard Draves To: "'Erik Nordmark'" Cc: "'IPng List'" Subject: RE: deprecated source addresses Date: Sun, 17 Oct 1999 23:09:23 -0700 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > One could also envision that rule 1 and 2 find the an address of the > same or larger scope but preferring a scope "closer" to the scope > of the destination (i.e. searching through increasing scope values). > Similarly, rule 3 and 4 could search through decreasing scope values. That's not quite what the draft says. Here's a difference: suppose the destination address is site-local, and you are choosing between A - deprecated site-local source, and B - non-deprecated global source. Then the 01 draft says to choose B over A. 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 Sun Oct 17 23:48:47 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9I6kNa09456 for ipng-dist; Sun, 17 Oct 1999 23:46:23 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9I6kEk09449 for ; Sun, 17 Oct 1999 23:46:15 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id XAA07578 for ; Sun, 17 Oct 1999 23:46:15 -0700 (PDT) Received: from ygmail.kt.co.kr (ygmail_kt.kotel.co.kr [147.6.3.33]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA08154 for ; Sun, 17 Oct 1999 23:46:13 -0700 (PDT) Received: from kt.co.kr ([147.6.65.78]) by ygmail.kt.co.kr (8.8.8/8.8.8) with ESMTP id PAA26296; Mon, 18 Oct 1999 15:50:22 +0900 (KST) Message-ID: <380AC3BF.848E427C@kt.co.kr> Date: Mon, 18 Oct 1999 15:52:48 +0900 From: ksb Reply-To: ksbn@kt.co.kr Organization: Korea Telecom X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: "6Bone(Int)" <6bone@isi.edu> CC: IETF ipng Subject: IPv6 router Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk How are you? I'm looking for the stable backbone routers(IPv6). Cisco has just beta solution. Will you send me the product information for IPv6 backbone routers(including release version o/s)? Thank you. -- Kim, Sahng-Beom / Korea Telecom TEL : +82-42-870-8322 FAX : +82-42-870-8329 E-mail : ksbn@kt.co.kr -- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 18 03:55:09 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9IAqex09604 for ipng-dist; Mon, 18 Oct 1999 03:52:40 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9IAqUk09597 for ; Mon, 18 Oct 1999 03:52:30 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id DAA22162 for ; Mon, 18 Oct 1999 03:52:29 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA06288 for ; Mon, 18 Oct 1999 04:52:28 -0600 (MDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26940; Mon, 18 Oct 1999 06:52:26 -0400 (EDT) Message-Id: <199910181052.GAA26940@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-dns-lookups-05.txt Date: Mon, 18 Oct 1999 06:52:25 -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 : DNS Extensions to Support IPv6 Address Aggregation and Renumbering Author(s) : M. Crawford, C. Huitema, S. Thomson Filename : draft-ietf-ipngwg-dns-lookups-05.txt Pages : 17 Date : 15-Oct-99 This document defines changes to the Domain Name System to support renumberable and aggregatable IPv6 addressing. The changes include a new resource record type to store an IPv6 address in a manner which expedites network renumbering, one new query type and updated definitions of existing query types that return Internet addresses as part of additional section processing. For lookups keyed on IPv6 addresses (often called reverse lookups), this document defines a new zone structure which allows a zone to be used without modification for parallel copies of an address space (as for a multihomed provider or site) and across network renumbering events. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-dns-lookups-05.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-dns-lookups-05.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-dns-lookups-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19991015093343.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-dns-lookups-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-dns-lookups-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991015093343.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 18 06:19:08 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9IDFss09839 for ipng-dist; Mon, 18 Oct 1999 06:15:54 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9IDFZk09832 for ; Mon, 18 Oct 1999 06:15:41 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id GAA24294 for ; Mon, 18 Oct 1999 06:15:36 -0700 (PDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA03305 for ; Mon, 18 Oct 1999 07:15:34 -0600 (MDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id OAA69734 for ; Mon, 18 Oct 1999 14:15:32 +0100 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id OAA25238 for ; Mon, 18 Oct 1999 14:15:30 +0100 (BST) Message-ID: <38074300.728ACB6C@hursley.ibm.com> Date: Fri, 15 Oct 1999 10:06:40 -0500 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: My InternetWeek op-ed column on IPv6 privacy issues References: <199910150703.KAA05655@anise.tte.vtt.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Markku is on a good point. For the billion or so always-on wireless devices we will have on the net in a few years, permanent addresses are a must. Brian Markku Savela wrote: > > [I removed the long CC list] > > This discussion seems to lead to a situation where IP-addresses are > never "permanent", just when I was hoping that IPv6 would bring enough > addresses to use, so that I could have permanent addresses for myself... > > This is a dilemma... > > - for some things I would like to use random (src) address > > - but, I still would like to have permantent address so that my SMTP > daemon on mobile phone [:-)] can be contacted (or that it can > receive voice over IP calls). Or just that I can run WEB server on > my home machine, to be more realistic. > > Is this another dimension to the source address selection discussion? > > -- > Markku Savela (msa@hemuli.tte.vtt.fi), Technical Research Centre of Finland > Multimedia Systems, P.O.Box 1203,FIN-02044 VTT,http://www.vtt.fi/tte/staff/msa/ > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 18 06:57:47 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9IDtJg09928 for ipng-dist; Mon, 18 Oct 1999 06:55:19 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9IDt8k09921 for ; Mon, 18 Oct 1999 06:55:10 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id GAA17924 for ; Mon, 18 Oct 1999 06:55:09 -0700 (PDT) Received: from dfw-ix7.ix.netcom.com (dfw-ix7.ix.netcom.com [206.214.98.7]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA06639 for ; Mon, 18 Oct 1999 06:55:09 -0700 (PDT) Received: (from smap@localhost) by dfw-ix7.ix.netcom.com (8.8.4/8.8.4) id IAA15290; Mon, 18 Oct 1999 08:54:43 -0500 (CDT) Received: from dal-tx42-61.ix.netcom.com(207.221.94.125) by dfw-ix7.ix.netcom.com via smap (V1.3) id rma015230; Mon Oct 18 08:54:16 1999 Message-ID: <380AB615.21B6D11B@ix.netcom.com> Date: Mon, 18 Oct 1999 06:54:30 +0100 From: Jeff Williams Organization: INEG. Inc. (Spokesman INEGroup) X-Mailer: Mozilla 4.08 [en] (Win16; I) MIME-Version: 1.0 To: Brian E Carpenter CC: ipng@sunroof.eng.sun.com Subject: Re: My InternetWeek op-ed column on IPv6 privacy issues References: <199910150703.KAA05655@anise.tte.vtt.fi> <38074300.728ACB6C@hursley.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian and all, Excuse me Brian, but why must those devices have permanent IP addresses? As you know to do so creates a privacy problem that is also as you know, addressable, pardon the pun. >;) Brian E Carpenter wrote: > Markku is on a good point. For the billion or so always-on wireless > devices we will have on the net in a few years, permanent addresses > are a must. > > Brian > > Markku Savela wrote: > > > > [I removed the long CC list] > > > > This discussion seems to lead to a situation where IP-addresses are > > never "permanent", just when I was hoping that IPv6 would bring enough > > addresses to use, so that I could have permanent addresses for myself... > > > > This is a dilemma... > > > > - for some things I would like to use random (src) address > > > > - but, I still would like to have permantent address so that my SMTP > > daemon on mobile phone [:-)] can be contacted (or that it can > > receive voice over IP calls). Or just that I can run WEB server on > > my home machine, to be more realistic. > > > > Is this another dimension to the source address selection discussion? > > > > -- > > Markku Savela (msa@hemuli.tte.vtt.fi), Technical Research Centre of Finland > > Multimedia Systems, P.O.Box 1203,FIN-02044 VTT,http://www.vtt.fi/tte/staff/msa/ > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home 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 > -------------------------------------------------------------------- Regards, -- Jeffrey A. Williams Spokesman INEGroup (Over 95k members strong!) CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 972-447-1894 Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 18 07:01:53 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9IE0cm09946 for ipng-dist; Mon, 18 Oct 1999 07:00:38 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9IE0Rk09939 for ; Mon, 18 Oct 1999 07:00:29 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA02939 for ; Mon, 18 Oct 1999 07:00:28 -0700 (PDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA16112 for ; Mon, 18 Oct 1999 08:00:27 -0600 (MDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id PAA275302 for ; Mon, 18 Oct 1999 15:00:24 +0100 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id PAA34802 for ; Mon, 18 Oct 1999 15:00:22 +0100 (BST) Message-ID: <380B27B8.79153EA6@hursley.ibm.com> Date: Mon, 18 Oct 1999 08:59:20 -0500 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: FYI Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'm told that somebody calling himself Jeff Williams has been addressing mail to me and this list. FYI, I have been filtering mail allegedly from this person straight into my trash folder for some years, and will continue to do so. Brian Carpenter -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 18 07:15:27 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9IECfV10062 for ipng-dist; Mon, 18 Oct 1999 07:12:41 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9IECVk10055 for ; Mon, 18 Oct 1999 07:12:32 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA19050 for ; Mon, 18 Oct 1999 07:12:32 -0700 (PDT) Received: from qn-lpr1-104.quicknet.inet.fi (qn-lpr1-104.quicknet.inet.fi [194.251.105.104]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id HAA15070 for ; Mon, 18 Oct 1999 07:12:30 -0700 (PDT) Received: from lut.fi(localhost[127.0.0.1]) (1165 bytes) by qn-lpr1-104.quicknet.inet.fi via sendmail with P:esmtp/R:bind_hosts/T:inet_zone_bind_smtp (sender: ) id for ; Mon, 18 Oct 1999 17:10:47 +0300 (EET DST) (Smail-3.2.0.106 1999-Mar-31 #3 built DST-Apr-19) Message-ID: <380B2A5C.619889C0@lut.fi> Date: Mon, 18 Oct 1999 17:10:36 +0300 From: Ville Nummela X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.12 i586) X-Accept-Language: en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: My InternetWeek op-ed column on IPv6 privacy issues Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by sunroof.eng.sun.com id d9IECXk10056 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jeff Williams wrote: > Excuse me Brian, but why must those devices have permanent > IP addresses? As you know to do so creates a privacy problem > that is also as you know, addressable, pardon the pun. >;) Your telephone has a permanent telephone number, does that create a privacy problem for you? -- | vnummela@lut.fi work: +358-5-4125389 home: +358-40-5075560 | | 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 Mon Oct 18 07:18:14 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9IEG6f10088 for ipng-dist; Mon, 18 Oct 1999 07:16:06 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9IEFgk10081 for ; Mon, 18 Oct 1999 07:15:49 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA29452 for ; Mon, 18 Oct 1999 07:15:43 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA16479 for ; Mon, 18 Oct 1999 07:15:42 -0700 (PDT) Received: from zed.isi.edu (zed-e.isi.edu [128.9.160.57]) by boreas.isi.edu (8.8.7/8.8.6) with ESMTP id HAA05561; Mon, 18 Oct 1999 07:15:41 -0700 (PDT) From: Bill Manning Received: (from bmanning@localhost) by zed.isi.edu (8.8.7/8.8.6) id HAA29252; Mon, 18 Oct 1999 07:15:41 -0700 (PDT) Message-Id: <199910181415.HAA29252@zed.isi.edu> Subject: Re: My InternetWeek op-ed column on IPv6 privacy issues To: brian@hursley.ibm.com (Brian E Carpenter) Date: Mon, 18 Oct 1999 07:15:41 -0700 (PDT) Cc: ipng@sunroof.eng.sun.com In-Reply-To: <38074300.728ACB6C@hursley.ibm.com> from "Brian E Carpenter" at Oct 15, 99 10:06:40 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, Is it worthwhile to keep a distinction between places in the topology (e.g. IP addresses) and what the current occupent of that space is (e.g. the node name)? The driver that Markku and seemingly you make is that the node and its place in the topology are invarient. > Markku is on a good point. For the billion or so always-on wireless > devices we will have on the net in a few years, permanent addresses > are a must. > > Brian > > Markku Savela wrote: > > > > [I removed the long CC list] > > > > This discussion seems to lead to a situation where IP-addresses are > > never "permanent", just when I was hoping that IPv6 would bring enough > > addresses to use, so that I could have permanent addresses for myself... > > > > This is a dilemma... > > > > - for some things I would like to use random (src) address > > > > - but, I still would like to have permantent address so that my SMTP > > daemon on mobile phone [:-)] can be contacted (or that it can > > receive voice over IP calls). Or just that I can run WEB server on > > my home machine, to be more realistic. > > > > Is this another dimension to the source address selection discussion? > > > > -- > > Markku Savela (msa@hemuli.tte.vtt.fi), Technical Research Centre of Finland > > Multimedia Systems, P.O.Box 1203,FIN-02044 VTT,http://www.vtt.fi/tte/staff/msa/ > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home 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 > -------------------------------------------------------------------- > -- --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 Mon Oct 18 07:19:48 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9IEIge10108 for ipng-dist; Mon, 18 Oct 1999 07:18:42 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9IEITk10099 for ; Mon, 18 Oct 1999 07:18:30 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA29908 for ; Mon, 18 Oct 1999 07:18:30 -0700 (PDT) Received: from dfw-ix7.ix.netcom.com (dfw-ix7.ix.netcom.com [206.214.98.7]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA17868 for ; Mon, 18 Oct 1999 07:18:29 -0700 (PDT) Received: (from smap@localhost) by dfw-ix7.ix.netcom.com (8.8.4/8.8.4) id JAA17015; Mon, 18 Oct 1999 09:18:25 -0500 (CDT) Received: from dal-tx42-61.ix.netcom.com(207.221.94.125) by dfw-ix7.ix.netcom.com via smap (V1.3) id rma016815; Mon Oct 18 09:17:45 1999 Message-ID: <380ABB98.FDE74887@ix.netcom.com> Date: Mon, 18 Oct 1999 07:18:01 +0100 From: Jeff Williams Organization: INEG. Inc. (Spokesman INEGroup) X-Mailer: Mozilla 4.08 [en] (Win16; I) MIME-Version: 1.0 To: Brian E Carpenter CC: ipng@sunroof.eng.sun.com Subject: Re: FYI References: <380B27B8.79153EA6@hursley.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian and all, Indeed this is a shame. Such behavior is a good indication of lack of an answer to my previous question regarding "Permanent" addresses for "Always On" devices as part ot the IPv6 standard. Personal attacks of this nature speak for themselves, Brian. Brian E Carpenter wrote: > I'm told that somebody calling himself Jeff Williams has been > addressing mail to me and this list. > > FYI, I have been filtering mail allegedly from this person > straight into my trash folder for some years, and will > continue to do so. > > Brian Carpenter > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- Regards, -- Jeffrey A. Williams Spokesman INEGroup (Over 95k members strong!) CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 972-447-1894 Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 18 07:56:15 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9IErZW10231 for ipng-dist; Mon, 18 Oct 1999 07:53:35 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9IErQk10224 for ; Mon, 18 Oct 1999 07:53:26 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA02762 for ; Mon, 18 Oct 1999 07:53:26 -0700 (PDT) Received: from alcove.wittsend.com (alcove.wittsend.com [130.205.0.20]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA05456 for ; Mon, 18 Oct 1999 08:53:25 -0600 (MDT) Received: (from mhw@localhost) by alcove.wittsend.com (8.9.3/8.9.3) id KAA09053; Mon, 18 Oct 1999 10:52:54 -0400 Date: Mon, 18 Oct 1999 10:52:54 -0400 From: "Michael H. Warfield" To: Ville Nummela Cc: ipng@sunroof.eng.sun.com Subject: Re: My InternetWeek op-ed column on IPv6 privacy issues Message-ID: <19991018105254.B1606@alcove.wittsend.com> References: <380B2A5C.619889C0@lut.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i In-Reply-To: <380B2A5C.619889C0@lut.fi> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, Oct 18, 1999 at 05:10:36PM +0300, Ville Nummela wrote: > Jeff Williams wrote: > > Excuse me Brian, but why must those devices have permanent > > IP addresses? As you know to do so creates a privacy problem > > that is also as you know, addressable, pardon the pun. >;) > Your telephone has a permanent telephone number, does that create a privacy problem > for you? For some people it really does, once you grant the existance of CLID (Calling Line ID). Once the originating number becomes known to the destination number, you have an analogous situation. Yes. Then there are a number of people who have a serious privacy problem over their telephone numbers and there has been, in the past, a great deal of controversy over CLID. It seriously delayed widespread introduction of CLID in spite of the tremendous demand for it and in spite of the demonstrated reduction in crank, obscene, and threatening phone calls. California even had a law on the books banning CLID resulting in the amusing situation that people in other states could get the numbers of Californian callers but other Californians could not. That ended only when the FCC mandated CLID availability nation wide. Some of the solutions have been "use various pay phones" (Dynamic address for your source phone number?) or use "calling number block" (but then we have "block the blocker" services). I've never heard of anyone suggesting real "dynamic numbers" for outbound calls to address this, but it is similar to what you get with PBXs and DID trunks where the number that shows up on the CLID box is the outgoing PBX trunk and not your inward dialing DID number. For most of us (myself included) fixed static IP addresses (IPv4 or IPv6) present no privacy concerns. For many of us, the advantages of fixed addresses far outweight the disadvantages, especially for our servers, but even for our workstations. For others, this presents just as serious a privacy convern as the Battered Woman's Shelter that does not want its phone number to show up on an abuser's CLID box. For others still, the fact that WE have fixed static address and THEY have dynamic addresses singles them out (the block the blocker stuff). They end up catagorized because they make this choice that they don't want static addresses and then things get denied them or they get treated differently than the rest of us (or so they fear). Our exercize of our right to not give a damn about the issue for ourselves becomes a personal threat, in their eyes, to their ability to exercize their rights to consider this to be a paramount serious issue. I have mail filters on my mail server that checks with DULS and DSSL to see if the peer contacting me is from a "dial-in" dynamic block of addresses. If it is, I refuse all mail (drop it in a SPAM CAN) from them (they should be going through their ISP server) since most of that is nothing but SPAM (>99%). This doesn't affect DHCP allocated addresses (unless the maintainers are foolish enough to use names which trip DSSL). Still, for at least one service, I do discriminate against dynamically allocated addresses. There may be other reasons now or in the future. I don't think there are very good solutions to the "block the blocker" situation. By solving their concerns, it opens up a can of worms for the rest of us when people start abusing their ability to hide while acting irresponsibly. It's the same thing as the anonymity vs accountablity debate. How do you preserve someone's privacy without giving them the ability to violate the rights (and privacy) of others around them without fear of accountablity. > -- > | vnummela@lut.fi work: +358-5-4125389 home: +358-40-5075560 | > | 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 > -------------------------------------------------------------------- Mike -- Michael H. Warfield | (770) 985-6132 | mhw@WittsEnd.com (The Mad Wizard) | (770) 331-2437 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it! -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 18 09:17:43 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9IGD4o10335 for ipng-dist; Mon, 18 Oct 1999 09:13:04 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9IGCtk10328 for ; Mon, 18 Oct 1999 09:12:55 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA13548 for ; Mon, 18 Oct 1999 09:12:55 -0700 (PDT) Received: from infobro.com ([204.255.254.70]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id KAA08653 for ; Mon, 18 Oct 1999 10:12:39 -0600 (MDT) Received: from red (unverified [205.161.100.60]) by infobro.com (EMWAC SMTPRS 0.83) with SMTP id ; Mon, 18 Oct 1999 12:12:24 -0400 Received: by localhost with Microsoft MAPI; Mon, 18 Oct 1999 12:12:21 -0400 Message-ID: <01BF1962.07DD3450.eric@infobro.com> From: "Eric D. Williams" To: "'Ville Nummela'" , "'ipng@sunroof.eng.sun.com'" Subject: RE: My InternetWeek op-ed column on IPv6 privacy issues Date: Mon, 18 Oct 1999 12:12:18 -0400 Organization: Information Brokers, Inc. X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The telephone issue is only important if your phone is tapped. In the case of addresses used to identify a system or systems the issue is one of connected sites tracking the 'habits' or 'movements' of such systems. I really think the appropriate venue for the privacy discussion is not this list. In fact, the privacy concerns stated can be easily transferred to a plethora of different technological implementations. Further, if we must engage this issue fully perhaps the proper context wold be (once again) how to introduce a level of permanence in addressing, of possibly mobile devices, whilst preserving a level of privacy (through some specific privacy regime) for 'fixed locale' devices. This is a difficult prospect to be sure. But, I maintain this is not the venue for this discussion unless we are truly willing to consider trashing the permanence of interface ID's completely. Eric Eric Williams, Pres. Information Brokers, Inc. Phone: +1 202.889.4395 http://www.infobro.com/ Fax: +1 202.889.4396 mailto:eric@infobro.com Pager: +1 301.303.8998 For More Info: info@infobro.com On Monday, October 18, 1999 10:11 AM, Ville Nummela [SMTP:vnummela@lut.fi] wrote: > Jeff Williams wrote: > > > Excuse me Brian, but why must those devices have permanent > > IP addresses? As you know to do so creates a privacy problem > > that is also as you know, addressable, pardon the pun. >;) > > Your telephone has a permanent telephone number, does that create a privacy > problem > for you? > > > -- > | vnummela@lut.fi work: +358-5-4125389 home: +358-40-5075560 | > | 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 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 18 10:27:02 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9IHNxU10559 for ipng-dist; Mon, 18 Oct 1999 10:23:59 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.87.31] (may be forged)) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9IHNmk10552 for ; Mon, 18 Oct 1999 10:23:48 -0700 (PDT) Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id KAA473390; Mon, 18 Oct 1999 10:23:47 -0700 (PDT) Date: Mon, 18 Oct 1999 10:23:46 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: deprecated source addresses To: Richard Draves Cc: "'Erik Nordmark'" , "'IPng List'" In-Reply-To: "Your message with ID" <4D0A23B3F74DD111ACCD00805F31D81014515C40@RED-MSG-50> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > That's not quite what the draft says. Here's a difference: suppose the > destination address is site-local, and you are choosing between A - > deprecated site-local source, and B - non-deprecated global source. Then the > 01 draft says to choose B over A. Sure. But I meant within one of the rules (1 through 4). For instance, when sending to a global address if the choice is a deprecated site-local and a deprecated link-local use the site-local since it is "closer" in scope. Likewise, when sending to a link-local address and the choice is a preferred site-local and a preferred global, choice the site-local since it is "closer". 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 18 10:53:09 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9IHmNi10656 for ipng-dist; Mon, 18 Oct 1999 10:48:23 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9IHm9k10649 for ; Mon, 18 Oct 1999 10:48:09 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA04166 for ; Mon, 18 Oct 1999 10:48:05 -0700 (PDT) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA11108 for ; Mon, 18 Oct 1999 10:48:04 -0700 (PDT) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id MAA01985; Mon, 18 Oct 1999 12:47:58 -0500 (CDT) Message-Id: <199910181747.MAA01985@gungnir.fnal.gov> To: "Eric D. Williams" Cc: "'ipng@sunroof.eng.sun.com'" Reply-To: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: Re: My InternetWeek op-ed column on IPv6 privacy issues In-reply-to: Your message of Mon, 18 Oct 1999 12:12:18 EDT. <01BF1962.07DD3450.eric@infobro.com> Date: Mon, 18 Oct 1999 12:47:57 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The telephone issue is only important if your phone is tapped. Nonsense. > In the case of addresses used to identify a system or systems the > issue is one of connected sites tracking the 'habits' or > 'movements' of such systems. The very same thing can be done with the databases of all the organizations whose toll-free numbers you've called. And if one of those databases contains your credit card number, or government- imposed personal ID, then it leads to volumes of additional data about you. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 18 11:14:15 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9IIB2q10740 for ipng-dist; Mon, 18 Oct 1999 11:11:02 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9IIAqk10733 for ; Mon, 18 Oct 1999 11:10:53 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA09404; Mon, 18 Oct 1999 11:10:51 -0700 (PDT) Received: from monet.artisan.calpoly.edu (monet.artisan.calpoly.edu [129.65.60.33]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA01196; Mon, 18 Oct 1999 12:10:50 -0600 (MDT) Received: from localhost (anchavez@localhost) by monet.artisan.calpoly.edu (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id LAA03491; Mon, 18 Oct 1999 11:10:49 -0700 (PDT) X-Authentication-Warning: monet.artisan.calpoly.edu: anchavez owned process doing -bs Date: Mon, 18 Oct 1999 11:10:49 -0700 (PDT) From: "Angelica Chavez (Angie)" X-Sender: anchavez@monet.artisan.calpoly.edu To: Erik Nordmark cc: Richard Draves , "'IPng List'" Subject: RE: deprecated source addresses 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 Hello ipng list, I was just wondering how I can get off of this mailing list. My email account has a very small quota of disk space and my mailbox seems to get full pretty quickly (due to all of my ipng messages). Can anyone help me? Thanks, Angie Chavez Cal Poly Student -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 18 11:19:04 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9IIHDJ10758 for ipng-dist; Mon, 18 Oct 1999 11:17:13 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9IIGMk10751 for ; Mon, 18 Oct 1999 11:16:27 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA13603 for ; Mon, 18 Oct 1999 11:15:42 -0700 (PDT) Received: from dfw-ix12.ix.netcom.com (dfw-ix12.ix.netcom.com [206.214.98.12]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA26725 for ; Mon, 18 Oct 1999 11:15:41 -0700 (PDT) Received: (from smap@localhost) by dfw-ix12.ix.netcom.com (8.8.4/8.8.4) id NAA11497; Mon, 18 Oct 1999 13:14:49 -0500 (CDT) Received: from dal-tx42-56.ix.netcom.com(207.221.94.120) by dfw-ix12.ix.netcom.com via smap (V1.3) id rma011444; Mon Oct 18 13:14:16 1999 Message-ID: <380AF306.A1FD7408@ix.netcom.com> Date: Mon, 18 Oct 1999 11:14:32 +0100 From: Jeff Williams Organization: INEG. Inc. (Spokesman INEGroup) X-Mailer: Mozilla 4.08 [en] (Win16; I) MIME-Version: 1.0 To: "Eric D. Williams" CC: "'Ville Nummela'" , "'ipng@sunroof.eng.sun.com'" Subject: Re: My InternetWeek op-ed column on IPv6 privacy issues References: <01BF1962.07DD3450.eric@infobro.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Eric and all, I feel you concern here Eric, but I am not in complete agreement with you in regards to this venue as being appropriate. Indeed I can think of no other venue or forum where these questions and concerns could be better addressed at present. If you do know of one please let us know of it, if you would. As to your analogy regarding the phone. I also have a bit of a problem with your comment there as well. Caller ID, for instance is a concern but devices are available to block Caller ID. Hence the same sort of approach needs to be available as default for autoconfig of IPv6 as well. Eric D. Williams wrote: > The telephone issue is only important if your phone is tapped. In the case of > addresses used to > identify a system or systems the issue is one of connected sites tracking the > 'habits' or 'movements' > of such systems. I really think the appropriate venue for the privacy > discussion is not this list. In fact, > the privacy concerns stated can be easily transferred to a plethora of > different technological implementations. > > Further, if we must engage this issue fully perhaps the proper context wold be > (once again) how to introduce a level of permanence in addressing, of possibly > mobile devices, whilst preserving a level of privacy (through some specific > privacy regime) for 'fixed locale' devices. This is a difficult prospect to be > sure. But, I maintain this is not the venue for this discussion unless we are > truly willing to consider trashing the permanence of interface ID's > completely. > > Eric > Eric Williams, Pres. > Information Brokers, Inc. Phone: +1 202.889.4395 > http://www.infobro.com/ Fax: +1 202.889.4396 > mailto:eric@infobro.com Pager: +1 301.303.8998 > For More Info: info@infobro.com > > On Monday, October 18, 1999 10:11 AM, Ville Nummela [SMTP:vnummela@lut.fi] > wrote: > > Jeff Williams wrote: > > > > > Excuse me Brian, but why must those devices have permanent > > > IP addresses? As you know to do so creates a privacy problem > > > that is also as you know, addressable, pardon the pun. >;) > > > > Your telephone has a permanent telephone number, does that create a privacy > > problem > > for you? > > > > > > -- > > | vnummela@lut.fi work: +358-5-4125389 home: +358-40-5075560 | > > | 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 > > ---------------------------------------------------------------------------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- Regards, -- Jeffrey A. Williams Spokesman INEGroup (Over 95k members strong!) CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 972-447-1894 Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 18 12:06:18 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9IJ3ET11059 for ipng-dist; Mon, 18 Oct 1999 12:03:14 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9IJ30k11043 for ; Mon, 18 Oct 1999 12:03:01 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA23618 for ; Mon, 18 Oct 1999 12:03:00 -0700 (PDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA25021 for ; Mon, 18 Oct 1999 13:02:54 -0600 (MDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id UAA305046; Mon, 18 Oct 1999 20:02:47 +0100 Received: from hursley.ibm.com (lig32-227-14-154.us.lig-dial.ibm.com [32.227.14.154]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id UAA28122; Mon, 18 Oct 1999 20:02:44 +0100 (BST) Message-ID: <380B6E94.293C3EB5@hursley.ibm.com> Date: Mon, 18 Oct 1999 14:01:40 -0500 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Fred Baker CC: ipng@sunroof.eng.sun.com Subject: Re: FYI... References: <4.1.19991015164604.00bdcb70@flipper.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Fred, I think it's very important that we all *start* each dealing with press by pointing out that privacy is important, that the IETF definitely cares about privacy (e.g. our stand on cryptography), and that we certainly don't believe that IPv6 is a threat to privacy. Then get into the details. Brian Fred Baker wrote: > > I have been sending the following email to any number of reporters and > privacy advocates for the last couple of days. You may want to critique it. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 18 13:18:41 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9IKDoW11256 for ipng-dist; Mon, 18 Oct 1999 13:13:50 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9IKDjk11249 for ; Mon, 18 Oct 1999 13:13:45 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.1b+Sun/8.9.1) id NAA20762 for ipng@sunroof.eng.sun.com; Mon, 18 Oct 1999 13:11:26 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9ICxTk09790 for ; Mon, 18 Oct 1999 05:59:30 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id FAA24273 for ; Mon, 18 Oct 1999 05:59:30 -0700 (PDT) Received: from luxisoya.kame.net (kame196.kame.net [203.178.141.196]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA12909 for ; Mon, 18 Oct 1999 05:59:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by luxisoya.kame.net (8.8.8/8.8.8) with ESMTP id VAA11909 for ; Mon, 18 Oct 1999 21:59:16 +0900 (JST) (envelope-from shin@luxisoya.kame.net) >To: ckyip@krdl.org.sg Cc: ipng@sunroof.eng.sun.com Subject: Re: ipng software From: fujisawa@kame.net In-Reply-To: Your message of "Fri, 15 Oct 1999 19:21:42 +0800 (SGT)" References: <3.0.32.19991015193619.00a0bbe0@mailhost.krdl.org.sg> X-Mailer: Mew version 1.70 on Emacs 19.34.1 / Mule 2.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 18 Oct 1999 21:59:16 +0900 Message-ID: <11907.940251556@luxisoya.kame.net> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, Yip Chan Keong > 1. an ipv4 - ipv6 translator, preferably siit compliant. kame has indicated > that work is undergoing for this pc of software. any idea what is the status? KAME translator is still implementing, but I will put this code into kame-snap before the month is out, so wait a while to get translator. This translator can translate ipv6 <-> ipv4. But there is address mapping problem when translate ipv4 -> ipv6, so if you want to connect ipv4 -> ipv6 this translator can do 1 to 1 translation only. You can set 1 to 1 address mapping pair into translator configuration, but you must know both ipv4 host address and ipv6 host address. This is quite annoying. So, please wait until I implement its address mapping daemon that resolve this problem. -- (fujisawa @ kame ) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 18 13:18:53 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9IKBVU11247 for ipng-dist; Mon, 18 Oct 1999 13:11:31 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9IKBPk11240 for ; Mon, 18 Oct 1999 13:11:25 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.1b+Sun/8.9.1) id NAA20732 for ipng@sunroof.eng.sun.com; Mon, 18 Oct 1999 13:09:05 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9IAXwk09583 for ; Mon, 18 Oct 1999 03:33:59 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id DAA21487 for ; Mon, 18 Oct 1999 03:33:57 -0700 (PDT) Received: from qhars002.nortel.com (qhars002.NortelNetworks.com [192.100.101.19]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA22715 for ; Mon, 18 Oct 1999 03:33:56 -0700 (PDT) Received: from zhard00d.europe.nortel.com (actually zhard00d) by qhars002.nortel.com; Mon, 18 Oct 1999 11:32:27 +0100 Received: from zvb1c004.corpemea.baynetworks.com (ZVB1C004 [141.251.160.84]) by zhard00d.europe.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id VA68TGN4; Mon, 18 Oct 1999 11:32:30 +0100 Received: from rbesemer.corpemea.baynetworks.com (RBESEMER [141.251.189.222]) by zvb1c004.corpemea.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id VA87YCNX; Mon, 18 Oct 1999 12:32:09 +0200 Message-Id: <3.0.32.19991018123009.007a1340@zvb1c004.corpemea.baynetworks.com> X-Sender: rbesemer@zvb1c004.corpemea.baynetworks.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 18 Oct 1999 12:30:10 +0100 To: ksbn@kt.co.kr From: "Reinhard Besemer" Subject: Re: IPv6 router Cc: "6Bone(Int)" <6bone@ISI.EDU>, IETF ipng Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Kim, take a look at the Backbone Node Routers of Nortel Networks (former Bay Networks). The routers have an IPv6 implementation since Router Software Version 12.0 (available for almost two years now). Take this link for further details and look for BACKBONE NODE or BAY NETWORKS ROUTER: http://www.nortelnetworks.com/products/customers/enterprise.html Best regards Reinhard At 15:52 18.10.99 +0900, ksb wrote... >How are you? > >I'm looking for the stable backbone routers(IPv6). >Cisco has just beta solution. >Will you send me the product information for IPv6 >backbone routers(including release version o/s)? > >Thank you. > >-- > Kim, Sahng-Beom / Korea Telecom > TEL : +82-42-870-8322 > FAX : +82-42-870-8329 > E-mail : ksbn@kt.co.kr >-- > > $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ Reinhard Besemer Nortel Networks Educational Services EMEA $ $ Teamleader East EMEA Phone: +49 711 1394 352 $ $ Mittlerer Pfad 26 Fax: +49 711 1394 330 $ $ D-70499 Stuttgart E-Mail: rbesemer@nortelnetworks.com $ $ Germany URL: http://support.baynetworks.com/training $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 18 13:53:14 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9IKnxd11377 for ipng-dist; Mon, 18 Oct 1999 13:49:59 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9IKnok11370 for ; Mon, 18 Oct 1999 13:49:51 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA10654 for ; Mon, 18 Oct 1999 13:49:49 -0700 (PDT) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id OAA08622 for ; Mon, 18 Oct 1999 14:49:49 -0600 (MDT) Received: from 157.54.9.108 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 18 Oct 1999 13:06:08 -0700 (Pacific Daylight Time) Received: by INET-IMC-05 with Internet Mail Service (5.5.2650.21) id ; Mon, 18 Oct 1999 13:06:08 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D81014515C4B@RED-MSG-50> From: Richard Draves To: "'Erik Nordmark'" Cc: "'IPng List'" Subject: RE: deprecated source addresses Date: Mon, 18 Oct 1999 13:06:02 -0700 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > For instance, when sending to a global address if the choice > is a deprecated > site-local and a deprecated link-local use the site-local since it is > "closer" in scope. > Likewise, when sending to a link-local address and the choice > is a preferred > site-local and a preferred global, choice the site-local > since it is "closer". Yes, the current 01 draft specifies those choices. Here is a summary of what it chooses in the several situations we've discussed : 1. global destination. source A is deprecated site-local or global, source B is preferred link-local. Choose A. 2. global destination. source A is deprecated site-local and source B is deprecated link-local. Choose A. 3. site-local destination. source A is deprecated site-local or global, source B is preferred global. Choose B. 4. link-local destination. source A is preferred site-local, source B is preferred global. Choose A. So in light of the Tokyo discussion, who would like me to change this aspect of the draft? 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 Mon Oct 18 14:30:46 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9ILTAE11458 for ipng-dist; Mon, 18 Oct 1999 14:29:10 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9ILT5k11451 for ; Mon, 18 Oct 1999 14:29:05 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.1b+Sun/8.9.1) id OAA20858 for ipng@sunroof.eng.sun.com; Mon, 18 Oct 1999 14:26:48 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9IENkk10145 for ; Mon, 18 Oct 1999 07:23:47 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA20036 for ; Mon, 18 Oct 1999 07:23:47 -0700 (PDT) Received: from monza.broadswitch.com ([195.178.164.73]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA20528 for ; Mon, 18 Oct 1999 07:23:45 -0700 (PDT) Received: by monza.broadswitch.com with Internet Mail Service (5.5.2448.0) id ; Mon, 18 Oct 1999 16:23:43 +0200 Message-ID: <45AFD48D077ED211BB4700A0C9DCE8FD15ACA1@monza.broadswitch.com> From: Thomas Eklund To: "'Ville Nummela'" , ipng@sunroof.eng.sun.com Subject: RE: My InternetWeek op-ed column on IPv6 privacy issues Date: Mon, 18 Oct 1999 16:23:37 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk You can always generate temporary interface tokens or session keys to use as a source addresss... compare to IMSI and TMSI in cellular.... /regards Thomas Eklund > -----Original Message----- > From: Ville Nummela [mailto:vnummela@lut.fi] > Sent: Monday, October 18, 1999 4:11 PM > To: ipng@sunroof.eng.sun.com > Subject: My InternetWeek op-ed column on IPv6 privacy issues > > > Jeff Williams wrote: > > > Excuse me Brian, but why must those devices have permanent > > IP addresses? As you know to do so creates a privacy problem > > that is also as you know, addressable, pardon the pun. >;) > > Your telephone has a permanent telephone number, does that > create a privacy problem > for you? > > > -- > | vnummela@lut.fi work: +358-5-4125389 home: +358-40-5075560 | > | 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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 18 14:30:58 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9ILRQa11432 for ipng-dist; Mon, 18 Oct 1999 14:27:26 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9ILRLk11425 for ; Mon, 18 Oct 1999 14:27:21 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.1b+Sun/8.9.1) id OAA20829 for ipng@sunroof.eng.sun.com; Mon, 18 Oct 1999 14:25:03 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9IEIfk10107 for ; Mon, 18 Oct 1999 07:18:43 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA29332 for ; Mon, 18 Oct 1999 07:18:42 -0700 (PDT) Received: from monza.broadswitch.com (monza.broadswitch.se [195.178.164.73]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA22401 for ; Mon, 18 Oct 1999 08:18:40 -0600 (MDT) Received: by monza.broadswitch.com with Internet Mail Service (5.5.2448.0) id ; Mon, 18 Oct 1999 16:18:33 +0200 Message-ID: <45AFD48D077ED211BB4700A0C9DCE8FD15ACA0@monza.broadswitch.com> From: Thomas Eklund To: "'Jeff Williams'" , Brian E Carpenter Cc: ipng@sunroof.eng.sun.com Subject: RE: My InternetWeek op-ed column on IPv6 privacy issues Date: Mon, 18 Oct 1999 16:18:28 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="windows-1252" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Of course Brian is right... Mobile systems always need a fix point whre to reach the mobile user... In mobile IP we have a home address and in cellular systems you have an IMSI etc... And in the fixed Internet world you have a record in the DNS... Which means that to use the network you always need a fixed point and when you move you will get temporary addresses in order to route the traffic to the current point of attachment (if away from your home network). What makes IPv6 and in more particular mobileIPv6 more feasible than mobileIPv4 is that because you always get an addres locally via ND you wont have the problems in default as you have with private addresses in mobileIPv4!! So why not use the best tool available for mobile systems - IPv6!! I think that you should more see IPv6 as a tool where you have everything you want to build a scalable system and when you later define your applications to run over IPv6 you have the most things you want from start rather than sticking to IPv4 based solutions and keep patching the "half-ready tool" - IPv4. -- Thomas Eklund, SwitchCore > > Brian and all, > > Excuse me Brian, but why must those devices have permanent > IP addresses? As you know to do so creates a privacy problem > that is also as you know, addressable, pardon the pun. >;) > > Brian E Carpenter wrote: > > > Markku is on a good point. For the billion or so always-on wireless > > devices we will have on the net in a few years, permanent addresses > > are a must. > > > > Brian > > > > Markku Savela wrote: > > > > > > [I removed the long CC list] > > > > > > This discussion seems to lead to a situation where > IP-addresses are > > > never "permanent", just when I was hoping that IPv6 would > bring enough > > > addresses to use, so that I could have permanent > addresses for myself... > > > > > > This is a dilemma... > > > > > > - for some things I would like to use random (src) address > > > > > > - but, I still would like to have permantent address so > that my SMTP > > > daemon on mobile phone [:-)] can be contacted (or that it can > > > receive voice over IP calls). Or just that I can run > WEB server on > > > my home machine, to be more realistic. > > > > > > Is this another dimension to the source address selection > discussion? > > > > > > -- > > > Markku Savela (msa@hemuli.tte.vtt.fi), Technical Research > Centre of Finland > > > Multimedia Systems, P.O.Box 1203,FIN-02044 > VTT,http://www.vtt.fi/tte/staff/msa/ > > > > -------------------------------------------------------------------- > > > IETF IPng Working Group Mailing List > > > IPng Home 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 > > -------------------------------------------------------------------- > > Regards, > > -- > Jeffrey A. Williams > Spokesman INEGroup (Over 95k members strong!) > CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. > Information Network Eng. Group. INEG. INC. > E-Mail jwkckid1@ix.netcom.com > Contact Number: 972-447-1894 > Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 18 15:17:27 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9IMCTp11657 for ipng-dist; Mon, 18 Oct 1999 15:12:29 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.88.31]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9IMCIk11650 for ; Mon, 18 Oct 1999 15:12:18 -0700 (PDT) Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id PAA528663; Mon, 18 Oct 1999 15:11:54 -0700 (PDT) Date: Mon, 18 Oct 1999 15:11:53 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: deprecated source addresses To: Richard Draves Cc: "'IPng List'" In-Reply-To: "Your message with ID" <4D0A23B3F74DD111ACCD00805F31D81014515C4B@RED-MSG-50> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > 1. global destination. source A is deprecated site-local or global, source B > is preferred link-local. Choose A. > > 2. global destination. source A is deprecated site-local and source B is > deprecated link-local. Choose A. > > 3. site-local destination. source A is deprecated site-local or global, > source B is preferred global. Choose B. > > 4. link-local destination. source A is preferred site-local, source B is > preferred global. Choose A. > > So in light of the Tokyo discussion, who would like me to change this aspect > of the draft? Not me. The above look sfine. 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 18 18:41:17 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9J1bS511999 for ipng-dist; Mon, 18 Oct 1999 18:37:28 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9J1bHk11992 for ; Mon, 18 Oct 1999 18:37:19 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id SAA17737 for ; Mon, 18 Oct 1999 18:37:12 -0700 (PDT) Received: from sunthing.sjsinc.com (sunthing.sjsinc.com [38.149.204.34]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA13628 for ; Mon, 18 Oct 1999 19:37:11 -0600 (MDT) Received: from localhost (sjs@localhost) by sunthing.sjsinc.com (Take-a-guess/Take-a-guess) with ESMTP id VAA04702; Mon, 18 Oct 1999 21:36:56 -0400 (EDT) Date: Mon, 18 Oct 1999 21:36:55 -0400 (EDT) From: Stefan Jon Silverman To: Brian E Carpenter cc: ipng@sunroof.eng.sun.com Subject: Re: My InternetWeek op-ed column on IPv6 privacy issues In-Reply-To: <38074300.728ACB6C@hursley.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Folks: Well, sitting here at a bar typing via a secure pipe into my NYC machines from my laptop in San Francisco which has a wireless ricochet modem I would tend to agree..... From a security point of view I would like the ricochet device to have a permanent address so that I can limit the access lists on the NYC machines..... And no, this is not inebreated rambling, I have not yet finished my first drink. TRAVEL: At Scient SF as of 27th of Sept. -- Traveling often, no sched. yet Regards, b c++'ing u, %-) sjs ------------------------------------------------------------------------------- Weebles wobble, but they don't fall down!!! ------------------------------------------------------------------------------- Stefan Jon Silverman SJS Associates, N.A., Inc. 698 West End Avenue - Suite 15-B New York, NY 10025 E-mail: sjs@sjsinc.com Phone: 212 662 9450 Website: http://www.sjsinc.com Fax: 212 662 9461 Text-Page: sjs-page@sjsinc.com Cell: 917 929 1668 ------------------------------------------------------------------------------- In San Francisco Scient: 415 591 3973 ssilverman@scient.com (MD - Infrastructure Arch.) Home: 415 929 0406 sjs-sf@pacbell.net (1155 Jones, Apt. 303 - 94133) ------------------------------------------------------------------------------- On Fri, 15 Oct 1999, Brian E Carpenter wrote: > Markku is on a good point. For the billion or so always-on wireless > devices we will have on the net in a few years, permanent addresses > are a must. > > Brian > > Markku Savela wrote: > > > > [I removed the long CC list] > > > > This discussion seems to lead to a situation where IP-addresses are > > never "permanent", just when I was hoping that IPv6 would bring enough > > addresses to use, so that I could have permanent addresses for myself... > > > > This is a dilemma... > > > > - for some things I would like to use random (src) address > > > > - but, I still would like to have permantent address so that my SMTP > > daemon on mobile phone [:-)] can be contacted (or that it can > > receive voice over IP calls). Or just that I can run WEB server on > > my home machine, to be more realistic. > > > > Is this another dimension to the source address selection discussion? > > > > -- > > Markku Savela (msa@hemuli.tte.vtt.fi), Technical Research Centre of Finland > > Multimedia Systems, P.O.Box 1203,FIN-02044 VTT,http://www.vtt.fi/tte/staff/msa/ > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home 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 Mon Oct 18 21:45:16 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) id d9J4gVn12209 for ipng-dist; Mon, 18 Oct 1999 21:42:32 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta3+Sun/8.10.0.Beta3) with ESMTP id d9J4gLk12202 for ; Mon, 18 Oct 1999 21:42:23 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id VAA24346 for ; Mon, 18 Oct 1999 21:42:20 -0700 (PDT) Received: from jazz-1.trumpet.com.au (jazz-1.trumpet.com.au [203.5.119.62]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA20369 for ; Mon, 18 Oct 1999 21:42:19 -0700 (PDT) Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id PAA13832; Tue, 19 Oct 1999 15:42:02 +1100 (EST) Date: Tue, 19 Oct 1999 15:42:02 +1100 (EST) From: Peter Tattam To: "Michael H. Warfield" cc: Ville Nummela , ipng@sunroof.eng.sun.com Subject: Re: My InternetWeek op-ed column on IPv6 privacy issues In-Reply-To: <19991018105254.B1606@alcove.wittsend.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk One could then ask following question... If there is a true need and sufficient demand for anonymizer services, then would it be a flourishing business model? An anonymizer at to the connection level would imply to me some kind of NAT or firewall. In keeping with the charter of this mailing list, I would have to say that Ipv6 can only be a step forward in this whole debate in that it offers more solutions for user control over anonymity of IPv6 addresses (well the lower 64 bits at least) in the absence of anonymizer services. I could say much more on the issue, but it is getting too far out of the charter of this list. Peter -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 19 04:06:28 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta4+Sun/8.10.0.Beta4) id d9JB3om13441 for ipng-dist; Tue, 19 Oct 1999 04:03:50 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta4+Sun/8.10.0.Beta4) with ESMTP id d9JB3fQ13434 for ; Tue, 19 Oct 1999 04:03:41 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id EAA05863 for ; Tue, 19 Oct 1999 04:03:34 -0700 (PDT) Received: from ygmail.kt.co.kr (ygmail_kt.kotel.co.kr [147.6.3.33]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA06917 for ; Tue, 19 Oct 1999 04:03:29 -0700 (PDT) Received: from kt.co.kr ([147.6.65.78]) by ygmail.kt.co.kr (8.8.8/8.8.8) with ESMTP id UAA27151; Tue, 19 Oct 1999 20:07:44 +0900 (KST) Message-ID: <380C5199.13B5D0C4@kt.co.kr> Date: Tue, 19 Oct 1999 20:10:17 +0900 From: ksb Reply-To: ksbn@kt.co.kr Organization: Korea Telecom X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: huitema@research.telcordia.com CC: "6Bone(Int)" <6bone@isi.edu>, IETF ipng , 6Bone-KR <6bone-kr@6bone.ne.kr> Subject: RSIP(Realm Specific IP) Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear huitema, I read your presentation at IPv6 Forum. You said that RSIP is good for IPv6 evolution. I can't find the difference between NAT/NAPT and RSIP conceptually. Will you explain about it? Is RSIP good for ISP? Thank you. Sahng-Beom Kim -- Kim, Sahng-Beom / Korea Telecom TEL : +82-42-870-8322 FAX : +82-42-870-8329 E-mail : ksbn@kt.co.kr -- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 19 05:23:33 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta4+Sun/8.10.0.Beta4) id d9JCL4M13506 for ipng-dist; Tue, 19 Oct 1999 05:21:04 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta4+Sun/8.10.0.Beta4) with ESMTP id d9JCKsQ13499 for ; Tue, 19 Oct 1999 05:20:55 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id FAA27508 for ; Tue, 19 Oct 1999 05:20:53 -0700 (PDT) Received: from qn-lpr1-104.quicknet.inet.fi (qn-lpr1-104.quicknet.inet.fi [194.251.105.104]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id GAA24050 for ; Tue, 19 Oct 1999 06:20:52 -0600 (MDT) Received: from lut.fi(localhost[127.0.0.1]) (5517 bytes) by qn-lpr1-104.quicknet.inet.fi via sendmail with P:esmtp/R:bind_hosts/T:inet_zone_bind_smtp (sender: ) id for ; Tue, 19 Oct 1999 15:18:51 +0300 (EET DST) (Smail-3.2.0.106 1999-Mar-31 #3 built DST-Apr-19) Message-ID: <380C6193.ECFAF0CC@lut.fi> Date: Tue, 19 Oct 1999 15:18:27 +0300 From: Ville Nummela X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.12 i586) X-Accept-Language: en MIME-Version: 1.0 To: Peter Tattam CC: "Michael H. Warfield" , ipng@sunroof.eng.sun.com Subject: Re: My InternetWeek op-ed column on IPv6 privacy issues References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by sunroof.eng.sun.com id d9JCKtQ13500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Peter Tattam wrote: > One could then ask following question... > > If there is a true need and sufficient demand for anonymizer services, then > would it be a flourishing business model? An anonymizer at to the connection > level would imply to me some kind of NAT or firewall. > > In keeping with the charter of this mailing list, I would have to say that Ipv6 > can only be a step forward in this whole debate in that it offers more > solutions for user control over anonymity of IPv6 addresses (well the lower 64 > bits at least) in the absence of anonymizer services. I think this discussion is moving towards the right direction; The original problem as described in the column mentioned on the subject line is about using Ethernet MAC addresses as a part of IPv6 addresses. Since this is optional (although the "default") behaviour this isn't really a problem. But then we get to a more generic kind of privacy problem: A static IP -address can always be (easily) traced to a certain human being (or at least to a certain group). Now lot's of people wrote some kind of response to my telephone -analogy. Some of them wrote about tapped wires. "Yikes, people can listen to my conversations" - is that really so bad? I mean, how many of you really thinks there is someone listening your personal calls? None, except criminals and terrorists I think. "Ordinary" people don't have any chance of listening to anyones phone conversation any way, and the same goes to encrypted data transfers over Internet. Another kind of an response was this Caller ID -thing; Almost everyone thought it was generally a bad thing. Well, at least I like to know who's calling me before I answer the phone. An the phone system at least here in Finland has a way of disabling Caller ID on per call basis. Then again, I have the choice of not answering a call if I can't see the number. Ok, let me now try to take this issue back to IPv6 and to explain my point.. I think that the way IPv6 is getting on now is quite good. Too much privacy only makes things worse. Consider a site (a website or something else, a bank perhaps). Now let's assume for a second that in IPv6 every address would be totally random, totally private and no-one knew no-one elses address.. In comes Mad Cracker, who tries to break in to the banks computers. As he proceeds trying different hacks and perhaps finally if he can't get in he decides to DoS the site by flooding it with packets. Using 1000 different random addresses which he changes every other second. And the operator of the site can't do a thing. On the IPv4 world he could have traced the first attacks when he tried to get in to some computer etc.. but this "wrong kind of" IP architecture renders it impossible. Now let's think another second. If this "random way" isn't the only possibility of obtaining addresses (in the IPv6 world there should be enough addresses so that everyone can get a static address also), the site maintainer can require the hosts connecting to the site to use a certain IP address. e.g. use a firewall which only lets through packets from certain addresses. This is quite much the way IPv6 is now. So, my point is that IPv6 is getting along quite fine and there isn't really any reason for this big fuzz about this so-called "privacy issue". -- | vnummela@lut.fi work: +358-5-4125389 home: +358-40-5075560 | | 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 Tue Oct 19 07:46:19 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta4+Sun/8.10.0.Beta4) id d9JEhgt13605 for ipng-dist; Tue, 19 Oct 1999 07:43:42 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta4+Sun/8.10.0.Beta4) with ESMTP id d9JEhVQ13598 for ; Tue, 19 Oct 1999 07:43:33 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA28282 for ; Tue, 19 Oct 1999 07:43:32 -0700 (PDT) Received: from infobro.com (ns.infobro.com [204.255.254.70]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id IAA06562 for ; Tue, 19 Oct 1999 08:43:31 -0600 (MDT) Received: from red (unverified [205.161.100.60]) by infobro.com (EMWAC SMTPRS 0.83) with SMTP id ; Tue, 19 Oct 1999 10:43:20 -0400 Received: by localhost with Microsoft MAPI; Tue, 19 Oct 1999 10:43:12 -0400 Message-ID: <01BF1A1E.BD92AA70.eric@infobro.com> From: "Eric D. Williams" To: "ipng@sunroof.eng.sun.com" Cc: "'Ville Nummela'" Subject: RE: My InternetWeek op-ed column on IPv6 privacy issues Date: Tue, 19 Oct 1999 10:42:55 -0400 Organization: Information Brokers, Inc. X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ville and all, Use of Randomness in DoS attacks ---------------------------- I agree with your point on DoS where random addresses could cause a big problem for the system administrator at the attacked site, although the current draft: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-addrconf-privacy-00.txt proposes setting bit 6 for local significance ONLY: Take the left-most 64-bits of the MD5 digest and set bit 6 (the left-most bit is numbered 0) to zero. This creates an interface identifier with the universal/local bit indicating local significance only. Use the resultant identifier for generating addresses as outlined in [ADDRCONF]. That is, use the interface identifier to generate a link-local and other appropriate addresses. Thus the addresses generated (using a "compliant" implementation) would be easily blocked by honing in on the link prefix [RFC2462] subnet prefix [RFC2373] of the attack blocking it and shutting down the attack. Discussion Context --------------------- IMHO, CALLER-ID is not the same type of situation because it only allows you to track (correlate) on phone numbers that you receive, on systems you control, thus an abstraction of calling patterns by the originating phone number would require extraordinary measures (certainly the Telcos can and do capture caller logs, but the point is moot I agree). I am merely stating the privacy concern is with the called party correlating usage patterns across multiple sites, of course in the above stated proposal and in Steve & Bob's discussion at: http://playground.sun.com/ipng the option for random generation serves to 'disable' the 'CALLER-ID' additionally the static addressing scheme is most appropriately used for 'servers' in the system and not 'clients' (usually the initiators of 'calls'). Given the context of the discussion my suggestion concerning proper venue relates to appropriateness of discussions concerning privacy of user usage patterns in the IPng group, IMHO it is outside the scope of the charter to attempt to address web site operator abstractions of user usage patterns. I don't believe the "high level" concern here is with the nuts-and-bolts but rather with web site user privacy. See Keith Moore's draft: http://www.ietf.org/internet-drafts/draft-iesg-serno-privacy-00.txt section two, which IMHO clearly describes the concern as: 2. Risks of Exposing Hardware Serial Numbers When a hardware serial number is associated with a particular host, the number may be used to track network-based activity of that host. Such tracking may be done by communication among the parties with which the host communicates, or by eavesdroppers who can observe the host's traffic. (even while encrypted the source and destination addresses would be exposed so this 'usage tracking' could still occur). Suggestion --------- Given the current state of privacy legislation here (USA) the concern is more for the end-users privacy than with the configuration of addresses or any such low-level operations, read this as "Where is the concern with static IPv4 addresses and properly mapped DNS entries?" so IMHO any further discussion should be covered by the run-wg http://www.ietf.org/html.charters/run-charter.html at least this would give it the proper context. In conclusion let me say, with a great deal of enthusiasm, that I agree with you. IPv6 is moving along in the right direction, and the so-called privacy concern is wholly blown-out-of-proportion. Eric Eric Williams, Pres. Information Brokers, Inc. Phone: +1 202.889.4395 http://www.infobro.com/ Fax: +1 202.889.4396 mailto:eric@infobro.com Pager: +1 301.303.8998 For More Info: info@infobro.com On Tuesday, October 19, 1999 8:18 AM, Ville Nummela [SMTP:vnummela@lut.fi] wrote: > Peter Tattam wrote: > > > One could then ask following question... > > > > If there is a true need and sufficient demand for anonymizer services, then > > would it be a flourishing business model? An anonymizer at to the > > connection > > level would imply to me some kind of NAT or firewall. > > > > In keeping with the charter of this mailing list, I would have to say that > > Ipv6 > > can only be a step forward in this whole debate in that it offers more > > solutions for user control over anonymity of IPv6 addresses (well the lower > > 64 > > bits at least) in the absence of anonymizer services. > > I think this discussion is moving towards the right direction; > > The original problem as described in the column mentioned on the subject line > is > about using Ethernet MAC addresses as a part of IPv6 addresses. Since this is > optional (although the "default") behaviour this isn't really a problem. But > then > we get to a more generic kind of privacy problem: > > A static IP -address can always be (easily) traced to a certain human being > (or at > least to a certain group). > > Now lot's of people wrote some kind of response to my telephone -analogy. > Some of > them wrote about tapped wires. "Yikes, people can listen to my > conversations" - is > that really so bad? I mean, how many of you really thinks there is someone > listening your personal calls? None, except criminals and terrorists I think. > "Ordinary" people don't have any chance of listening to anyones phone > conversation > any way, and the same goes to encrypted data transfers over Internet. > > Another kind of an response was this Caller ID -thing; Almost everyone thought > it > was generally a bad thing. Well, at least I like to know who's calling me > before I > answer the phone. An the phone system at least here in Finland has a way of > disabling Caller ID on per call basis. Then again, I have the choice of not > answering a call if I can't see the number. > > Ok, let me now try to take this issue back to IPv6 and to explain my point.. > > I think that the way IPv6 is getting on now is quite good. Too much privacy > only > makes things worse. Consider a site (a website or something else, a bank > perhaps). > Now let's assume for a second that in IPv6 every address would be totally > random, > totally private and no-one knew no-one elses address.. In comes Mad Cracker, > who > tries to break in to the banks computers. As he proceeds trying different > hacks > and perhaps finally if he can't get in he decides to DoS the site by flooding > it > with packets. Using 1000 different random addresses which he changes every > other > second. And the operator of the site can't do a thing. On the IPv4 world he > could > have traced the first attacks when he tried to get in to some computer etc.. > but > this "wrong kind of" IP architecture renders it impossible. > > Now let's think another second. If this "random way" isn't the only > possibility of > obtaining addresses (in the IPv6 world there should be enough addresses so > that > everyone can get a static address also), the site maintainer can require the > hosts > connecting to the site to use a certain IP address. e.g. use a firewall which > only > lets through packets from certain addresses. This is quite much the way IPv6 > is > now. > > So, my point is that IPv6 is getting along quite fine and there isn't really > any > reason for this big fuzz about this so-called "privacy issue". > > > -- > | vnummela@lut.fi work: +358-5-4125389 home: +358-40-5075560 | > | 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 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 19 08:48:31 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta4+Sun/8.10.0.Beta4) id d9JFjlT13768 for ipng-dist; Tue, 19 Oct 1999 08:45:47 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta4+Sun/8.10.0.Beta4) with ESMTP id d9JFjbQ13761 for ; Tue, 19 Oct 1999 08:45:38 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA15411 for ; Tue, 19 Oct 1999 08:45:37 -0700 (PDT) Received: from dfw-ix4.ix.netcom.com (dfw-ix4.ix.netcom.com [206.214.98.4]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA07895 for ; Tue, 19 Oct 1999 08:45:30 -0700 (PDT) Received: (from smap@localhost) by dfw-ix4.ix.netcom.com (8.8.4/8.8.4) id KAA23498; Tue, 19 Oct 1999 10:43:10 -0500 (CDT) Received: from dal-tx2-24.ix.netcom.com(207.94.120.152) by dfw-ix4.ix.netcom.com via smap (V1.3) id rma023076; Tue Oct 19 10:41:35 1999 Message-ID: <380C20B7.32A2442D@ix.netcom.com> Date: Tue, 19 Oct 1999 08:41:45 +0100 From: Jeff Williams Organization: INEG. Inc. (Spokesman INEGroup) X-Mailer: Mozilla 4.08 [en] (Win16; I) MIME-Version: 1.0 To: Ville Nummela CC: Peter Tattam , "Michael H. Warfield" , ipng@sunroof.eng.sun.com Subject: Re: My InternetWeek op-ed column on IPv6 privacy issues References: <380C6193.ECFAF0CC@lut.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ville and all, Ville Nummela wrote: > Peter Tattam wrote: > > > One could then ask following question... > > > > If there is a true need and sufficient demand for anonymizer services, then > > would it be a flourishing business model? An anonymizer at to the connection > > level would imply to me some kind of NAT or firewall. > > > > In keeping with the charter of this mailing list, I would have to say that Ipv6 > > can only be a step forward in this whole debate in that it offers more > > solutions for user control over anonymity of IPv6 addresses (well the lower 64 > > bits at least) in the absence of anonymizer services. > > I think this discussion is moving towards the right direction; > > The original problem as described in the column mentioned on the subject line is > about using Ethernet MAC addresses as a part of IPv6 addresses. Since this is > optional (although the "default") behaviour this isn't really a problem. But then > we get to a more generic kind of privacy problem: The real problem is that this is the DEFAULT. That's backwards. > > > A static IP -address can always be (easily) traced to a certain human being (or at > least to a certain group). Exactly right. Though with IPSEC, this can be somewhat protected. > > > Now lot's of people wrote some kind of response to my telephone -analogy. Some of > them wrote about tapped wires. "Yikes, people can listen to my conversations" - is > that really so bad? Yes this is "Really so bad"! > I mean, how many of you really thinks there is someone > listening your personal calls? None, except criminals and terrorists I think. Likely none, this is true. But without some sort of protections, which I employ on my phone line, you never know. Take Monica Lewinski for instance. Look at the trouble that has caused, and mostly unnecessarily I might add as well. > > "Ordinary" people don't have any chance of listening to anyones phone conversation > any way, and the same goes to encrypted data transfers over Internet. Yes the same goes for "Encrypted Data Transfers". But that is no what we are talking about, is it? We are talking about the DEFAULT autoconfig for IPv6, and NO Encryption as well. Hence this argument is not valid on those two basses. > > > Another kind of an response was this Caller ID -thing; Almost everyone thought it > was generally a bad thing. Well, at least I like to know who's calling me before I > answer the phone. An the phone system at least here in Finland has a way of > disabling Caller ID on per call basis. Then again, I have the choice of not > answering a call if I can't see the number. Right, and this is a good thing. > > > Ok, let me now try to take this issue back to IPv6 and to explain my point.. > > I think that the way IPv6 is getting on now is quite good. Too much privacy only > makes things worse. You can never have "Too Much Privacy". That is an absolute, IMHO. And many people are going to see IPv6 as not allowing for enough Privacy should the spec remain "As is". > Consider a site (a website or something else, a bank perhaps). > Now let's assume for a second that in IPv6 every address would be totally random, > totally private and no-one knew no-one elses address.. In comes Mad Cracker, who > tries to break in to the banks computers. As he proceeds trying different hacks > and perhaps finally if he can't get in he decides to DoS the site by flooding it > with packets. Using 1000 different random addresses which he changes every other > second. And the operator of the site can't do a thing. The problem with this scenario is that the operator can stop a DoS attack with several other methods, besides the bank using a static address. This scenario doesn't even make allot of sense from the banks point of view. > On the IPv4 world he could > have traced the first attacks when he tried to get in to some computer etc.. but > this "wrong kind of" IP architecture renders it impossible. How??? > > > Now let's think another second. If this "random way" isn't the only possibility of > obtaining addresses (in the IPv6 world there should be enough addresses so that > everyone can get a static address also), the site maintainer can require the hosts > connecting to the site to use a certain IP address. e.g. use a firewall which only > lets through packets from certain addresses. This is quite much the way IPv6 is > now. Having this as a "Option" as part of the IPv6 spec for autoconfig would be expectable, but not as the Default. > > > So, my point is that IPv6 is getting along quite fine and there isn't really any > reason for this big fuzz about this so-called "privacy issue". Well given your arguments, I am sure you DO fell this way. However your premise are not valid, so your argument is therefore not logical and therefore not proving you point. > > > -- > | vnummela@lut.fi work: +358-5-4125389 home: +358-40-5075560 | > | 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 > -------------------------------------------------------------------- Regards, -- Jeffrey A. Williams Spokesman INEGroup (Over 95k members strong!) CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 972-447-1894 Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 19 09:55:07 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta4+Sun/8.10.0.Beta4) id d9JGrL413900 for ipng-dist; Tue, 19 Oct 1999 09:53:21 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta4+Sun/8.10.0.Beta4) with ESMTP id d9JGr7Q13893 for ; Tue, 19 Oct 1999 09:53:07 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA19571 for ; Tue, 19 Oct 1999 09:53:06 -0700 (PDT) Received: from qn-lpr1-104.quicknet.inet.fi (qn-lpr1-104.quicknet.inet.fi [194.251.105.104]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id KAA01771 for ; Tue, 19 Oct 1999 10:53:01 -0600 (MDT) Received: from lut.fi(localhost[127.0.0.1]) (5650 bytes) by qn-lpr1-104.quicknet.inet.fi via sendmail with P:esmtp/R:bind_hosts/T:inet_zone_bind_smtp (sender: ) id for ; Tue, 19 Oct 1999 19:50:40 +0300 (EET DST) (Smail-3.2.0.106 1999-Mar-31 #3 built DST-Apr-19) Message-ID: <380CA153.42EF8A39@lut.fi> Date: Tue, 19 Oct 1999 19:50:27 +0300 From: Ville Nummela X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.12 i586) X-Accept-Language: en MIME-Version: 1.0 To: Jeff Williams CC: Peter Tattam , "Michael H. Warfield" , ipng@sunroof.eng.sun.com Subject: Re: My InternetWeek op-ed column on IPv6 privacy issues References: <380C6193.ECFAF0CC@lut.fi> <380C20B7.32A2442D@ix.netcom.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by sunroof.eng.sun.com id d9JGr8Q13894 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jeff Williams wrote: > > "Ordinary" people don't have any chance of listening to anyones phone conversation > > any way, and the same goes to encrypted data transfers over Internet. > > Yes the same goes for "Encrypted Data Transfers". But that is no what > we are talking about, is it? We are talking about the DEFAULT autoconfig > for IPv6, and NO Encryption as well. Hence this argument is not valid > on those two basses. Why? You admit that it's possible for everyone to acquire the privacy if they want it. Does the IPv6 really have to PUSH privacy to people? I don't think that's the main function of IPv6. Even though these privacy issues are things that have to be looked into, and they already have. > > Consider a site (a website or something else, a bank perhaps). > > Now let's assume for a second that in IPv6 every address would be totally random, > > totally private and no-one knew no-one elses address.. In comes Mad Cracker, who > > tries to break in to the banks computers. As he proceeds trying different hacks > > and perhaps finally if he can't get in he decides to DoS the site by flooding it > > with packets. Using 1000 different random addresses which he changes every other > > second. And the operator of the site can't do a thing. > > The problem with this scenario is that the operator can stop a DoS > attack with several other methods, besides the bank using a static address. > This scenario doesn't even make allot of sense from the banks point of view. Well, the reason this scenario doesn't make sence to you is probably that it is not the case with current IP architectures (IPv4 or IPv6). As stated by other people in this mailing list, IPv6 doesn't allow totally random addresses.. (now there's another issue of IP spoofing but that's another story.. :-) > > On the IPv4 world he could > > have traced the first attacks when he tried to get in to some computer etc.. but > > this "wrong kind of" IP architecture renders it impossible. > How??? Ok, I'll try to explain it "the hard way". If we had totally random IP addressses (note: This is NOT the case with IPv6 and would be even rather impossible to implement since every address would have to be on every routing table of every router.. and they would have to be changed when the address would change) there would be no way for the target system to separate the legitimate connections from those generated by the attacker. The attacker could easily hog the resources of the server to the point the server becomes not usable for it's legitimate users. Now with IPv6 we can still filter the attackers packets on the firewall; they all share the same network address. Therefore this whole example is totally nonsense, as you said ;-) I was just trying to exaggarate a little so that I could make my point more clear.. > > So, my point is that IPv6 is getting along quite fine and there isn't really any > > reason for this big fuzz about this so-called "privacy issue". > Well given your arguments, I am sure you DO fell this way. However > your premise are not valid, so your argument is therefore not logical and > therefore not proving you point. I think bigger problem is that my English language isn't that good.. It's rather hard trying to explain something when you have to use a dictionary.. :-P -- | vnummela@lut.fi work: +358-5-4125389 home: +358-40-5075560 | | 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 Tue Oct 19 09:55:16 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta4+Sun/8.10.0.Beta4) id d9JGpr213884 for ipng-dist; Tue, 19 Oct 1999 09:51:53 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta4+Sun/8.10.0.Beta4) with ESMTP id d9JGphQ13875 for ; Tue, 19 Oct 1999 09:51:44 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA19285 for ; Tue, 19 Oct 1999 09:51:42 -0700 (PDT) Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA01055 for ; Tue, 19 Oct 1999 10:51:40 -0600 (MDT) Received: from fmsmsx27.FM.INTEL.COM (fmsmsx27.fm.intel.com [132.233.42.27]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.9 1999/10/15 23:57:06 lcm Exp $) with ESMTP id MAA00502; Tue, 19 Oct 1999 12:51:52 GMT Received: by fmsmsx27.fm.intel.com with Internet Mail Service (5.5.2448.0) id <4Y441NKK>; Tue, 19 Oct 1999 09:51:19 -0700 Message-ID: <0428AD6295E1D211AC4400A0C969E8A2016013B6@orsmsx43.jf.intel.com> From: "Tang, Tom J" To: "'ksbn@kt.co.kr'" , huitema@research.telcordia.com Cc: "6Bone(Int)" <6bone@isi.edu>, IETF ipng , 6Bone-KR <6bone-kr@6bone.ne.kr> Subject: RE: RSIP(Realm Specific IP) Date: Tue, 19 Oct 1999 09:51:17 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="KS_C_5601-1987" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Sahng-Beom : One thing is that NAT/NAPT has problems when you run IPSec since ports,IP cannot be modified. Using RSIP, the server would assign the client resources from the external routing realm such that the client could use those resources to authenticate the packet. I don't know if this is good for ISPs but in my opinion that is the most compelling reason for running RSIP instead of NAT/NAPT. That's the short version... but one should get the idea. --------------------------------------------------------------- Tom J. Tang Telephone : (503) 712-1791 Network Software Engineer Office Fax : (503) 264-3843 Intel Architecture Labs Email : tom.j.tang@intel.com Internet Security Group Disclaimer : Any views expressed within belong to the author and is not endorsed by my employer. -------------------------------------------------------------- -----Original Message----- From: ksb [mailto:ksbn@kt.co.kr] Sent: Tuesday, October 19, 1999 4:10 AM To: huitema@research.telcordia.com Cc: 6Bone(Int); IETF ipng; 6Bone-KR Subject: RSIP(Realm Specific IP) Dear huitema, I read your presentation at IPv6 Forum. You said that RSIP is good for IPv6 evolution. I can't find the difference between NAT/NAPT and RSIP conceptually. Will you explain about it? Is RSIP good for ISP? Thank you. Sahng-Beom Kim -- Kim, Sahng-Beom / Korea Telecom TEL : +82-42-870-8322 FAX : +82-42-870-8329 E-mail : ksbn@kt.co.kr -- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Oct 19 09:55:33 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta4+Sun/8.10.0.Beta4) id d9JGpv713891 for ipng-dist; Tue, 19 Oct 1999 09:51:58 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.0.Beta4+Sun/8.10.0.Beta4) with ESMTP id d9JGpqQ13883 for ; Tue, 19 Oct 1999 09:51:52 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.1b+Sun/8.9.1) id JAA21660 for ipng@sunroof.eng.sun.com; Tue, 19 Oct 1999 09:49:32 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta4+Sun/8.10.0.Beta4) with ESMTP id d9JFvcQ13801 for ; Tue, 19 Oct 1999 08:57:40 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA08524 for ; Tue, 19 Oct 1999 08:57:38 -0700 (PDT) Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA14752 for ; Tue, 19 Oct 1999 08:57:37 -0700 (PDT) Received: from mailee.research.telcordia.com (mailee [192.4.7.23]) by thumper.research.telcordia.com (8.9.3/8.9.1) with ESMTP id LAA17910; Tue, 19 Oct 1999 11:56:39 -0400 (EDT) Received: from seascape.bellcore.com (pptpdhcp25.research.telcordia.com [192.4.9.250]) by mailee.research.telcordia.com (8.8.8/8.8.8) with SMTP id LAA07346; Tue, 19 Oct 1999 11:56:31 -0400 (EDT) Message-Id: <4.1.19991019114953.009d6d70@mailee.research.telcordia.com> X-Sender: huitema@mailee.research.telcordia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 19 Oct 1999 11:54:28 -0400 To: ksbn@kt.co.kr From: Christian Huitema Subject: Re: RSIP(Realm Specific IP) Cc: "6Bone(Int)" <6bone@isi.edu>, ipng , 6Bone-KR <6bone-kr@6bone.ne.kr> In-Reply-To: <380C5199.13B5D0C4@kt.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 08:10 PM 10/19/99 +0900, ksb wrote: >Dear huitema, > >I read your presentation at IPv6 Forum. >You said that RSIP is good for IPv6 evolution. >I can't find the difference between NAT/NAPT and RSIP >conceptually. What I said was that RSIP is an evolution of the NAT technology that tries to alleviate some of the NAT problems, such as the impossibility to dynamically open listening sockets behind a NAT, or the impossibility to let IPSEC cross a NAT. However, implementing RSIP requires a new stack in the host, and thus has the same deployment problems as IPv6. This implies that a v4-to-v4 RSIP/NAT solution is not easier to deploy than a v6-to-v4 solution. On the other hand, the basic idea of RSIP, interacting with the translation box in order to ensure transparency, is a good idea that should be somehow implemented in the IPv6 transition. -- Christian Huitema -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 19 10:27:22 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta4+Sun/8.10.0.Beta4) id d9JHNlR14002 for ipng-dist; Tue, 19 Oct 1999 10:23:47 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta4+Sun/8.10.0.Beta4) with ESMTP id d9JHNbQ13995 for ; Tue, 19 Oct 1999 10:23:38 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA00671 for ; Tue, 19 Oct 1999 10:23:37 -0700 (PDT) Received: from dfw-ix8.ix.netcom.com (dfw-ix8.ix.netcom.com [206.214.98.8]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA16253 for ; Tue, 19 Oct 1999 11:23:36 -0600 (MDT) Received: (from smap@localhost) by dfw-ix8.ix.netcom.com (8.8.4/8.8.4) id MAA00007; Tue, 19 Oct 1999 12:21:41 -0500 (CDT) Received: from dal-tx50-47.ix.netcom.com(198.211.45.239) by dfw-ix8.ix.netcom.com via smap (V1.3) id rma029971; Tue Oct 19 12:21:22 1999 Message-ID: <380C381C.8860A6EE@ix.netcom.com> Date: Tue, 19 Oct 1999 10:21:34 +0100 From: Jeff Williams Organization: INEG. Inc. (Spokesman INEGroup) X-Mailer: Mozilla 4.08 [en] (Win16; I) MIME-Version: 1.0 To: Ville Nummela CC: Peter Tattam , "Michael H. Warfield" , ipng@sunroof.eng.sun.com Subject: Re: My InternetWeek op-ed column on IPv6 privacy issues References: <380C6193.ECFAF0CC@lut.fi> <380C20B7.32A2442D@ix.netcom.com> <380CA153.42EF8A39@lut.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ville and all, Ville Nummela wrote: > Jeff Williams wrote: > > > > "Ordinary" people don't have any chance of listening to anyones phone conversation > > > any way, and the same goes to encrypted data transfers over Internet. > > > > Yes the same goes for "Encrypted Data Transfers". But that is no what > > we are talking about, is it? We are talking about the DEFAULT autoconfig > > for IPv6, and NO Encryption as well. Hence this argument is not valid > > on those two basses. > > Why? You admit that it's possible for everyone to acquire the privacy if they want it. > Does the IPv6 really have to PUSH privacy to people? I am not suggesting that the IPv6 spec push anything. I am suggesting, however that the spec need some significant revision with respect to autoconfig for the purposes of privacy. That's all. > I don't think that's the main > function of IPv6. Even though these privacy issues are things that have to be looked > into, and they already have. "Looked into" is not good enough. The MUST be addressed in a satisfactory manner. > > > > > Consider a site (a website or something else, a bank perhaps). > > > Now let's assume for a second that in IPv6 every address would be totally random, > > > totally private and no-one knew no-one elses address.. In comes Mad Cracker, who > > > tries to break in to the banks computers. As he proceeds trying different hacks > > > and perhaps finally if he can't get in he decides to DoS the site by flooding it > > > with packets. Using 1000 different random addresses which he changes every other > > > second. And the operator of the site can't do a thing. > > > > The problem with this scenario is that the operator can stop a DoS > > attack with several other methods, besides the bank using a static address. > > This scenario doesn't even make allot of sense from the banks point of view. > > Well, the reason this scenario doesn't make sence to you is probably that it is not the > case with current IP architectures (IPv4 or IPv6). As stated by other people in this > mailing list, IPv6 doesn't allow totally random addresses.. (now there's another issue > of IP spoofing but that's another story.. :-) I am not suggesting totally random addressing, but I am suggesting that some random addressing become the default. That can be achieved, and should be as part of the default autoconfig. > > > > > On the IPv4 world he could > > > have traced the first attacks when he tried to get in to some computer etc.. but > > > this "wrong kind of" IP architecture renders it impossible. > > > How??? > > Ok, I'll try to explain it "the hard way". If we had totally random IP addressses > (note: This is NOT the case with IPv6 and would be even rather impossible to implement > since every address would have to be on every routing table of every router.. and they > would have to be changed when the address would change) there would be no way for the > target system to separate the legitimate connections from those generated by the > attacker. The attacker could easily hog the resources of the server to the point the > server becomes not usable for it's legitimate users. > Now with IPv6 we can still filter the attackers packets on the firewall; they all share > the same network address. Therefore this whole example is totally nonsense, as you said > ;-) I was just trying to exaggarate a little so that I could make my point more clear.. LOL! Well you did a good job of exaggerating in your example. >;) > > > > > So, my point is that IPv6 is getting along quite fine and there isn't really any > > > reason for this big fuzz about this so-called "privacy issue". > > Well given your arguments, I am sure you DO fell this way. However > > your premise are not valid, so your argument is therefore not logical and > > therefore not proving you point. > > I think bigger problem is that my English language isn't that good.. It's rather hard > trying to explain something when you have to use a dictionary.. :-P Well my french is not all that good either. But I thought you did ok on your english. It is just that your arguments don't hold or are not valid. > > > -- > | vnummela@lut.fi work: +358-5-4125389 home: +358-40-5075560 | > | IRC naturae alienum est! Periculosum est! Delendum est! | Regards, -- Jeffrey A. Williams Spokesman INEGroup (Over 95k members strong!) CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 972-447-1894 Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 20 00:12:07 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta4+Sun/8.10.0.Beta4) id d9K79UG14831 for ipng-dist; Wed, 20 Oct 1999 00:09:30 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta4+Sun/8.10.0.Beta4) with ESMTP id d9K79JQ14824 for ; Wed, 20 Oct 1999 00:09:20 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id AAA25886 for ; Wed, 20 Oct 1999 00:09:20 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA04470 for ; Wed, 20 Oct 1999 01:09:18 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id JAA23285; Wed, 20 Oct 1999 09:08:32 +0200 Received: from valis (valis.rennes.enst-bretagne.fr [193.52.74.87]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with SMTP id JAA00173; Wed, 20 Oct 1999 09:08:31 +0200 (MET DST) Received: by localhost with Microsoft MAPI; Wed, 20 Oct 1999 09:07:28 +0200 Message-ID: <01BF1ADA.887AB8C0.Laurent.Toutain@enst-bretagne.fr> From: Laurent Toutain To: "'Christian Huitema'" , "ksbn@kt.co.kr" , "Jim Bound (Adresse de messagerie)" Cc: "6Bone(Int)" <6bone@isi.edu>, ipng , 6Bone-KR <6bone-kr@6bone.ne.kr> Subject: RE: RSIP(Realm Specific IP) Date: Wed, 20 Oct 1999 09:07:27 +0200 X-Mailer: Messagerie Internet de Microsoft/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk We proposed with Jim Bound in the ngtrans group a transition mechanism called DSTM (Dual Stack Transition Mechanism). It is, in a way, similar to RSIP. We allocate a temporary IPv4 address to IPv6 hosts and we tunnel IPv4 packet into IPv6 packet. The tunnel end point is a router at the border between IPv6 and IPv4 only network. This allow part of a network to move to IPv6, the rest can stay in IPv4. The main difference with RSIP is that IPv4 applications don't have to be recompiled to deal with DSTM. Laurent > -----Original Message----- > From: Christian Huitema [SMTP:huitema@research.telcordia.com] > Sent: Tuesday, October 19, 1999 5:54 PM > To: ksbn@kt.co.kr > Cc: 6Bone(Int); ipng; 6Bone-KR > Subject: Re: RSIP(Realm Specific IP) > > At 08:10 PM 10/19/99 +0900, ksb wrote: > >Dear huitema, > > > >I read your presentation at IPv6 Forum. > >You said that RSIP is good for IPv6 evolution. > >I can't find the difference between NAT/NAPT and RSIP > >conceptually. > > What I said was that RSIP is an evolution of the NAT technology that tries > to alleviate some of the NAT problems, such as the impossibility to > dynamically open listening sockets behind a NAT, or the impossibility to > let IPSEC cross a NAT. However, implementing RSIP requires a new stack in > the host, and thus has the same deployment problems as IPv6. This implies > that a v4-to-v4 RSIP/NAT solution is not easier to deploy than a v6-to-v4 > solution. On the other hand, the basic idea of RSIP, interacting with the > translation box in order to ensure transparency, is a good idea that should > be somehow implemented in the IPv6 transition. > -- Christian Huitema > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 20 01:51:37 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta4+Sun/8.10.0.Beta4) id d9K8n6h14911 for ipng-dist; Wed, 20 Oct 1999 01:49:06 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta4+Sun/8.10.0.Beta4) with ESMTP id d9K8muQ14904 for ; Wed, 20 Oct 1999 01:48:57 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id BAA28766 for ; Wed, 20 Oct 1999 01:48:54 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA23625 for ; Wed, 20 Oct 1999 01:48:52 -0700 (PDT) Received: from localhost ([3ffe:501:100f:1048:2a0:24ff:fe66:1350]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.0) with ESMTP id RAA27041; Wed, 20 Oct 1999 17:38:42 +0900 (JST) Date: Wed, 20 Oct 1999 17:52:54 +0900 Message-ID: <14349.33510.484495.58712V@condor.isl.rdc.toshiba.co.jp> From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: richdr@microsoft.com Cc: itojun@iijlab.net, ipng@sunroof.eng.sun.com Subject: RE: reconnecting an interface In-Reply-To: In your message of "Fri, 15 Oct 1999 14:59:12 -0700" <4D0A23B3F74DD111ACCD00805F31D81014515C2C@RED-MSG-50> References: <4D0A23B3F74DD111ACCD00805F31D81014515C2C@RED-MSG-50> User-Agent: Wanderlust/2.2.4 (Black Or White) Emacs/20.4 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.4 - "Terai") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 53 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'm sorry, I should've answered your questions but I've not had enough time. >>>>> On Fri, 15 Oct 1999 14:59:12 -0700, >>>>> Richard Draves said: >> You may want to take a look at KAME nomadic node hack by Tatsuya >> Jinmei, which is described in section 3.4 of the >> following paper: >> http://www.isoc.org/inet99/proceedings/4s/4s_2.htm >> The code is available in normal KAME distribution and >> works well. > I worry that there could be an accumulation of detached prefixes and > addresses... > It's not clear to me what happens to UDP/TCP sockets that are using an > address that becomes detached? A detached address is not used as a source address of a "new" connection, but it's still valid in a bound socket (just as a deprecated address). So if the detached address is luckily valid (i.e. can be effectively used for a communication) after moving, the socket will simply be able to continue to use the address. > The paper says: "One simple solution to these problems is to force the node > to discard the old prefix and the old address after moving. But this > approach may cause an unexpected deletion of prefixes and addresses that > should remain valid. For instance, suppose that there is a failure of the > router on a network while a laptop computer is suspended. When the laptop's > operation is resumed, it should discard the prefix and the address that were > advertised before suspension, because there is a possibility that the laptop > has moved from the network. The laptop, however, cannot get a prefix anymore > because the router has already stopped; it therefore fails to communicate > with any nodes, even with those within the network." > So the problem is that the router's down, so communication fails. That > sounds like expected behavior, why is it a problem to fix? As Bill has already answered (thanks!), my concern here is a case where another node on the link tries to connect to the laptop using the (mistakenly) discarded address. I admit, however, that it's not a typical case and that the network can't be expected to work normally when the only router is down. Anyway, we've already implemented the approach and the implementation has worked fine for more than one years for typical cases as well as for rare cases. 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 20 03:59:37 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta4+Sun/8.10.0.Beta4) id d9KAug914972 for ipng-dist; Wed, 20 Oct 1999 03:56:42 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta4+Sun/8.10.0.Beta4) with ESMTP id d9KAuWQ14965 for ; Wed, 20 Oct 1999 03:56:32 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id DAA04186 for ; Wed, 20 Oct 1999 03:56:31 -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 DAA19633 for ; Wed, 20 Oct 1999 03:56:30 -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 GAA24148; Wed, 20 Oct 1999 06:56:28 -0400 (EDT) Message-Id: <199910201056.GAA24148@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-esd-analysis-05.txt Date: Wed, 20 Oct 1999 06:56:28 -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 : Separating Identifiers and Locators in Addresses: An Analysis of the GSE Proposal for IP Author(s) : M. Crawford, A. Mankin, T. Narten, J. Stewart, L. Zhang Filename : draft-ietf-ipngwg-esd-analysis-05.txt Pages : 52 Date : 19-Oct-99 On February 27-28, 1997, the IPng Working Group held an interim meeting in Palo Alto, California to consider adopting Mike O'Dell's 'GSE - An Alternate Addressing Architecture for IPv6' proposal [GSE]. In GSE, 16-byte IPv6 addresses are split into distinct portions for global routing, local routing and end-point identification. GSE includes the feature of configuring a node internal to a site with only the local routing and end-point identification portions of the address, thus hiding the full address from the node. When such a node generates a packet, only the low-order bytes of the source address are specified; the high-order bytes of the address are filled in by a border router when the packet leaves the site. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-esd-analysis-05.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-esd-analysis-05.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-esd-analysis-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19991019135837.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-esd-analysis-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-esd-analysis-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991019135837.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 20 10:59:27 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta4+Sun/8.10.0.Beta4) id d9KHteK15298 for ipng-dist; Wed, 20 Oct 1999 10:55:40 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.0.Beta4+Sun/8.10.0.Beta4) with ESMTP id d9KHtYQ15291 for ; Wed, 20 Oct 1999 10:55:34 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.1b+Sun/8.9.1) id KAA22567 for ipng@sunroof.eng.sun.com; Wed, 20 Oct 1999 10:53:12 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta4+Sun/8.10.0.Beta4) with ESMTP id d9KGCaQ15194 for ; Wed, 20 Oct 1999 09:12:37 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA29630 for ; Wed, 20 Oct 1999 09:12:36 -0700 (PDT) Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA19673 for ; Wed, 20 Oct 1999 09:12:35 -0700 (PDT) Received: from penelope.ecs.soton.ac.uk (penelope.ecs.soton.ac.uk [152.78.68.135]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id RAA09066 for ; Wed, 20 Oct 1999 17:12:23 +0100 (BST) Received: from penelope (penelope [152.78.68.135]) by penelope.ecs.soton.ac.uk (8.9.1a/8.9.1) with ESMTP id RAA27079 for ; Wed, 20 Oct 1999 17:12:23 +0100 (BST) Date: Wed, 20 Oct 1999 17:12:23 +0100 (BST) From: Tim Chown To: ipng@sunroof.eng.sun.com Subject: UK Network News IPv6 "tapping" article Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, One of the UK printed mags ran a cover story on the IESG statement about wire-tapping of IP telephony. The headline reads "IETF proposes to open up IPv6 to internet wire taps." Not quite what the IESG said, but the issue is one which could blow up if not addressed clearly at Washington's advertised plenary. The IESG statement is at: http://www.ietf.org/mail-archive/ietf-announce/msg05435.html Cheers, Tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 20 18:56:05 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta4+Sun/8.10.0.Beta4) id d9L1rLS16019 for ipng-dist; Wed, 20 Oct 1999 18:53:21 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta4+Sun/8.10.0.Beta4) with ESMTP id d9L1rBQ16012 for ; Wed, 20 Oct 1999 18:53:13 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id SAA05921 for ; Wed, 20 Oct 1999 18:53:11 -0700 (PDT) Received: from smtp6.mindspring.com (smtp6.mindspring.com [207.69.200.110]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA08930 for ; Wed, 20 Oct 1999 19:53:10 -0600 (MDT) Received: from ix.netcom.com (dal-tx1-29.ix.netcom.com [207.94.120.93]) by smtp6.mindspring.com (8.8.5/8.8.5) with ESMTP id VAA31940 for ; Wed, 20 Oct 1999 21:52:56 -0400 (EDT) Message-ID: <380E0178.F5D3308B@ix.netcom.com> Date: Wed, 20 Oct 1999 18:52:58 +0100 From: Jeff Williams Organization: INEG. Inc. (Spokesman INEGroup) X-Mailer: Mozilla 4.08 [en] (Win16; I) MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: New FTC rueling on Privacy for children may have far reaching consequences. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The FTC ruled today that opt-out rules will apply in privacy with respect to children on the net. This could have broad reaching implications in DNS and IPv6 issues. See: http://www.ftc.gov/opa/1999/9910/childfinal.htm Regards, -- Jeffrey A. Williams Spokesman INEGroup (Over 95k members strong!) CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 972-447-1894 Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 20 20:20:09 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta4+Sun/8.10.0.Beta4) id d9L3HB516081 for ipng-dist; Wed, 20 Oct 1999 20:17:11 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta4+Sun/8.10.0.Beta4) with ESMTP id d9L3GuQ16074 for ; Wed, 20 Oct 1999 20:16:59 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id UAA10300 for ; Wed, 20 Oct 1999 20:16:17 -0700 (PDT) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA26432 for ; Wed, 20 Oct 1999 21:16:17 -0600 (MDT) Received: from postal.research.att.com (postal.research.att.com [135.207.23.30]) by mail-blue.research.att.com (Postfix) with ESMTP id 65C154CE22; Wed, 20 Oct 1999 23:16:15 -0400 (EDT) Received: from smb.research.att.com (sigaba.research.att.com [135.207.23.169]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id XAA10718; Wed, 20 Oct 1999 23:16:01 -0400 (EDT) Received: by smb.research.att.com (Postfix, from userid 54047) id 74869ACADC; Wed, 20 Oct 1999 23:16:10 -0400 (EDT) Received: from smb.research.att.com (localhost [127.0.0.1]) by smb.research.att.com (Postfix) with ESMTP id 6D2D8ABC3E; Wed, 20 Oct 1999 23:16:05 -0400 (EDT) X-Mailer: exmh version 2.0.2 2/24/98 From: "Steven M. Bellovin" To: Jeff Williams Cc: ipng@sunroof.eng.sun.com Subject: Re: New FTC rueling on Privacy for children may have far reaching consequences. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 20 Oct 1999 23:16:04 -0400 Message-Id: <19991021031610.74869ACADC@smb.research.att.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <380E0178.F5D3308B@ix.netcom.com>, Jeff Williams writes: >The FTC ruled today that opt-out rules will apply in privacy with >respect to children on the net. This could have broad reaching >implications in DNS and IPv6 issues. >See: http://www.ftc.gov/opa/1999/9910/childfinal.htm Perhaps, perhaps not. Have you read the actual rule? The text at the bottom of page 15/top of 16 states explicitly that static IP addresses and processor serial numbers are not considered "personal information" unless they are linked to other "individually identifiable personal information". The same applies to cookies. See page 79 (part of section 312.2) for the precise formal definition in the rules. --Steve Bellovin -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 20 20:35:05 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta4+Sun/8.10.0.Beta4) id d9L3WRg16115 for ipng-dist; Wed, 20 Oct 1999 20:32:27 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta4+Sun/8.10.0.Beta4) with ESMTP id d9L3WHQ16108 for ; Wed, 20 Oct 1999 20:32:18 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id UAA29800 for ; Wed, 20 Oct 1999 20:32:16 -0700 (PDT) Received: from smtp6.mindspring.com (smtp6.mindspring.com [207.69.200.110]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA29845 for ; Wed, 20 Oct 1999 21:32:16 -0600 (MDT) Received: from ix.netcom.com (dal-tx62-08.ix.netcom.com [207.221.94.200]) by smtp6.mindspring.com (8.8.5/8.8.5) with ESMTP id XAA07192; Wed, 20 Oct 1999 23:32:12 -0400 (EDT) Message-ID: <380E18BB.9BE28533@ix.netcom.com> Date: Wed, 20 Oct 1999 20:32:13 +0100 From: Jeff Williams Organization: INEG. Inc. (Spokesman INEGroup) X-Mailer: Mozilla 4.08 [en] (Win16; I) MIME-Version: 1.0 To: "Steven M. Bellovin" CC: ipng@sunroof.eng.sun.com Subject: Re: New FTC rueling on Privacy for children may have far reaching consequences. References: <19991021031610.74869ACADC@smb.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve and all, Steven M. Bellovin wrote: > In message <380E0178.F5D3308B@ix.netcom.com>, Jeff Williams writes: > >The FTC ruled today that opt-out rules will apply in privacy with > >respect to children on the net. This could have broad reaching > >implications in DNS and IPv6 issues. > >See: http://www.ftc.gov/opa/1999/9910/childfinal.htm > > Perhaps, perhaps not. Have you read the actual rule? The text at the bottom of page 15/top of 16 states explicitly that static IP addresses and processor serial numbers are not considered "personal information" unless they are linked to other "individually identifiable personal information". The same applies to cookies. See page 79 (part of section 312.2) for the precise formal definition in the rules. Yes actually I did read those relative sections closely. However they do not decimate with regards to collecting that information or release of that information as it applies to IPv6 in the current spec, most especially the autoconfig. So if the IP address is permanently assigned to any DN for instance that might be related to a Child site for instance, such a provision would not apply and would therefore considered an opt-out issue with that IP address. > > > --Steve Bellovin Regards, -- Jeffrey A. Williams Spokesman INEGroup (Over 95k members strong!) CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 972-447-1894 Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 22 08:18:57 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id d9MFEHm17937 for ipng-dist; Fri, 22 Oct 1999 08:14:17 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id d9MFE7i17927 for ; Fri, 22 Oct 1999 08:14:08 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA11106 for ; Fri, 22 Oct 1999 08:14:07 -0700 (PDT) Received: from digi-data.com (ns.digi-data.com [209.94.197.193]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA24855 for ; Fri, 22 Oct 1999 08:14:04 -0700 (PDT) Received: by odin.digi-data.com id <15237>; Fri, 22 Oct 1999 11:10:30 -0400 Message-Id: <99Oct22.111030gmt-0400.15237@odin.digi-data.com> Date: Fri, 22 Oct 1999 11:16:31 -0400 From: Robert Honore Reply-To: robert@digi-data.com Organization: Digi-Data Systems Limited X-Mailer: Mozilla 4.6 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: IPng Mailing List Subject: Is it just me or is the List really quiet? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear Folks, Is it just me or is the list really quiet? I have not got anything in about 24 hours now. Yours sincerely, Robert Honore. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Oct 22 09:51:40 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id d9MGjWl18060 for ipng-dist; Fri, 22 Oct 1999 09:45:32 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id d9MGjJi18053 for ; Fri, 22 Oct 1999 09:45:21 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA08732 for ; Fri, 22 Oct 1999 09:45:19 -0700 (PDT) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA05236 for ; Fri, 22 Oct 1999 09:45:18 -0700 (PDT) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id LAA27248; Fri, 22 Oct 1999 11:45:08 -0500 (CDT) Message-Id: <199910221645.LAA27248@gungnir.fnal.gov> To: ipng@sunroof.eng.sun.com Cc: Steve Deering , Bob Hinden From: "Matt Crawford" Subject: ICMP name lookups Date: Fri, 22 Oct 1999 11:45:08 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I just submitted draft-ietf-ipngwg-icmp-name-lookups-05.txt. Significant changes are: + Names are expressed in DNS notation rather than as ASCII strings. This future-proofs the protocol against the possibility of UTF-8 DNS names or other such horrors. + The multicast address for queries by name is now formed with (truncated) MD5 rather than CRC-32. + I added a Code value and a Qtype to let IPv4 addresses be the subject or object of a query. (But this is still an ICMPv6-only protocol!) + I added a flag to the Node Addresses query to ask for IPv4-compatible addresses. + Returned addresses are now each tagged with a caching time limit. + The flag bits have been rearranged for uniformity. (I apologize in advance to early implementors!) The draft is available for early reading at . When the draft appears through the i-d editor, I request that the chairs begin WG last call at their discretion. Matt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Oct 22 09:54:00 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id d9MGp6d18069 for ipng-dist; Fri, 22 Oct 1999 09:51:06 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id d9MGoti18062 for ; Fri, 22 Oct 1999 09:50:56 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA09867 for ; Fri, 22 Oct 1999 09:50:55 -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 JAA07635 for ; Fri, 22 Oct 1999 09:50:54 -0700 (PDT) Received: from new (satsuma.iprg.nokia.com [205.226.1.120]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with ESMTP id JAA02852; Fri, 22 Oct 1999 09:50:20 -0700 (PDT) Message-Id: <4.2.0.58.19991022094914.03ac4ad0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 22 Oct 1999 09:49:38 -0700 To: robert@digi-data.com From: Bob Hinden Subject: Re: Is it just me or is the List really quiet? Cc: IPng Mailing List In-Reply-To: <99Oct22.111030gmt-0400.15237@odin.digi-data.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Just quiet :-) Bob At 11:16 AM 10/22/99 -0400, Robert Honore wrote: >Dear Folks, > >Is it just me or is the list really quiet? I have not got anything in >about 24 >hours now. >- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 22 10:23:04 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id d9MHFP618102 for ipng-dist; Fri, 22 Oct 1999 10:15:25 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id d9MHFGi18095 for ; Fri, 22 Oct 1999 10:15:17 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA15010 for ; Fri, 22 Oct 1999 10:15:16 -0700 (PDT) Received: from mailext03.compaq.com (mailext03.compaq.com [207.18.199.41]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA18188 for ; Fri, 22 Oct 1999 10:15:14 -0700 (PDT) Received: from mailint02.im.hou.compaq.com (mailint02.compaq.com [207.18.199.35]) by mailext03.compaq.com (Postfix) with ESMTP id 96763152164 for ; Fri, 22 Oct 1999 12:15:13 -0500 (CDT) Received: by mailint02.im.hou.compaq.com (Postfix, from userid 12345) id 90476BC4CC; Fri, 22 Oct 1999 12:15:08 -0500 (CDT) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mailint02.im.hou.compaq.com (Postfix) with ESMTP id 213C7B2A43; Fri, 22 Oct 1999 12:15:08 -0500 (CDT) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id NAA0000013063; Fri, 22 Oct 1999 13:15:12 -0400 (EDT) From: Jim Bound Message-Id: <199910221715.NAA0000013063@quarry.zk3.dec.com> To: Richard Draves Cc: "'IPng List'" Subject: Re: (ngtrans) I-D ACTION:draft-ietf-ngtrans-6to4-03.txt In-reply-to: Your message of "Sun, 17 Oct 1999 22:48:21 PDT." <4D0A23B3F74DD111ACCD00805F31D81014515C3E@RED-MSG-50> Date: Fri, 22 Oct 1999 13:15:11 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Rich, >> Also lets add to the ruleset some type of preference that when the dst >> address is on the same subnet (link) we use a prefix on link. >> I know MS >> does this for IPv4 and UNIX vendors can do it via DNS >> resolver via BIND. > >Isn't this just a special case of what longest-matching-prefix preferences >will do? Yes. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Oct 22 14:12:43 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id d9ML9LV18355 for ipng-dist; Fri, 22 Oct 1999 14:09:21 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id d9ML9Bi18348 for ; Fri, 22 Oct 1999 14:09:13 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id OAA27759 for ; Fri, 22 Oct 1999 14:09:11 -0700 (PDT) Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA29734 for ; Fri, 22 Oct 1999 14:09:09 -0700 (PDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id RAA21266 for ; Fri, 22 Oct 1999 17:08:32 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.37.82.31]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id RAA36756 for ; Fri, 22 Oct 1999 17:08:35 -0400 Received: from rotala.raleigh.ibm.com (localhost [127.0.0.1]) by rotala.raleigh.ibm.com (8.9.3/8.7/RTP-ral-1.0) with ESMTP id RAA17403 for ; Fri, 22 Oct 1999 17:07:45 -0400 Message-Id: <199910222107.RAA17403@rotala.raleigh.ibm.com> To: ipng@sunroof.eng.sun.com Subject: draft-ietf-ipngwg-addrconf-privacy-01.txt Date: Fri, 22 Oct 1999 17:07:45 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Has been submitted. Early birds can find it at ftp://ftp.cs.duke.edu/pub/narten/ietf/privacy.out. The major change is that it now calls for a node to have both public and "anonymous" addresses simultaneously, and that anonymous addresses apply to global scope prefixes only, not link-local or site-local. (It would be trivial to make site-local addresses anonymous as well, but it is not clear this is needed.) In addition, addresses change periodically (e.g., once a day) and not just when a machine restarts. Rich Draves also helped out and is now a coauthor. Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Oct 22 16:24:00 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id d9MNK3F18567 for ipng-dist; Fri, 22 Oct 1999 16:20:03 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id d9MNJqi18560 for ; Fri, 22 Oct 1999 16:19:53 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id QAA25219 for ; Fri, 22 Oct 1999 16:19:52 -0700 (PDT) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id QAA20286 for ; Fri, 22 Oct 1999 16:19:52 -0700 (PDT) Received: from 157.54.9.108 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 22 Oct 1999 16:19:51 -0700 (Pacific Daylight Time) Received: by INET-IMC-05 with Internet Mail Service (5.5.2650.21) id ; Fri, 22 Oct 1999 16:19:50 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D81014515CD5@RED-MSG-50> From: Richard Draves To: "'IPng List'" Subject: draft-ipngwg-default-addr-select-00.txt Date: Fri, 22 Oct 1999 16:19:50 -0700 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I submitted a new draft on address selection last night. > It's available at > ftp://ftp.research.microsoft.com/users/richdr/draft-ipngwg-default-addr-se > lect-00.txt. > The main changes from draft-draves-ipngwg-simple-srcaddr-01.txt are: Added framework discussion. Added algorithm for destination address ordering. Added mechanism to allow the specification of administrative policy that can override the default behavior. Changed the candidate set definition for source address selection, so that only addresses assigned to the outgoing interface are allowed. Unfortunately I won't be able to present it (at least not in person) at DC. I would appreciate any comments here on the list. 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 Sat Oct 23 03:14:12 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id d9NABQt18889 for ipng-dist; Sat, 23 Oct 1999 03:11:26 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id d9NABFi18882 for ; Sat, 23 Oct 1999 03:11:16 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id DAA00515 for ; Sat, 23 Oct 1999 03:11:15 -0700 (PDT) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id DAA22209 for ; Sat, 23 Oct 1999 03:11:12 -0700 (PDT) Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id KA26103; Sat, 23 Oct 1999 20:11:03 +1000 (from kre@munnari.OZ.AU) From: Robert Elz To: Richard Draves Cc: "'IPng List'" Subject: Re: draft-ipngwg-default-addr-select-00.txt In-Reply-To: Your message of "Fri, 22 Oct 1999 16:19:50 MST." <4D0A23B3F74DD111ACCD00805F31D81014515CD5@RED-MSG-50> Date: Sat, 23 Oct 1999 20:11:03 +1000 Message-Id: <18419.940673463@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 22 Oct 1999 16:19:50 -0700 From: Richard Draves Message-ID: <4D0A23B3F74DD111ACCD00805F31D81014515CD5@RED-MSG-50> | Changed the candidate set definition for source address selection, | so that only addresses assigned to the outgoing interface are | allowed. I think this is a mistake. Eg: consider a node with two interfaces A and B. Allow A to have a global address GA (and a local address LA though that won't be relevant here). Allow B to have just a local address LB (no global prefix has been advertised on that link). For the purposes of this example it doesn't matter whether the local addresses are site local, link local (or both). Then consider a packet to be sent to the destination global address GD (exactly one address is available, and it has global scope). And then assume that the node has chosen to transmit the packet through interface B (as assumed in section 5 of the draft, the outgoing interface has been chosen already). For the purposes of this example (just to avoid the "why?" questions, assume that interface B is the only interface containing a default route, and that no more specific route can be used to reach GD). The rule above (section 4.1 of the draft) allows only LB to appear in the candidate set of course addresses, and given only one address in the candidate set, that address must be chosen. That means sending to a global destination address (perhaps way over the other side of the global internet) using a local source address, which is not going to be condusive to working communications. While selecting an address from the set on the outgoing interface ought be done where possible, forcing selection of a useless source address, when an adequate one would have been available, doesn't make a lot of sense. The equivalent for IPv4 would be to demand that the source address selected be the address of the outgoing interface, only to discover that you're sending through an unnumbered interface... IPv6 doesn't really have unnumbered interfaces, but it does have ones that have only local scope addresses. 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 25 04:01:14 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id d9PAwAA19908 for ipng-dist; Mon, 25 Oct 1999 03:58:10 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id d9PAvsi19893 for ; Mon, 25 Oct 1999 03:57:55 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id DAA03690 for ; Mon, 25 Oct 1999 03:57:53 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA07910 for ; Mon, 25 Oct 1999 04:57:52 -0600 (MDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03011; Mon, 25 Oct 1999 06:57:51 -0400 (EDT) Message-Id: <199910251057.GAA03011@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-scopedaddr-format-00.txt Date: Mon, 25 Oct 1999 06:57:51 -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 : An Extension of Format for IPv6 Scoped Addresses Author(s) : T. Jinmei, A. Onoe Filename : draft-ietf-ipngwg-scopedaddr-format-00.txt Pages : 5 Date : 22-Oct-99 This document defines an extension of the format for IPv6 scoped addresses. In the format, a scope identifier is attached to a scoped address in order to supplement the ambiguity of the semantics of the address. Using the format with some library routines will make scope-aware applications simpler. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-scopedaddr-format-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-scopedaddr-format-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-ipngwg-scopedaddr-format-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19991022135619.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-scopedaddr-format-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-scopedaddr-format-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991022135619.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 25 04:01:29 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id d9PAwFs19909 for ipng-dist; Mon, 25 Oct 1999 03:58:15 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id d9PAw0i19901 for ; Mon, 25 Oct 1999 03:58:02 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id DAA24521 for ; Mon, 25 Oct 1999 03:58:00 -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 DAA21288 for ; Mon, 25 Oct 1999 03:57:59 -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 GAA03023; Mon, 25 Oct 1999 06:57:58 -0400 (EDT) Message-Id: <199910251057.GAA03023@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-hbh-ext-csi-02.txt Date: Mon, 25 Oct 1999 06:57:57 -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 : Connection/Link Status Investigation (CSI) IPv6 Hop-by-Hop option and ICMPv6 messages Extension Author(s) : H. Kitamura Filename : draft-ietf-ipngwg-hbh-ext-csi-02.txt Pages : 43 Date : 22-Oct-99 This document proposes a new mechanism called 'Connection/Link Status Investigation (CSI)'. It is designed to collect status information of nodes along the communication path. One new IPv6 Hop-by-Hop option (CSI option) and three new ICMPv6 messages (Status Request/Reply, and Status Report) are proposed as extensions for the CSI mechanism. The CSI mechanism is based on hop-by-hop data acquisition operations and realtime 'boomerang' action messages. It is simple and can investigate both outgoing and incoming paths between the source and the destination with minimum investigation packets. It can provide various new functions (e.g. realtime consumed bandwidth measurement, etc.). Since it has good characteristics, it is possible to innovate current investigation functions (e.g., 'traceroute', 'pathchar', etc.) This document describes specifications of the CSI mechanism and defines a set of basic data types. The CSI mechanism is designed as a generic framework mechanism. By defining new data types to collect, it can be easily applied to various advanced usages. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-hbh-ext-csi-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-hbh-ext-csi-02.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-hbh-ext-csi-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19991022135634.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-hbh-ext-csi-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-hbh-ext-csi-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991022135634.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 25 13:09:37 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id d9PK5n020341 for ipng-dist; Mon, 25 Oct 1999 13:05:49 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id d9PK5ei20334 for ; Mon, 25 Oct 1999 13:05:41 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA16914 for ; Mon, 25 Oct 1999 13:05:39 -0700 (PDT) Received: from inet-vrs-02.microsoft.com (mail2.microsoft.com [131.107.3.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id OAA20855 for ; Mon, 25 Oct 1999 14:05:38 -0600 (MDT) Received: from 157.54.9.104 by inet-vrs-02.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 25 Oct 1999 12:58:22 -0700 (Pacific Daylight Time) Received: by INET-IMC-02 with Internet Mail Service (5.5.2650.21) id ; Mon, 25 Oct 1999 12:58:22 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D81014515CFD@RED-MSG-50> From: Richard Draves To: "'Robert Elz'" Cc: "'IPng List'" Subject: RE: draft-ipngwg-default-addr-select-00.txt Date: Mon, 25 Oct 1999 12:58:19 -0700 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > | Changed the candidate set definition for source > address selection, > | so that only addresses assigned to the outgoing interface are > | allowed. > > I think this is a mistake. Great! I was hoping to provoke some discussion. > Eg: consider a node with two interfaces A and B. Allow A to have > a global address GA (and a local address LA though that won't be > relevant here). Allow B to have just a local address LB (no global > prefix has been advertised on that link). For the purposes of > this example it doesn't matter whether the local addresses are site > local, link local (or both). > > Then consider a packet to be sent to the destination global address GD > (exactly one address is available, and it has global scope). > > And then assume that the node has chosen to transmit the > packet through > interface B (as assumed in section 5 of the draft, the > outgoing interface > has been chosen already). For the purposes of this example (just to > avoid the "why?" questions, assume that interface B is the only > interface containing a default route, and that no more specific route > can be used to reach GD). It sounds to me like your node is misconfigured. Can you construct a realistic situation that would explain this configuration? > While selecting an address from the set on the outgoing > interface ought > be done where possible, forcing selection of a useless source address, > when an adequate one would have been available, doesn't make a lot of > sense. When I asked about this at the Tokyo meeting, no one could come up with a good scenario or criteria for when an address from an interface other than the outgoing interface should be used. Put another way, if the candidate set is to contain addresses from multiple interfaces, to implement the preference for the outgoing interface there would need to be a rule added saying to prefer an address on the outgoing interface over an address on another interface. Where in the prioritized list of rules do you think this rule would belong? One compelling scenario raised at the Tokyo meeting was with unidirectional interfaces, where one would necessarily need to reply by sending packets out another interface. But in that situation the source address is specified by an upper-layer or application. > The equivalent for IPv4 would be to demand that the source address > selected be the address of the outgoing interface, only to discover > that you're sending through an unnumbered interface... IPv6 > doesn't really have unnumbered interfaces, but it does have ones that > have only local scope addresses. I don't have any experience with unnumbered interfaces. Can you draw an analogy to their use in v4 to create a scenario for v6 where an interface with only a link-local address will originate new communication to a global destination? 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 Mon Oct 25 16:29:09 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id d9PNNpb20581 for ipng-dist; Mon, 25 Oct 1999 16:23:51 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id d9PNNfi20574 for ; Mon, 25 Oct 1999 16:23:41 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id QAA00617 for ; Mon, 25 Oct 1999 16:23:40 -0700 (PDT) Received: from rs.arin.net (rs1.arin.net [192.149.252.21]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id QAA02589 for ; Mon, 25 Oct 1999 16:23:38 -0700 (PDT) Received: (qmail 24471 invoked from network); 25 Oct 1999 22:57:24 -0000 Received: from ops.arin.net (192.149.252.141) by rs1.arin.net with SMTP; 25 Oct 1999 22:57:24 -0000 Received: from ice.arin.net (ice.arin.net [192.149.252.205]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id SAA21691; Mon, 25 Oct 1999 18:57:17 -0400 (EDT) Received: from localhost (kerr@localhost) by ice.arin.net (8.9.3/8.9.3) with SMTP id SAA03437; Mon, 25 Oct 1999 18:57:16 -0400 (EDT) X-Authentication-Warning: ice.arin.net: kerr owned process doing -bs Date: Mon, 25 Oct 1999 18:57:16 -0400 (EDT) From: Shane Kerr Reply-To: Shane Kerr To: Laurent Toutain cc: "'Christian Huitema'" , "ksbn@kt.co.kr" , "Jim Bound (Adresse de messagerie)" , "6Bone(Int)" <6bone@isi.edu>, ipng , 6Bone-KR <6bone-kr@6bone.ne.kr> Subject: RE: RSIP(Realm Specific IP) In-Reply-To: <01BF1ADA.887AB8C0.Laurent.Toutain@enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 20 Oct 1999, Laurent Toutain wrote: > We proposed with Jim Bound in the ngtrans group a transition mechanism > called DSTM (Dual Stack Transition Mechanism). It is, in a way, similar > to RSIP. We allocate a temporary IPv4 address to IPv6 hosts and we > tunnel IPv4 packet into IPv6 packet. The tunnel end point is a router at > the border between IPv6 and IPv4 only network. This allow part of a > network to move to IPv6, the rest can stay in IPv4. > > The main difference with RSIP is that IPv4 applications don't have to be > recompiled to deal with DSTM. My understanding is that applications don't have to be recompilied to deal with RSIP either. That is, I should be able to use the good old-fashioned connect() and sendto()/recvfrom() API without changing the binaries. The IP stacks need to be recompiled, to fetch an IP/port from the realm server before a connection is instantiated, but applications should run without modification. Only applications that bind() to a specific IP and/or port should be affected, as I understand it. -- Shane Kerr Software Engineer American Registry for Internet Numbers +1 703-227-9877 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 25 16:44:46 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id d9PNfUD20616 for ipng-dist; Mon, 25 Oct 1999 16:41:30 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id d9PNfFi20609 for ; Mon, 25 Oct 1999 16:41:16 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id QAA22419 for ; Mon, 25 Oct 1999 16:41:15 -0700 (PDT) Received: from roll.mentat.com (mentat.com [192.88.122.129]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA11271 for ; Mon, 25 Oct 1999 17:41:14 -0600 (MDT) Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id QAA06204; Mon, 25 Oct 1999 16:41:39 -0700 (PDT) Received: from feller.mentat.com (feller [192.88.122.144]) by leo.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id QAA16019; Mon, 25 Oct 1999 16:41:39 -0700 (PDT) Received: (from tim@localhost) by feller.mentat.com (8.9.1b+Sun/8.9.1) id QAA21225; Mon, 25 Oct 1999 16:41:38 -0700 (PDT) Date: Mon, 25 Oct 1999 16:41:38 -0700 (PDT) From: Tim Hartrick Message-Id: <199910252341.QAA21225@feller.mentat.com> To: kre@munnari.oz.au, richdr@microsoft.com Subject: RE: draft-ipngwg-default-addr-select-00.txt Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Richard, One scenario which I have run into recently would be not work properly if this restriction held. Now it may be an unrealistic scenario or an implementation specific scenario but here goes. We have an IPv6 node that has a Ethernet link which has a globally routable IPv6 address assigned to it. For the moment lets assume that it was statically assigned. There are no IPv6 routers on the Ethernet. The node also has a IPv6 in IPv4 tunnel interface configured such that it has a default route pointing to a an IPv4 compatible IPv6 address that resides on the other end of the tunnel. This tunnel is the node's connection point to the 6bone. Now the node wants to start a TCP connection to some node on the 6bone. Using your restriction it wouldn't have an appropriately scoped address to use for the communication even though it has a perfectly good address hanging off the Ethernet interface. I believe this scenerio is somewhat akin to the unnumbered interface scenario to which KRE was alluding. Now one can easily say that the tunnel interface should have been assigned the globally routable address in the first place. Because of the way our implementation currently handles tunneling that wasn't an option. It may be that the answer is to simply make tunnel interfaces "first-class" interfaces and this scenario will go away. I suspect that with 6[to|over]4 that is going to be essential anyway. Tim Hartrick Mentat Inc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 25 18:56:36 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id d9Q1rj520790 for ipng-dist; Mon, 25 Oct 1999 18:53:45 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id d9Q1rZi20783 for ; Mon, 25 Oct 1999 18:53:36 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id SAA18059 for ; Mon, 25 Oct 1999 18:53:30 -0700 (PDT) Received: from mailext03.compaq.com (mailext03.compaq.com [207.18.199.41]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA07247 for ; Mon, 25 Oct 1999 18:53:29 -0700 (PDT) Received: from mailint02.im.hou.compaq.com (mailint02.compaq.com [207.18.199.35]) by mailext03.compaq.com (Postfix) with ESMTP id 1040615217E; Mon, 25 Oct 1999 20:53:29 -0500 (CDT) Received: by mailint02.im.hou.compaq.com (Postfix, from userid 12345) id 9AEE6BC4C4; Mon, 25 Oct 1999 20:53:17 -0500 (CDT) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mailint02.im.hou.compaq.com (Postfix) with ESMTP id 9CDDCB2A4C; Mon, 25 Oct 1999 20:53:16 -0500 (CDT) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id VAA0000016413; Mon, 25 Oct 1999 21:53:26 -0400 (EDT) From: Jim Bound Message-Id: <199910260153.VAA0000016413@quarry.zk3.dec.com> To: Shane Kerr Cc: Laurent Toutain , "'Christian Huitema'" , "ksbn@kt.co.kr" , "Jim Bound (Adresse de messagerie)" , "6Bone(Int)" <6bone@isi.edu>, ipng , 6Bone-KR <6bone-kr@6bone.ne.kr> Subject: Re: RSIP(Realm Specific IP) In-reply-to: Your message of "Mon, 25 Oct 1999 18:57:16 EDT." Date: Mon, 25 Oct 1999 21:53:26 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> We proposed with Jim Bound in the ngtrans group a transition mechanism >> called DSTM (Dual Stack Transition Mechanism). It is, in a way, similar >> to RSIP. We allocate a temporary IPv4 address to IPv6 hosts and we >> tunnel IPv4 packet into IPv6 packet. The tunnel end point is a router at >> the border between IPv6 and IPv4 only network. This allow part of a >> network to move to IPv6, the rest can stay in IPv4. >> >> The main difference with RSIP is that IPv4 applications don't have to be >> recompiled to deal with DSTM. >From Shane Kerr Oct 25........ >My understanding is that applications don't have to be recompilied to deal >with RSIP either. That is, I should be able to use the good old-fashioned >connect() and sendto()/recvfrom() API without changing the binaries. The >IP stacks need to be recompiled, to fetch an IP/port from the realm server >before a connection is instantiated, but applications should run without >modification. Only applications that bind() to a specific IP and/or port >should be affected, as I understand it. That is correct the designers did this well. DSTM does not require an IPv4-ONLY node to do anything even if it is using a private address, as then its an intranet solution. Thats the difference. All the code to make DSTM work is on IPv6 not IPv4. So in that sense IPv4 stuff don't have to be messed with. The only common thingees btw RSIP and DSTM are as follows: 1. Translation is not required for an IPv6 node to talk with IPv4. Though I am extrapolating as RSIP has not specified the added functions of IPv6. 2. Global IPv4 addresses are assigned to the end node temporarily from a pool. 3. Most of the architectural precepts and reason for the solutions are similiar. But DSTM addresses directly the transition issue where a user wants to deploy IPv6 on an Intranet but needs to speak with IPv4-ONLY nodes either on the Intranet or on the Internet. Also DSTM permits the incoming connection of IPv4 to an IPv6 node that is then dynamically assigned an IPv4 address as needed. DSTM also provides a Dynamic Tunnel Interface and other parts to make all this work... Yada Yada Yada... But there is no free lunch here as with any transition mechanism, but we do preserve users the ability to use end-to-end computing in its purist form and with IPsec if they choose, as defined by those standards. That is why we consider our NGTRANS proposal/solution unique and distinct. See draft-ietf-ngtrans-dstm-00.txt and send comments to the ngtrans list. What we do not want to do IMO is to deploy RSIP as another band-aid to not get to IPv6. That would be stupid. But RSIP is a good alternative to translation in its present form within IPv4. Once we get DSTM clear within the NGTRANS group it is probably wise for the DSTM authors and RSIP authors to connect and have some kind of meeting of the minds. But lets not interfere with either proposals idea and let each working group make each of them good. Then we take two good things and see what applicability exists. As an idea for thought. But this is an IPv6 list and RSIP is not doing IPv6. thanks /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 25 22:44:07 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id d9Q5SDQ20915 for ipng-dist; Mon, 25 Oct 1999 22:28:13 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id d9Q5Roi20908 for ; Mon, 25 Oct 1999 22:27:53 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id WAA24872 for ; Mon, 25 Oct 1999 22:27:39 -0700 (PDT) Received: from alien.burst.net (dns1.burst.net [209.3.64.50]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA23759 for ; Mon, 25 Oct 1999 22:27:35 -0700 (PDT) Received: from [155.69.177.45] (helo=hotsteppa) by alien.burst.net with esmtp (Exim 3.03 #1) id 11fz36-0002ys-00 for ipng@sunroof.eng.sun.com; Tue, 26 Oct 1999 01:21:32 -0400 Message-ID: <014b01bf1f72$f44bbbc0$2db1459b@pa.ntu.edu.sg> From: "***{ Jayanth }***" To: Subject: IPv6 - A Study Date: Tue, 26 Oct 1999 13:28:14 +0800 Organization: StudioJN Online 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.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, I have been following the discussions here awhile, and would like to know if there is any comprehensive resource available (apart from the RFCs), as to the advantages of IPv6 over contemporary IPv4, from the network/protocol as well as the commercial perspectives. Would appreciate any comments and/or pointers. Thanks in advance. Cheers! Jayanth -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 25 23:25:48 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id d9Q6GHf20990 for ipng-dist; Mon, 25 Oct 1999 23:16:17 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id d9Q6Fvi20983 for ; Mon, 25 Oct 1999 23:16:03 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id XAA27449 for ; Mon, 25 Oct 1999 23:15:58 -0700 (PDT) Received: from inet-vrs-02.microsoft.com (mail2.microsoft.com [131.107.3.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id AAA11760 for ; Tue, 26 Oct 1999 00:15:58 -0600 (MDT) Received: from 157.54.9.104 by inet-vrs-02.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 25 Oct 1999 23:15:57 -0700 (Pacific Daylight Time) Received: by INET-IMC-02 with Internet Mail Service (5.5.2650.21) id ; Mon, 25 Oct 1999 23:15:57 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D81014515D0A@RED-MSG-50> From: Richard Draves To: "'IPng List'" Subject: RE: draft-ietf-ipngwg-scopedaddr-format-00.txt Date: Mon, 25 Oct 1999 23:15:54 -0700 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I like the idea of having a text representation for address plus scope-id. I think the representation should specify the delimiter instead of leaving it open. I don't like the address@scope syntax. Winsock has a WSAStringToAddress function that converts a string (address literal only, not name lookup) to a sockaddr. It already supports the syntax address@port. So using @scope would be ambiguous. In our implementation we are using scope/address. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Oct 26 00:01:46 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id d9Q6sYA21056 for ipng-dist; Mon, 25 Oct 1999 23:54:34 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id d9Q6sKi21049 for ; Mon, 25 Oct 1999 23:54:21 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id XAA06532 for ; Mon, 25 Oct 1999 23:54:21 -0700 (PDT) Received: from inet-vrs-02.microsoft.com (mail2.microsoft.com [131.107.3.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id AAA18318 for ; Tue, 26 Oct 1999 00:54:20 -0600 (MDT) Received: from 157.54.9.104 by inet-vrs-02.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 25 Oct 1999 23:51:58 -0700 (Pacific Daylight Time) Received: by INET-IMC-02 with Internet Mail Service (5.5.2650.21) id ; Mon, 25 Oct 1999 23:51:58 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D81014515D0B@RED-MSG-50> From: Richard Draves To: "'Tim Hartrick'" , kre@munnari.oz.au Cc: ipng@sunroof.eng.sun.com Subject: RE: draft-ipngwg-default-addr-select-00.txt Date: Mon, 25 Oct 1999 23:51:57 -0700 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Now one can easily say that the tunnel interface should > have been > assigned the globally routable address in the first place. > Because of the > way our implementation currently handles tunneling that > wasn't an option. > It may be that the answer is to simply make tunnel interfaces > "first-class" > interfaces and this scenario will go away. I suspect that > with 6[to|over]4 > that is going to be essential anyway. So you can't assign global addresses to your tunnel interfaces? Ignoring the "fix your implementation" response... One thought is that an interface that can't be assigned addresses shouldn't qualify as an interface. So from this perspective, your node would just have the ethernet interface plus a routing table entry referring to an implementation structure that has some passing similarity to an interface. Then the global address would be available as a source address when sending to the 6bone. Another thought: how will your node receive packets from the 6bone that are sent to the global address? They will be arriving via the tunnel. So it would seem that your implementation uses a "weak host" model? In Oslo and Tokyo the working group was considering a "semi-strong" model for IPv6 that I think would rule out your implementation (at least if the tunnel is considered to be an interface). A final thought, appropriate only for routers: you could consider the ethernet interface to be originating/receiving packets using the global address, and it's internally forwarding the packets over to the tunnel interface. If this is a desired viewpoint, I'd want to change the draft to be more explicit about effectively enlarging the candidate set of source addresses on routers. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Oct 26 01:00:45 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id d9Q7qlu21113 for ipng-dist; Tue, 26 Oct 1999 00:52:47 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id d9Q7qZi21102 for ; Tue, 26 Oct 1999 00:52:37 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id AAA10166 for ; Tue, 26 Oct 1999 00:52:35 -0700 (PDT) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id BAA29275 for ; Tue, 26 Oct 1999 01:52:32 -0600 (MDT) Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id HA11039; Tue, 26 Oct 1999 17:52:12 +1000 (from kre@munnari.OZ.AU) From: Robert Elz To: Richard Draves Cc: "'IPng List'" Subject: Re: draft-ipngwg-default-addr-select-00.txt In-Reply-To: Your message of "Mon, 25 Oct 1999 12:58:19 MST." <4D0A23B3F74DD111ACCD00805F31D81014515CFD@RED-MSG-50> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 26 Oct 1999 17:52:10 +1000 Message-Id: <8379.940924330@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 25 Oct 1999 12:58:19 -0700 From: Richard Draves Message-ID: <4D0A23B3F74DD111ACCD00805F31D81014515CFD@RED-MSG-50> | It sounds to me like your node is misconfigured. Can you construct a | realistic situation that would explain this configuration? Sure, though what is misconfigured, and what is just unusual, is kind of hard to distinguish at the minute - we don't have "you should be configured like this" guidelines yet. (More below). Part of this is that I believe that we ought keep the mechanisms as flexible as possible so we can adapt to what turns out to be the operating modes that people fall into naturally, rather than constraining them to the operating mode we now see as the one which everyone ought to use. It may be that having a global address on every interface is what the world moves to, but then again, it might not. | When I asked about this at the Tokyo meeting, no one could come up with a | good scenario or criteria for when an address from an interface other than | the outgoing interface should be used. I would say, when the interface has no available suitable address, as one scenario. | Put another way, if the candidate set is to contain addresses from multiple | interfaces, to implement the preference for the outgoing interface there | would need to be a rule added saying to prefer an address on the outgoing | interface over an address on another interface. Where in the prioritized | list of rules do you think this rule would belong? I wouldn't do it that way. After I sent the previous message I realised that I hadn't said what I would change in the draft, and almost decided to reply to myself and fill in the details - then I thought I'd wait for some response. Rather than adding all the addresses into the candidate set, and then be faced with the problem of choosing which to select somehow, I'd be more selective when building the candidate set. That is, I would change section 4.1 to be something like... For the purposes of source address selection, the candidate set of source addresses CandidateSrc(D) for a destination address D contains all the unicast addresses assigned to the interface that will be used to send to the destination D. If no address with scope equal or greater than that of D is in CandidateSrc(D), then addresses of scope greater than, or equal to, the scope of D from other interfaces are added to CandidateSrc(D). Then CandidateSrc(D) only contains addresses from the desireable interface unless none of those is likely to be suitable. With that in mind, the rest of the rules don't need to concern interfaces, they'll find the best (or one of a set of equal best addresses) as it is. | One compelling scenario raised at the Tokyo meeting was with unidirectional | interfaces, where one would necessarily need to reply by sending packets out | another interface. But in that situation the source address is specified by | an upper-layer or application. Huh? Why? Why would the application be any more likely to supply the address in that case than in any other? Are applications supposed to be endowed with knowledge of unidirectional links for some reason? Surely the application just says "open a connection to D", and then if the path to D is via one half of a unidirectional link, that is what gets used. Dealing with this case will probably take more language in the candidate set selection algorithm, as here the interface might actually have a global address, it just isn't one that you really prefer to use. Or perhaps this is a rare enough case, that as long as you have a working address, whether it is the "best" or not doesn't matter as much. | I don't have any experience with unnumbered interfaces. Can you draw an | analogy to their use in v4 to create a scenario for v6 where an interface | with only a link-local address will originate new communication to a global | destination? Sure - unnumbered interfaces are used for all those point to point links for which having an address achieves little, and not having one conserves address space. Maybe IPv6 has enough address space to simply number everything, but given various kind of tunnels (IPv4 tunnels, VPN tunnels, etc) I'm not sure that we necessarily want to mandate burning addresses on such things (if they could reasonably use /126 blocks or something it would probably be OK, but it is more likely they will be using /64 blocks). And for initiating communication - all I need for that is to have my point to point link terminate on my firewall, which is running my mailer - when I send mail, to the world, it goes internally to the firewall, which relays it out its point to point link into the world. The firewall box has a global address for the LAN interface(s) on the internal side, it doesn't really need one for its *DSL, or ISDN, or whatever, interface to the world, just a link local will do fine there. Tim Hartrick's IPv4 tunnels are one possible unnumbered interface, there are many more - the question for here is whether we should be mandating that all such things have IPv6 global addresses (or at least, addresses with a scope as large as any other interfaces on the system), or whether we should be leaving that unspecified for now, to see just how the community configures its systems. There never was an IPv4 "how to choose the source address" specification, so when unnumbered interfaces became useful, their implementation was (fairly) simple. I would suggest that we keep IPv6 flexible the same way. Your reply to Tim was ... richdr@microsoft.com said: | So you can't assign global addresses to your tunnel interfaces? It isn't (or shouldn't be) whether it can be done or not, but whether it must be done. If this is to be mandatory, is there any better reason than simplifying the source address selection algorithm? | One thought is that an interface that can't be assigned addresses | shouldn't qualify as an interface. This sounds like playing with words to suit the definition. I'm not sure that's a good idea, all it can do is lead to future confusion. In any case, in some of these cases (I don't know about Tim's) the interface may have addresses, just not ones with sufficient scope. | Another thought: how will your node receive packets from the 6bone that are | sent to the global address? They will be arriving via the tunnel. So it | would seem that your implementation uses a "weak host" model? In Oslo and | Tokyo the working group was considering a "semi-strong" model for IPv6 That would be overspecification. There's no particular reason why any of these models must be part of the specs - implementations can be of strong, weak, or the "semi-strong" kind as needed. Further, in many of the cases that matter here, the device with the multiple interfaces is a router anyway, for which those models are irrelevant (whether a router simply receives a packet sent to an "incorrect" interface, or whether it internally routes it to the correct interface, and then receives it, is really an irrelevant consideration from the outside). | A final thought, appropriate only for routers: you could consider the | ethernet interface to be originating/receiving packets using the | global address, and it's internally forwarding the packets over to the | tunnel interface. If this is a desired viewpoint, I'd want to change | the draft to be more explicit about effectively enlarging the | candidate set of source addresses on routers. It can be viewed that way, but this is really more artificial layering, which isn't going to match what anyone is really doing - and there's also no real reason why this functionality needs to be confined to routers. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Oct 26 04:31:43 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id d9QBRak21237 for ipng-dist; Tue, 26 Oct 1999 04:27:36 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id d9QBRPi21230 for ; Tue, 26 Oct 1999 04:27:26 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id EAA23693 for ; Tue, 26 Oct 1999 04:27:24 -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 EAA04843 for ; Tue, 26 Oct 1999 04:27: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 HAA01923; Tue, 26 Oct 1999 07:27:19 -0400 (EDT) Message-Id: <199910261127.HAA01923@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-ipngwg-default-addr-select-00.txt Date: Tue, 26 Oct 1999 07:27:19 -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-ipngwg-default-addr-select-00.txt Pages : 10 Date : 25-Oct-99 This document describes two algorithms, for destination address ordering and for source 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ipngwg-default-addr-select-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ipngwg-default-addr-select-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-ipngwg-default-addr-select-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19991025150621.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ipngwg-default-addr-select-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ipngwg-default-addr-select-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991025150621.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 26 05:30:47 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id d9QCPHW21362 for ipng-dist; Tue, 26 Oct 1999 05:25:17 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id d9QCP8i21355 for ; Tue, 26 Oct 1999 05:25:09 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id FAA25530 for ; Tue, 26 Oct 1999 05:25:08 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA17126 for ; Tue, 26 Oct 1999 05:25:06 -0700 (PDT) Received: from localhost (condor.v6.kame.net [3ffe:501:4819:2000:2a0:24ff:fe66:1350]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.0) with ESMTP id VAA21739 for ; Tue, 26 Oct 1999 21:15:29 +0900 (JST) Date: Tue, 26 Oct 1999 21:24:48 +0900 Message-ID: <14357.40336.439165.3063M@condor.isl.rdc.toshiba.co.jp> From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipng@sunroof.eng.sun.com Subject: RE: draft-ietf-ipngwg-scopedaddr-format-00.txt In-Reply-To: In your message of "Mon, 25 Oct 1999 23:15:54 -0700" <4D0A23B3F74DD111ACCD00805F31D81014515D0A@RED-MSG-50> References: <4D0A23B3F74DD111ACCD00805F31D81014515D0A@RED-MSG-50> User-Agent: Wanderlust/2.2.5 (Come Undone) Emacs/20.4 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.4 - "Terai") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 32 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Mon, 25 Oct 1999 23:15:54 -0700, >>>>> Richard Draves said: > I like the idea of having a text representation for address plus scope-id. > I think the representation should specify the delimiter instead of leaving > it open. Agreed, but as you said below, each implementation would have its own syntactical limitation on the delimiter, so I just proposed the concept in the initial draft. After listening to other implementors' opinion, I'll revise the draft with a specific delimiter (and hopefully with a specific notation of scope_id). > I don't like the address@scope syntax. Winsock has a WSAStringToAddress > function that converts a string (address literal only, not name lookup) to a > sockaddr. It already supports the syntax address@port. So using @scope would > be ambiguous. Hmm, okay. In fact, @ would be ambiguous in another context; the (traditional) telnet command using source routing, as I mentioned in the Tokyo interim meeting. Maybe we should change the KAME's implementation... > In our implementation we are using scope/address. What type of notation do you use as "scope"? 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 Tue Oct 26 06:40:31 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id d9QDZbu21425 for ipng-dist; Tue, 26 Oct 1999 06:35:37 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.87.31] (may be forged)) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id d9QDZNi21418 for ; Tue, 26 Oct 1999 06:35:25 -0700 (PDT) Received: from lillen (d-ekst01-129-83.Sweden.Sun.COM [129.159.129.83]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id GAA693809; Tue, 26 Oct 1999 06:35:23 -0700 (PDT) Date: Tue, 26 Oct 1999 06:35:22 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Updated advanced API document To: ipng@sunroof.eng.sun.com Cc: nordmark@jurassic.eng.sun.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I did manage to send in an updated API document (-ipngwg-2292bis-01.txt) before the I-D cutoff, but not all TODO and open issues are taken care of yet. But I felt it would be good to get additional review at this point in time. However, due to some formatting problems (tab characters being "eaten" by nroff) some of the new data structures are hard to read. Thus they should be: 2.1.3. IPv6 Options Eleven options are defined for IPv6 at the time of writing this document. We define structures for all except the unspecified EID option. The following structures are defined as a result of including . /* IPv6 options */ struct ip6_opt { uint8_t ip6o_type; uint8_t ip6o_len; }; /* * The high-order 3 bits of the option type define the behavior * when processing an unknown option and whether or not the option * content changes in flight. */ #define IP6OPT_TYPE(o) ((o) & 0xc0) #define IP6OPT_TYPE_SKIP 0x00 #define IP6OPT_TYPE_DISCARD 0x40 #define IP6OPT_TYPE_FORCEICMP 0x80 #define IP6OPT_TYPE_ICMP 0xc0 #define IP6OPT_MUTABLE 0x20 #define IP6OPT_PAD1 0x00 /* 00 0 00000 */ #define IP6OPT_PADN 0x01 /* 00 0 00001 */ #define IP6OPT_JUMBO 0xc2 /* 11 0 00010 = 194 */ #define IP6OPT_NSAP_ADDR 0xc3 /* 11 0 00011 */ #define IP6OPT_TUNNEL_LIMIT 0x04 /* 00 0 00100 */ #define IP6OPT_ROUTER_ALERT 0x05 /* 00 0 00101 */ draft-ietf-ipngwg-2292bis-01.txt [Page 10] INTERNET-DRAFT Advanced Sockets API for IPv6 Oct 22, 1999 #define IP6OPT_BINDING_UPDATE 0xc6 /* 11 0 00110 */ #define IP6OPT_BINDING_ACK 0x07 /* 00 0 00111 */ #define IP6OPT_BINDING_REQ 0x08 /* 00 0 01000 */ #define IP6OPT_HOME_ADDRESS 0xc9 /* 11 0 01001 */ #define IP6OPT_EID 0x8a /* 10 0 01010 */ /* Jumbo Payload Option */ struct ip6_opt_jumbo { uint8_t ip6oj_type; uint8_t ip6oj_len; uint8_t ip6oj_jumbo_len[4]; }; #define IP6OPT_JUMBO_LEN 6 /* NSAP Address Option */ struct ip6_opt_nsap { uint8_t ip6on_type; uint8_t ip6on_len; uint8_t ip6on_src_nsap_len; uint8_t ip6on_dst_nsap_len; /* followed by source NSAP */ /* followed by destination NSAP */ }; /* Tunnel Limit Option */ struct ip6_opt_tunnel { uint8_t ip6ot_type; uint8_t ip6ot_len; uint8_t ip6ot_encap_limit; }; /* Router Alert Option */ struct ip6_opt_router { uint8_t ip6or_type; uint8_t ip6or_len; uint8_t ip6or_value[2]; }; /* Router alert values (in network byte order) */ #ifdef _BIG_ENDIAN #define IP6_ALERT_MLD 0x0000 #define IP6_ALERT_RSVP 0x0001 #define IP6_ALERT_AN 0x0002 #else #define IP6_ALERT_MLD 0x0000 #define IP6_ALERT_RSVP 0x0100 #define IP6_ALERT_AN 0x0200 #endif draft-ietf-ipngwg-2292bis-01.txt [Page 11] INTERNET-DRAFT Advanced Sockets API for IPv6 Oct 22, 1999 /* Binding Update Option */ struct ip6_opt_binding_update { uint8_t ip6ou_type; uint8_t ip6ou_len; uint8_t ip6ou_flags; uint8_t ip6ou_prefixlen; uint8_t ip6ou_seqno[2]; uint8_t ip6ou_lifetime[4]; uint8_t ip6ou_coa[16]; /* Optional based on flags */ /* followed by sub-options */ }; /* Binding Update Flags */ #define IP6_BUF_ACK 0x80 /* Request a binding ack */ #define IP6_BUF_HOME 0x40 /* Home Registration */ #define IP6_BUF_COA 0x20 /* Care-of-address present in option */ #define IP6_BUF_ROUTER 0x10 /* Sending mobile node is a router */ /* Binding Ack Option */ struct ip6_opt_binding_ack { uint8_t ip6oa_type; uint8_t ip6oa_len; uint8_t ip6oa_status; uint8_t ip6oa_seqno[2]; uint8_t ip6oa_lifetime[4]; uint8_t ip6oa_refresh[4]; /* followed by sub-options */ }; /* Binding Request Option */ struct ip6_opt_binding_request { uint8_t ip6or_type; uint8_t ip6or_len; /* followed by sub-options */ }; /* Home Address Option */ struct ip6_opt_home_address { uint8_t ip6oh_type; uint8_t ip6oh_len; uint8_t ip6oh_addr[16]; /* Home Address */ /* followed by sub-options */ }; 2.2.3. Multicast Listener Discovery Type and Code Values draft-ietf-ipngwg-2292bis-01.txt [Page 16] INTERNET-DRAFT Advanced Sockets API for IPv6 Oct 22, 1999 The following structures and definitions are defined as a result of including . struct mld_hdr { struct icmp6_hdr mld_hdr; struct in6_addr mld_addr; /* multicast address */ }; #define mld_type mld_hdr.icmp6_type #define mld_code mld_hdr.icmp6_code #define mld_cksum mld_hdr.icmp6_cksum #define mld_maxdelay mld_hdr.icmp6_data16[0] #define mld_reserved mld_hdr.icmp6_data16[1] 2.2.4. ICMPv6 Router Renumbering Type and Code Values The following structures and definitions are defined as a result of including . struct icmp6_router_renum { /* router renumbering header */ struct icmp6_hdr rr_hdr; u_int8_t rr_segnum; u_int8_t rr_flags; u_int16_t rr_maxdelay; u_int32_t rr_reserved; }; #define rr_type rr_hdr.icmp6_type #define rr_code rr_hdr.icmp6_code #define rr_cksum rr_hdr.icmp6_cksum #define rr_seqnum rr_hdr.icmp6_data32[0] /* Router renumbering flags */ #define ICMP6_RR_FLAGS_TEST 0x80 #define ICMP6_RR_FLAGS_REQRESULT 0x40 #define ICMP6_RR_FLAGS_FORCEAPPLY 0x20 #define ICMP6_RR_FLAGS_SPECSITE 0x10 #define ICMP6_RR_FLAGS_PREVDONE 0x08 struct rr_pco_match { /* match prefix part */ u_int8_t rpm_code; u_int8_t rpm_len; u_int8_t rpm_ordinal; u_int8_t rpm_matchlen; u_int8_t rpm_minlen; u_int8_t rpm_maxlen; u_int16_t rpm_reserved; draft-ietf-ipngwg-2292bis-01.txt [Page 17] INTERNET-DRAFT Advanced Sockets API for IPv6 Oct 22, 1999 struct in6_addr rpm_prefix; }; /* PCI code values */ #define RPM_PCO_ADD 1 #define RPM_PCO_CHANGE 2 #define RPM_PCO_SETGLOBAL 3 struct rr_pco_use { /* use prefix part */ u_int8_t rpu_uselen; u_int8_t rpu_keeplen; u_int8_t rpu_ramask; u_int8_t rpu_raflags; u_int32_t rpu_vltime; u_int32_t rpu_pltime; u_int32_t rpu_flags; struct in6_addr rpu_prefix; }; #define ICMP6_RR_PCOUSE_RAFLAGS_ONLINK 0x20 #define ICMP6_RR_PCOUSE_RAFLAGS_AUTO 0x10 #if BYTE_ORDER == BIG_ENDIAN #define ICMP6_RR_PCOUSE_FLAGS_DECRVLTIME 0x80000000 #define ICMP6_RR_PCOUSE_FLAGS_DECRPLTIME 0x40000000 #elif BYTE_ORDER == LITTLE_ENDIAN #define ICMP6_RR_PCOUSE_FLAGS_DECRVLTIME 0x80 #define ICMP6_RR_PCOUSE_FLAGS_DECRPLTIME 0x40 #endif struct rr_result { /* router renumbering result message */ u_int16_t rrr_flags; u_int8_t rrr_ordinal; u_int8_t rrr_matchedlen; u_int32_t rrr_ifid; struct in6_addr rrr_prefix; }; #if BYTE_ORDER == BIG_ENDIAN #define ICMP6_RR_RESULT_FLAGS_OOB 0x0002 #define ICMP6_RR_RESULT_FLAGS_FORBIDDEN 0x0001 #elif BYTE_ORDER == LITTLE_ENDIAN #define ICMP6_RR_RESULT_FLAGS_OOB 0x0200 #define ICMP6_RR_RESULT_FLAGS_FORBIDDEN 0x0100 #endif 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 26 09:34:45 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id d9QGRjL21646 for ipng-dist; Tue, 26 Oct 1999 09:27:45 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id d9QGRMi21639 for ; Tue, 26 Oct 1999 09:27:24 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA23496 for ; Tue, 26 Oct 1999 09:27:21 -0700 (PDT) Received: from maredsous.monarch.cs.cmu.edu (MAREDSOUS.MONARCH.CS.CMU.EDU [128.2.250.149]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA15004 for ; Tue, 26 Oct 1999 09:27:20 -0700 (PDT) Received: from maredsous.monarch.cs.cmu.edu (localhost [127.0.0.1]) by maredsous.monarch.cs.cmu.edu id MAA17444; Tue, 26 Oct 1999 12:28:15 -0400 (EDT) To: mobile-ip@standards.nortelnetworks.com, ipng@sunroof.eng.sun.com From: Dave Johnson Reply-To: Dave Johnson Subject: New version of Mobile IPv6 draft Date: Tue, 26 Oct 1999 12:28:15 -0400 Message-ID: <17442.940955295@maredsous.monarch.cs.cmu.edu> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Friday, I submitted a new (and hopefully final) version of the Mobile IPv6 draft, draft-ietf-mobileip-ipv6-09.txt. Someday soon, the official announcement of it should come out, but I haven't seen an announcement yet, so here's an unofficial announcement: Copies of the new draft are now available from the CMU Monarch Project web pages at http://www.monarch.cs.cmu.edu/ . The URL for the new draft is: http://www.monarch.cs.cmu.edu/internet-drafts/draft-ietf-mobileip-ipv6-09.txt Here's a brief list of most of the changes in the draft since the previous version: - Added a new section (Section 10.2), giving guidance to implementors on the interaction between outbound Mobile IP processing and outbound IPsec processing for packets sent by a mobile node while away from home. - Changed the optional Care-of Address field in the Binding Update option format (Section 5.1) to instead be a sub-option. This better matches the use of other sub-options to encode optional information in an option, and also makes the specification of the alignment requirement for the Binding Update option easier. - Also removed the Care-of Address Present (C) bit in the Binding Update option format, as it is no longer needed with the use of a sub-option to specify the alternate care-of address. NOTE: This change also resulted in moving the Router (R) bit over by one bit position in the Binding Update option format. - Added explicit specification of the alignment requirements [5] for each of the Mobile IPv6 destination options and sub-options. - Introduced Pad1 and PadN sub-options (Section 5.5) to allow the sub-options in Mobile IPv6 options to be aligned properly. To match the option numbering used for the Pad1 and PadN options defined for use in Hop-by-Hop Options and Destination Options extension headers [5], these two sub-options have been numbered 0 and 1, respectively. NOTE: This change also resulted in changing the sub-option numbers of the other Mobile IPv6 sub-options. - Added an explicit specification of the units in which the Lifetime and Refresh fields are expressed in the Binding Acknowledgement option (Section 5.2). As with the corresponding Lifetime field in the Binding Update option and the Valid Lifetime and Preferred Lifetime in the Prefix Information option used by Neighbor Discovery [14], these fields in the Binding Acknowledgement option are expressed in seconds. - Rewrote Section 10.9 to indicate that the Binding Update is sent to any home agent on the link on which the specified previous care-of address is located, rather than (necessarily) to the router that it used as its default router on that link. Also, the mobile node can establish packet forwarding from any previous care-of address, not just from its previous primary care-of address. - Removed the Status value of 129 (Poorly formed Binding Update) for the Binding Acknowledgement option, since this value is not used. Instead, poorly formed Binding Updates have already been defined (Section 8.2) to be silently discarded. - Removed the Status value of 134 (Sequence Number field value too small) for the Binding Acknowledgement option, since this value is not used. Instead, received Binding Updates in which the Sequence Number field is not greater than the Sequence Number received in the previous Binding Update for this home address, if any, have already been defined (Section 8.2) to be silently discarded. - Corrected a few more minor typographical errors in places. Dave -- David B. Johnson dbj@cs.cmu.edu Associate Professor http://www.cs.cmu.edu/~dbj/ Computer Science Department http://www.monarch.cs.cmu.edu/ Carnegie Mellon University Phone: (412) 268-7399 5000 Forbes Avenue Fax: (412) 268-5576 Pittsburgh, PA 15213-3891 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 26 09:54:21 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id d9QGp6T21723 for ipng-dist; Tue, 26 Oct 1999 09:51:06 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id d9QGori21716 for ; Tue, 26 Oct 1999 09:50:55 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA04377 for ; Tue, 26 Oct 1999 09:50:53 -0700 (PDT) Received: from roll.mentat.com (mentat.com [192.88.122.129]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA23988 for ; Tue, 26 Oct 1999 10:50:53 -0600 (MDT) Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id JAA09575; Tue, 26 Oct 1999 09:51:32 -0700 (PDT) Received: from feller.mentat.com (feller [192.88.122.144]) by leo.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id JAA01539; Tue, 26 Oct 1999 09:51:32 -0700 (PDT) Received: (from tim@localhost) by feller.mentat.com (8.9.1b+Sun/8.9.1) id JAA21577; Tue, 26 Oct 1999 09:51:30 -0700 (PDT) Date: Tue, 26 Oct 1999 09:51:30 -0700 (PDT) From: Tim Hartrick Message-Id: <199910261651.JAA21577@feller.mentat.com> To: kre@munnari.oz.au, richdr@microsoft.com Subject: RE: draft-ipngwg-default-addr-select-00.txt Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Richard, > > So you can't assign global addresses to your tunnel interfaces? > Ignoring the "fix your implementation" response... > Hmm... This is a bit pejorative. The implementation does not require fixing. It works as intended. I freely admit that in order to support routing protocols over tunnels, implement 6to4 or 6over4 the implementation of tunnel interfaces needs to be more expansive. However, to support automatic tunneling and support configured tunnels modeled as routing table entries the implementation is adequate to the task. I didn't intend to have to defend our implementation. I was merely attempting to echo KRE's feelings about the utility of something like IPv4 unnumbered interfaces. > One thought is that an interface that can't be assigned addresses shouldn't > qualify as an interface. So from this perspective, your node would just have > the ethernet interface plus a routing table entry referring to an > implementation structure that has some passing similarity to an interface. > Then the global address would be available as a source address when sending > to the 6bone. > It has been assigned an address. That address is an IPv4 compatible IPv6 address. That assignment happens automatically, but it happens. > Another thought: how will your node receive packets from the 6bone that are > sent to the global address? They will be arriving via the tunnel. So it > would seem that your implementation uses a "weak host" model? In Oslo and > Tokyo the working group was considering a "semi-strong" model for IPv6 that > I think would rule out your implementation (at least if the tunnel is > considered to be an interface). > Both interfaces are configured to forward datagrams. Since I haven't read a definition of what the "semi-strong" model is I can't comment on it. > A final thought, appropriate only for routers: you could consider the > ethernet interface to be originating/receiving packets using the global > address, and it's internally forwarding the packets over to the tunnel > interface. If this is a desired viewpoint, I'd want to change the draft to > be more explicit about effectively enlarging the candidate set of source > addresses on routers. > Yes, that is in essence what is happening. I think the language would need to be tightened (loosened?) to take into account the IPv6 equivalent of unnumbered interfaces. That assumes of course that we determine that a facility like unnumbered interfaces still has utility in the IPv6 world. The reason these things have been used in the IPv4 world was to avoid burning down lots of address space at the server end of PPP dialup connections. That is less of a concern for IPv6 however they also have the added benefit of making PPP dialup boxes at least a little easier to administer. Tim Hartrick Mentat Inc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 26 09:59:07 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id d9QGuWj21788 for ipng-dist; Tue, 26 Oct 1999 09:56:32 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id d9QGuMi21781 for ; Tue, 26 Oct 1999 09:56:23 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA19768 for ; Tue, 26 Oct 1999 09:56:22 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA28046 for ; Tue, 26 Oct 1999 09:56:18 -0700 (PDT) Received: from localhost ([3ffe:501:100f:13ff::a]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.0) with ESMTP id BAA22717; Wed, 27 Oct 1999 01:46:17 +0900 (JST) Date: Wed, 27 Oct 1999 01:52:23 +0900 Message-ID: <14357.56391.879936.85469U@condor.isl.rdc.toshiba.co.jp> From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: pim@catarina.usc.edu Cc: ipng@sunroof.eng.sun.com Subject: question about checksum calculation of PIM for IPv6 User-Agent: Wanderlust/2.2.5 (Come Undone) Emacs/20.4 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.4 - "Terai") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 26 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In RFC 2362 and draft-ietf-pim-v2-sm-00, there is description about the checksum field of PIM packets; Checksum The checksum is the 16-bit one's complement of the one's complement sum of the entire PIM message, (excluding the data portion in the Register message). For computing the checksum, the checksum field is zeroed. i.e. the checksum is calculated without a pseudo-IP header. Should this be applied to IPv6 as well as to IPv4? As far as I know, all upper layer checksums for IPv6 (including ICMPv6 and OSPFv6) are calculated with an IPv6 pseudo-header, mainly because IPv6 does not have an IP layer checksum. IMO, the checksum for PIMv6 should obey the same rule for the same reason. I've read draft-ietf-pim-ipv6-01 as well, but have not seen any specification about the checksum calculation. I'd like to know PIM specialists' opinion. Thanks in advance, 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 Tue Oct 26 10:37:48 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id d9QHWJD21904 for ipng-dist; Tue, 26 Oct 1999 10:32:19 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id d9QHW6i21897 for ; Tue, 26 Oct 1999 10:32:08 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA08501 for ; Tue, 26 Oct 1999 10:32:05 -0700 (PDT) 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 LAA11573 for ; Tue, 26 Oct 1999 11:32:03 -0600 (MDT) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id CAA11111; Wed, 27 Oct 1999 02:31:12 +0900 (JST) To: Dave Johnson cc: mobile-ip@standards.nortelnetworks.com, ipng@sunroof.eng.sun.com In-reply-to: dbj's message of Tue, 26 Oct 1999 12:28:15 -0400. <17442.940955295@maredsous.monarch.cs.cmu.edu> 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: New version of Mobile IPv6 draft From: itojun@iijlab.net Date: Wed, 27 Oct 1999 02:31:12 +0900 Message-ID: <11109.940959072@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >On Friday, I submitted a new (and hopefully final) version of the >Mobile IPv6 draft, draft-ietf-mobileip-ipv6-09.txt. Someday soon, >the official announcement of it should come out, but I haven't seen >an announcement yet, so here's an unofficial announcement: Copies of >the new draft are now available from the CMU Monarch Project web pages >at http://www.monarch.cs.cmu.edu/ . The URL for the new draft is: >http://www.monarch.cs.cmu.edu/internet-drafts/draft-ietf-mobileip-ipv6-09.txt >Here's a brief list of most of the changes in the draft since the >previous version: > > - Added a new section (Section 10.2), giving guidance to > implementors on the interaction between outbound Mobile IP > processing and outbound IPsec processing for packets sent by a > mobile node while away from home. First of all, thanks for compiling section 10.2, it was what I always wished! It would be better if you can talk more about IKE issue (maybe separately from mobile-ipv6 draft) in bullet 4. To setup a IPsec secret key between home address and destination address, IKE packet (UDP port 500) would need to have home address as a source (correct me if I'm wrong on this), and this causes chicken-and-egg problem. 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 26 12:09:41 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id d9QJ5dp22063 for ipng-dist; Tue, 26 Oct 1999 12:05:39 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id d9QJ5Ti22056 for ; Tue, 26 Oct 1999 12:05:30 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA03172 for ; Tue, 26 Oct 1999 12:05:28 -0700 (PDT) Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.198.195]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA27431 for ; Tue, 26 Oct 1999 12:05:28 -0700 (PDT) Received: from [171.71.38.63] (deering-office-mac.cisco.com [171.71.38.63]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id MAA18356; Tue, 26 Oct 1999 12:03:54 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: In-Reply-To: <14357.56391.879936.85469U@condor.isl.rdc.toshiba.co.jp> References: <14357.56391.879936.85469U@condor.isl.rdc.toshiba.co.jp> Date: Tue, 26 Oct 1999 12:03:56 -0700 To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= From: Steve Deering Subject: Re: question about checksum calculation of PIM for IPv6 Cc: pim@catarina.usc.edu, ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 1:52 AM +0900 10/27/99, JINMEI Tatuya / >i.e. the checksum is calculated without a pseudo-IP header. Should >this be applied to IPv6 as well as to IPv4? As far as I know, all >upper layer checksums for IPv6 (including ICMPv6 and OSPFv6) are >calculated with an IPv6 pseudo-header, mainly because IPv6 does not >have an IP layer checksum. IMO, the checksum for PIMv6 should obey the >same rule for the same reason. Including a pseudo-header in an upper-layer checksum is necessary only for those higher-layer protocols that depend on the contents of some IP-layer fields for their own correct operation. For example, TCP uses the addresses from the IP header as part of the identity of TCP connection state, and uses the IP length field to determine the size of the TCP payload. An upper-layer protocol that had no dependencies on any IP header fields would not need to use a pseudo-header. (I don't know, off hand, whether or not PIMv6 is such a protocol.) Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Oct 26 13:25:51 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id d9QKLj622261 for ipng-dist; Tue, 26 Oct 1999 13:21:45 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id d9QKLZi22254 for ; Tue, 26 Oct 1999 13:21:37 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA20128 for ; Tue, 26 Oct 1999 13:21:33 -0700 (PDT) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA24441 for ; Tue, 26 Oct 1999 14:21:32 -0600 (MDT) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id WAA28622; Tue, 26 Oct 1999 22:21:28 +0200 (MET DST) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id WAA06063; Tue, 26 Oct 1999 22:21:28 +0200 (MET DST) Message-Id: <199910262021.WAA06063@givry.inria.fr> From: Francis Dupont To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: ipng@sunroof.eng.sun.com Subject: Re: draft-ietf-ipngwg-scopedaddr-format-00.txt In-reply-to: Your message of Tue, 26 Oct 1999 21:24:48 +0900. <14357.40336.439165.3063M@condor.isl.rdc.toshiba.co.jp> Date: Tue, 26 Oct 1999 22:21:15 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I believe we need a structure too in order to be able to deal with a scoped address in context where a sockaddr_in6 is not needed (for instance in RSVP or IKE tools, currently they use addresses without scope (ie. in6_addr structures), this is obviously *wrong*). Have you a proposal (we need interoperability)? Regards Francis.Dupont@inria.fr PS: I like the '-' character as a delimiter ('@' is already used for other purposes). -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 26 14:04:23 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id d9QKweI22321 for ipng-dist; Tue, 26 Oct 1999 13:58:40 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id d9QKwRi22313 for ; Tue, 26 Oct 1999 13:58:28 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA11690 for ; Tue, 26 Oct 1999 13:58:26 -0700 (PDT) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id NAA17296 for ; Tue, 26 Oct 1999 13:58:26 -0700 (PDT) Received: from 157.54.9.101 by mail1.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 26 Oct 1999 13:58:24 -0700 (Pacific Daylight Time) Received: by INET-IMC-01 with Internet Mail Service (5.5.2650.21) id ; Tue, 26 Oct 1999 13:58:23 -0700 Message-ID: <3D2036E25376D31197A100805FEAD892712E9F@x1red-msg-14.itg-messaging.redmond.corp.microsoft.com> From: Brian Zill To: ipng@sunroof.eng.sun.com Subject: RE: draft-ietf-ipngwg-scopedaddr-format-00.txt Date: Tue, 26 Oct 1999 13:58:20 -0700 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I agree that it would be beneficial if we all used the same textual representation for scoped addresses. I'm not very particular as to how we do this, but I think the scope id should come first (and not after the address). Textual representation of IP addresses has always been big-endian, where the most significant portions of the address come first. And there is also already the precedent of putting port numbers after an address (using a : for a separator) which goes along with this (port numbers can be viewed as the least significant part of an address). Since the scope id is the most significant part, it should be written before the rest of the address. > PS: I like the '-' character as a delimiter ('@' is already used for > other purposes). This could rapidly turn into the same argument regarding reserved characters and the lack of any remaining unused ones that we had over URL representation of addresses. But I agree that @ is particularly bad. The '-' character sounds reasonable to me. We currently use the '/' character (i.e. scopeid/address) in our implementation, but it'd be easy to change to scopeid-address. --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 26 14:33:08 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id d9QLRsx22389 for ipng-dist; Tue, 26 Oct 1999 14:27:54 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id d9QLRTi22382 for ; Tue, 26 Oct 1999 14:27:31 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id OAA10047 for ; Tue, 26 Oct 1999 14:27:30 -0700 (PDT) Received: from inet-vrs-02.microsoft.com (mail2.microsoft.com [131.107.3.124]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id OAA01006 for ; Tue, 26 Oct 1999 14:27:30 -0700 (PDT) Received: from 157.54.9.104 by inet-vrs-02.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 26 Oct 1999 14:27:28 -0700 (Pacific Daylight Time) Received: by INET-IMC-02 with Internet Mail Service (5.5.2650.21) id ; Tue, 26 Oct 1999 14:27:28 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D81014515D1E@RED-MSG-50> From: Richard Draves To: "'JINMEI Tatuya / ????'" Cc: ipng@sunroof.eng.sun.com Subject: RE: draft-ietf-ipngwg-scopedaddr-format-00.txt Date: Tue, 26 Oct 1999 14:21:13 -0700 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > In our implementation we are using scope/address. > > What type of notation do you use as "scope"? Currently a numeric interface or site identifier, but in the future I would like to allow a string name for a scope identifier. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Oct 26 19:01:55 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id d9R1whi22605 for ipng-dist; Tue, 26 Oct 1999 18:58:43 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id d9R1wXi22597 for ; Tue, 26 Oct 1999 18:58:34 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id SAA02720 for ; Tue, 26 Oct 1999 18:58:32 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA03455 for ; Tue, 26 Oct 1999 18:58:31 -0700 (PDT) Received: from localhost (condor.v6.kame.net [3ffe:501:4819:2000:2a0:24ff:fe66:1350]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.0) with ESMTP id KAA24959; Wed, 27 Oct 1999 10:48:47 +0900 (JST) Date: Wed, 27 Oct 1999 10:25:10 +0900 Message-ID: <14358.21622.34253.39645R@condor.isl.rdc.toshiba.co.jp> From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: deering@cisco.com Cc: pim@catarina.usc.edu, ipng@sunroof.eng.sun.com Subject: Re: question about checksum calculation of PIM for IPv6 In-Reply-To: In your message of "Tue, 26 Oct 1999 12:03:56 -0700" References: <14357.56391.879936.85469U@condor.isl.rdc.toshiba.co.jp> User-Agent: Wanderlust/2.2.5 (Come Undone) Emacs/20.4 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.4 - "Terai") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 28 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Tue, 26 Oct 1999 12:03:56 -0700, >>>>> Steve Deering said: >> i.e. the checksum is calculated without a pseudo-IP header. Should >> this be applied to IPv6 as well as to IPv4? As far as I know, all >> upper layer checksums for IPv6 (including ICMPv6 and OSPFv6) are >> calculated with an IPv6 pseudo-header, mainly because IPv6 does not >> have an IP layer checksum. IMO, the checksum for PIMv6 should obey the >> same rule for the same reason. > Including a pseudo-header in an upper-layer checksum is necessary only > for those higher-layer protocols that depend on the contents of some > IP-layer fields for their own correct operation. For example, TCP uses > the addresses from the IP header as part of the identity of TCP connection > state, and uses the IP length field to determine the size of the TCP > payload. An upper-layer protocol that had no dependencies on any IP > header fields would not need to use a pseudo-header. (I don't know, > off hand, whether or not PIMv6 is such a protocol.) PIM uses, for example, the value of the source address field of the IP(4 or 6) header to recognize PIM neighbors. The source adress is also used in order to elect the Designated Router. There is no different in these point between PIMv4 and PIMv6. 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 Tue Oct 26 20:48:11 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id d9R3eeX22675 for ipng-dist; Tue, 26 Oct 1999 20:40:40 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id d9R3eTi22668 for ; Tue, 26 Oct 1999 20:40:30 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id UAA17763 for ; Tue, 26 Oct 1999 20:40:28 -0700 (PDT) Received: from mail.enol.com (enol.com [206.40.240.8]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA26580 for ; Tue, 26 Oct 1999 20:40:28 -0700 (PDT) Received: from workstation (usr5-026.enol.com [206.40.240.46]) by mail.enol.com (Postfix) with SMTP id 0EE8994009 for ; Tue, 26 Oct 1999 21:40:27 -0600 (MDT) Message-ID: <008601bf202d$9d2c3340$2ef028ce@home.net> From: "Jeffery Smith" To: Subject: Stupid Question (How can I learn more about IPv6) Date: Tue, 26 Oct 1999 21:44:46 -0600 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.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I am a student wanting to learn more about IPv6. I would like to setup a small implementation at home. I would like to become someone apprentice you could say. If this is not the place to ask please direct me to the correct place. Thanks in advance for not flaming me to bad. Jeff Smith Geekous Tinkerous -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 26 23:00:25 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id d9R5sfX22778 for ipng-dist; Tue, 26 Oct 1999 22:54:41 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id d9R5sTi22771 for ; Tue, 26 Oct 1999 22:54:30 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id WAA24323 for ; Tue, 26 Oct 1999 22:54:28 -0700 (PDT) Received: from mailext03.compaq.com (mailext03.compaq.com [207.18.199.41]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA24438 for ; Tue, 26 Oct 1999 22:54:28 -0700 (PDT) Received: from mailint12.im.hou.compaq.com (mailint12.compaq.com [207.18.199.190]) by mailext03.compaq.com (Postfix) with ESMTP id DC3EA15200E for ; Wed, 27 Oct 1999 00:54:27 -0500 (CDT) Received: by mailint12.im.hou.compaq.com (Postfix, from userid 12345) id 79DB44FB01; Wed, 27 Oct 1999 00:54:14 -0500 (CDT) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mailint12.im.hou.compaq.com (Postfix) with ESMTP id 2E2C54C909 for ; Wed, 27 Oct 1999 00:54:14 -0500 (CDT) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id BAA0000011309; Wed, 27 Oct 1999 01:54:26 -0400 (EDT) From: Jim Bound Message-Id: <199910270554.BAA0000011309@quarry.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: I: IPv6 Positive Press (nice) Date: Wed, 27 Oct 1999 01:54:26 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ------- Forwarded Message Return-Path: latif.ladid@village.uunet.lu Received: from quarry.zk3.dec.com by iota.zk3.dec.com (8.7.6/UNX 1.7/1.1.20.3/24Apr98-0811AM) id BAA0000017249; Wed, 27 Oct 1999 01:08:05 -0400 (EDT) Received: from mail1.digital.com by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id BAA0000005771; Wed, 27 Oct 1999 01:08:03 -0400 (EDT) Received: from jazz.viagenie.qc.ca (jazz.viagenie.qc.ca [206.123.31.2]) by mail1.digital.com (8.9.2/8.9.2/WV2.0g) with ESMTP id WAA13077 for ; Tue, 26 Oct 1999 22:07:32 -0700 (PDT) Received: from prserv.net (out1.prserv.net [165.87.194.252]) by jazz.viagenie.qc.ca (Viagenie/8.9.3) with ESMTP id AAA55707 for ; Wed, 27 Oct 1999 00:57:28 -0400 (EDT) Received: from oemcomputer ([139.92.77.129]) by prserv.net (out1) with SMTP id <1999102705005925203l6a8be>; Wed, 27 Oct 1999 05:00:59 +0000 Message-Id: <3.0.6.32.19991027065808.00846890@j.pop.uunet.lu> X-Sender: lu000849@j.pop.uunet.lu X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Wed, 27 Oct 1999 06:58:08 +0200 To: members@ipv6forum.com From: Latif LADID Subject: Data Comm WebInsite Weekly/October 26, 1999 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" It took a while but Pete Loshin is on the Datacom magasin. BTW, this is the first extensive article on IPv6 on Datacom. Awareness at newspaper level was also an obstacle! Remember this article was the collective contribution of a lot of v6 deployment people back in March/April The article is a good one! >3) TECH TUTORIAL: IPV6 OVER EVERYTHING >====================================== >Now that they've put the millennial bug behind them, net architects >might think some relaxation is in order. But there's no rest for the >weary: If the Y2K problem is solved, then it must be time to address >IPv6. And deciding when and how to address the newest version of the >Internet protocol is going to be a lot more complicated than simply >making sure things run smoothly come January 1. For the latest on >this critical issue, go to: > >http://www.data.com/issue/991021/ipv6.html > > /Latif ------- End of Forwarded 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 Wed Oct 27 02:59:11 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id d9R9p9G22894 for ipng-dist; Wed, 27 Oct 1999 02:51:09 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id d9R9oji22887 for ; Wed, 27 Oct 1999 02:50:46 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id CAA10141 for ; Wed, 27 Oct 1999 02:50:44 -0700 (PDT) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id CAA18885 for ; Wed, 27 Oct 1999 02:50:41 -0700 (PDT) Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id JA31508; Wed, 27 Oct 1999 19:50:31 +1000 (from kre@munnari.OZ.AU) From: Robert Elz To: Richard Draves Cc: ipng@sunroof.eng.sun.com Subject: Re: draft-ipngwg-default-addr-select-00.txt In-Reply-To: Your message of "Tue, 26 Oct 1999 17:53:47 MST." <4D0A23B3F74DD111ACCD00805F31D81014515D27@RED-MSG-50> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 27 Oct 1999 19:50:31 +1000 Message-Id: <16050.941017831@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 26 Oct 1999 17:53:47 -0700 From: Richard Draves Message-ID: <4D0A23B3F74DD111ACCD00805F31D81014515D27@RED-MSG-50> | The root issue seems to be the proposed "semi-strong" host model. Perhaps, but ... | I just checked Steve Deering's Tokyo presentation - he defined it as "source | address SHOULD belong to the originating interface". (The presentation | didn't define the receive side behavior.) I wasn't in Tokyo, but I have heard Steve describe this before, and it never seemed horribly unreasonable ... but the "SHOULD" is the key there. That means that if there are good reasons for doing differently, one can do differently. Your draft says MUST which doesn't allow that variation. The effect of your draft is to mandate the strong host model (for sending at least). | In discussion of the SHOULD in the semi-strong definition, the consensus was | that source address selection should explicitly call out any exceptions. That's reasonable - as long as it does not pretend that it is now possible to anticipate all possible future exceptions. That's more or less what the text I sent for section 4.1 was doing, I think. | I think there are good reasons to prefer a strong or semi-strong host model | for IPv6. Among them: | - Redirect won't work if a source address from the "wrong" interface is used Yes, that's a nuisance. Not fatal, just a nuisance though. It turns out not to matter on the interfaces which will tend not to have global addresses (the ones I am concerned with at the minute) as they're essentially all point to point, and redirect makes no sense anyway. The same problem applies to the case where the application has specified the source address (or it is forced because of the address chosen by the peer) and it isn't the one which applies to the outgoing interface (which may also have been specified by the application). It has been with us with IPv4 as well. I doubt that this is enough of an argument to influence anything. | - Similarly, I'm told multicast routing might not work Your draft is explicitly concerned with unicast address selection, so I'm not sure this is relevant. It may be that an address without a scope N unicast address can't participate in scope N multicast, I think I could cope with that. | - Predictable host behavior is a good thing Yes, but workable host behaviour is even better. | I think it's more than just sophistry - the semi-strong model and hence | source address selection will need a good definition of "interface". Yes, it would. | The | current definitions (an interface is an attachment to a link and a link is | medium for transmitting packets below the IP layer) might be too imprecise | for our purposes here. Maybe. I view a link as a device (physical or logical) via which IPvN datagrams (of a particular version) can be transmitted from one node to another, without any intermediate IPvN routing of that particular packet. An interface is the point at which a packet is placed on a link, or removed from it. The technology used to move the packet (be it a tunnel over another instance of the same version of IP or over some other technology, or something physical). | I'm not sure I understand the scenario. Is the firewall machine routing | between its internal and external interfaces? Not for these purposes. | If it is not, then I would | configure it with a global address on its external interface and then I | could use site-local addresses if I wanted on the internal interfaces & | networks. You could, and that might be a reasonable choice. The question is not whether you can do that, but whether you must. | Since it would be acting as a host on the external network, it | would need a global address there. This is the issue - as long as it has A global address, is it necessarily true that it MUST have an address on every interface? One global address (plus the necessary routing infrastructure) is all that a host should need to work, more than that might be beneficial, but need it be mandatory? | Is it useful to have hosts with "unnumbered" interfaces? If it is useful to have routers with unnumbered interfaces, then hosts with unnumbered interfaces are a fact of life - because before it enables routing, any router is a host, but the interfaces are still all there (or most of them are, tunnels might not be perhaps). If/when we develop protocols to allow a local router to fetch some of its config from the service provider, then the router might want to send packets out its (unnumbered) point to point link to the ISP, before it starts acting as a router. Unless the target of thost packets is the device at the other end of the point to point link, then a global address will be needed to talk to it (link local cannot work, as the link here has just the two nodes, and almost by definition site local can't work, as the link is the border between the sites). Now you can always "avoid" the rule in that kind of case by simply proclaiming that the application is specifying the source address, rather than allowing the kernel to choose it (when it is all inside one piece of software how you distinguish I can't really tell). I don't think this helps. | No no, the scenario is an incoming TCP connection. TCP needs to reverse the | source & destination addresses, but it came in on a unidirectional interface | so the reply has to go out a different interface. Yes, I understand that scenario. You missed my point. If I have a host with unidirectional links (a pair I assume), then I am just as likely to want to initiate a connection (with only the destination address currently specified) for communications which will use the outgoing side of the unidirectional link pair. For that, I would expect that the source address ought to be the address of the incoming interface, not the outgoing one. Aside from all of this, I suspect that this requirement fails the testability test anyway - that is, there's no way you can really tell if the implementation would be complying with your MUST (assuming it remains) or not from outside. There's no plan to prohibit an application from specifying its source address (to be anything which belongs to the node) I hope ... from outside you simply can't tell whether or not an application has done that, or whether the kernel just assigned the address for the application to use. 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 27 03:30:39 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id d9RANSb22926 for ipng-dist; Wed, 27 Oct 1999 03:23:28 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id d9RANIi22919 for ; Wed, 27 Oct 1999 03:23:19 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id DAA11565 for ; Wed, 27 Oct 1999 03:23:18 -0700 (PDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id EAA11507 for ; Wed, 27 Oct 1999 04:23:16 -0600 (MDT) Received: from 157.54.9.103 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 26 Oct 1999 17:53:56 -0700 (Pacific Daylight Time) Received: by INET-IMC-04 with Internet Mail Service (5.5.2650.21) id ; Tue, 26 Oct 1999 17:53:56 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D81014515D27@RED-MSG-50> From: Richard Draves To: "'Tim Hartrick'" , kre@munnari.oz.au Cc: ipng@sunroof.eng.sun.com Subject: RE: draft-ipngwg-default-addr-select-00.txt Date: Tue, 26 Oct 1999 17:53:47 -0700 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The root issue seems to be the proposed "semi-strong" host model. I just checked Steve Deering's Tokyo presentation - he defined it as "source address SHOULD belong to the originating interface". (The presentation didn't define the receive side behavior.) Note that this breaks down into two different cases: a) if the source address is specified, how this constrains the originating interface b) if the originating interface is specified, how this constrains the source address Only case b) is of concern for my draft. In discussion of the SHOULD in the semi-strong definition, the consensus was that source address selection should explicitly call out any exceptions. But the only exception that anyone came up with was replying to requests arriving on unidirectional interfaces, which is an issue for case a) not case b). Hence I made it a MUST in my draft, hoping to provoke this discussion. Mixing responses to Tim & kre (sorry this is long): >From kre: > That would be overspecification. There's no particular > reason why any > of these models must be part of the specs - implementations can be of > strong, weak, or the "semi-strong" kind as needed. I think there are good reasons to prefer a strong or semi-strong host model for IPv6. Among them: - Redirect won't work if a source address from the "wrong" interface is used - Similarly, I'm told multicast routing might not work - Predictable host behavior is a good thing >From Tim: > > Ignoring the "fix your implementation" response... > > Hmm... This is a bit pejorative. The implementation does not require > fixing. It works as intended. Sorry, no offense intended. > I freely admit that in order to support routing protocols > over tunnels, > implement 6to4 or 6over4 the implementation of tunnel interfaces needs > to be more expansive. > > However, to support automatic tunneling and support configured tunnels > modeled as routing table entries the implementation is adequate to the > task. Sounds somewhat similar to how MSR IPv6 works right now. In our case, configured tunnels are not interfaces; you can't assign an address to a configured tunnel endpoint. We implement 6over4 separately as "real" interfaces. >From kre: > | One thought is that an interface that can't be assigned addresses > | shouldn't qualify as an interface. > > This sounds like playing with words to suit the definition. I think it's more than just sophistry - the semi-strong model and hence source address selection will need a good definition of "interface". The current definitions (an interface is an attachment to a link and a link is medium for transmitting packets below the IP layer) might be too imprecise for our purposes here. For example, sometimes it might be useful to view IPsec tunnel-mode associations as point-to-point links, and sometimes not. >From kre: > | A final thought, appropriate only for routers: you could > consider the > | ethernet interface to be originating/receiving packets using the > | global address, and it's internally forwarding the > packets over to the > | tunnel interface. If this is a desired viewpoint, I'd > want to change > | the draft to be more explicit about effectively enlarging the > | candidate set of source addresses on routers. > > It can be viewed that way, but this is really more artificial > layering, > which isn't going to match what anyone is really doing - and > there's also > no real reason why this functionality needs to be confined to routers. I disagree - it's a very natural conceptualization to think of a router as forwarding internally among its interfaces. There are real reasons for confining this functionality to routers - see the comments about Redirect and multicast routing above, both of which apply to hosts but not routers. >From kre: > And for initiating communication - all I need for that is to have my > point to point link terminate on my firewall, which is running my > mailer - when I send mail, to the world, it goes internally to the > firewall, which relays it out its point to point link into the world. > The firewall box has a global address for the LAN interface(s) on the > internal side, it doesn't really need one for its *DSL, or ISDN, or > whatever, interface to the world, just a link local will do > fine there. I'm not sure I understand the scenario. Is the firewall machine routing between its internal and external interfaces? If it is not, then I would configure it with a global address on its external interface and then I could use site-local addresses if I wanted on the internal interfaces & networks. Since it would be acting as a host on the external network, it would need a global address there. If it is acting as a router with filtering, then I think it would still be sensible to assign a global address to the external interface. But as a router it could logically originate a packet on an internal interface with a global address and then send the packet out the external interface, so the external interface could do without a global address if that were desired. >From Tim: > Yes, that is in essence what is happening. I think the > language would need to > be tightened (loosened?) to take into account the IPv6 > equivalent of unnumbered > interfaces. That assumes of course that we determine that a > facility like > unnumbered interfaces still has utility in the IPv6 world. > > The reason these things have been used in the IPv4 world was > to avoid burning > down lots of address space at the server end of PPP dialup > connections. That > is less of a concern for IPv6 however they also have the > added benefit of > making PPP dialup boxes at least a little easier to administer. Is it useful to have hosts with "unnumbered" interfaces? >From kre: > | One compelling scenario raised at the Tokyo meeting was > with unidirectional > | interfaces, where one would necessarily need to reply by > sending packets out > | another interface. But in that situation the source > address is specified by > | an upper-layer or application. > > Huh? Why? > > Why would the application be any more likely to supply the address in > that case than in any other? Are applications supposed to be endowed > with knowledge of unidirectional links for some reason? No no, the scenario is an incoming TCP connection. TCP needs to reverse the source & destination addresses, but it came in on a unidirectional interface so the reply has to go out a different interface. 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 Wed Oct 27 05:13:11 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id d9RC4fq22990 for ipng-dist; Wed, 27 Oct 1999 05:04:41 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id d9RC4Si22983 for ; Wed, 27 Oct 1999 05:04:29 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id FAA27440 for ; Wed, 27 Oct 1999 05:04:27 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA01249 for ; Wed, 27 Oct 1999 06:04:26 -0600 (MDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06962; Wed, 27 Oct 1999 08:04:24 -0400 (EDT) Message-Id: <199910271204.IAA06962@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-icmp-name-lookups-05.txt Date: Wed, 27 Oct 1999 08:04:24 -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 : IPv6 Node Information Queries Author(s) : M. Crawford Filename : draft-ietf-ipngwg-icmp-name-lookups-05.txt Pages : 13 Date : 26-Oct-99 This document describes an experimental protocol for asking an IPv6 node to supply certain network information, such as its fully- qualified domain name. IPv6 implementation experience has shown that direct queries for FQDN are useful, and a direct query mechanism for other information has been requested. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-icmp-name-lookups-05.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-icmp-name-lookups-05.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-icmp-name-lookups-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19991026145118.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-icmp-name-lookups-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-icmp-name-lookups-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991026145118.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 27 05:50:12 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id d9RCfvv23020 for ipng-dist; Wed, 27 Oct 1999 05:41:57 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id d9RCfhi23013 for ; Wed, 27 Oct 1999 05:41:44 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id FAA16841 for ; Wed, 27 Oct 1999 05:41:44 -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 FAA22398 for ; Wed, 27 Oct 1999 05:41:43 -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 IAA08861; Wed, 27 Oct 1999 08:41:42 -0400 (EDT) Message-Id: <199910271241.IAA08861@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-ipngwg-default-addr-select-00.txt Date: Wed, 27 Oct 1999 08:41:41 -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-ipngwg-default-addr-select-00.txt Pages : 10 Date : 25-Oct-99 This document describes two algorithms, for destination address ordering and for source 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ipngwg-default-addr-select-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ipngwg-default-addr-select-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-ipngwg-default-addr-select-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19991025150621.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ipngwg-default-addr-select-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ipngwg-default-addr-select-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991025150621.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 27 08:37:32 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id d9RFYqZ23223 for ipng-dist; Wed, 27 Oct 1999 08:34:52 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id d9RFYgi23216 for ; Wed, 27 Oct 1999 08:34:43 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA26189 for ; Wed, 27 Oct 1999 08:34:42 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA21518 for ; Wed, 27 Oct 1999 08:34:40 -0700 (PDT) Received: from localhost ([3ffe:501:100f:13ff::a]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.0) with ESMTP id AAA28474; Thu, 28 Oct 1999 00:24:39 +0900 (JST) Date: Thu, 28 Oct 1999 00:12:12 +0900 Message-ID: <14359.5708.218817.40681D@condor.isl.rdc.toshiba.co.jp> From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Francis.Dupont@inria.fr Cc: ipng@sunroof.eng.sun.com Subject: Re: draft-ietf-ipngwg-scopedaddr-format-00.txt In-Reply-To: In your message of "Tue, 26 Oct 1999 22:21:15 +0200" <199910262021.WAA06063@givry.inria.fr> References: <14357.40336.439165.3063M@condor.isl.rdc.toshiba.co.jp> <199910262021.WAA06063@givry.inria.fr> User-Agent: Wanderlust/2.2.5 (Come Undone) Emacs/20.4 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.4 - "Terai") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 27 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Tue, 26 Oct 1999 22:21:15 +0200, >>>>> Francis Dupont said: > I believe we need a structure too in order to be able to deal with > a scoped address in context where a sockaddr_in6 is not needed > (for instance in RSVP or IKE tools, currently they use addresses > without scope (ie. in6_addr structures), this is obviously *wrong*). Do you mean some API that would be used in the tools? If so, why not just use sockaddr_in6 instead of in6_addr? Although I admit that sockaddr_in6 has redundant fields for such purposes, the structure already has *enough* fields. > Have you a proposal (we need interoperability)? So for now, I'm not convinced why a new structure should be introduced (I don't oppose you, but I'm not sure yet). > PS: I like the '-' character as a delimiter ('@' is already used for > other purposes). Okay. Thanks for your opinion. 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 27 09:31:07 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id d9RGRLC23286 for ipng-dist; Wed, 27 Oct 1999 09:27:21 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id d9RGRCi23279 for ; Wed, 27 Oct 1999 09:27:13 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA08689 for ; Wed, 27 Oct 1999 09:27:11 -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 KAA00378 for ; Wed, 27 Oct 1999 10:27:05 -0600 (MDT) Received: from localhost ([3ffe:501:100f:13ff::a]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.0) with ESMTP id BAA28684; Thu, 28 Oct 1999 01:17:20 +0900 (JST) Date: Thu, 28 Oct 1999 01:26:49 +0900 Message-ID: <14359.10185.853927.4596M@condor.isl.rdc.toshiba.co.jp> From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: bzill@microsoft.com Cc: ipng@sunroof.eng.sun.com Subject: RE: draft-ietf-ipngwg-scopedaddr-format-00.txt In-Reply-To: In your message of "Tue, 26 Oct 1999 13:58:20 -0700" <3D2036E25376D31197A100805FEAD892712E9F@x1red-msg-14.itg-messaging.redmond.corp.microsoft.com> References: <3D2036E25376D31197A100805FEAD892712E9F@x1red-msg-14.itg-messaging.redmond.corp.microsoft.com> User-Agent: Wanderlust/2.2.5 (Come Undone) Emacs/20.4 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.4 - "Terai") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 49 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Tue, 26 Oct 1999 13:58:20 -0700, >>>>> Brian Zill said: > I'm not very particular as to how we do this, but I think the scope id > should come first (and not after the address). Textual representation of IP > addresses has always been big-endian, where the most significant portions of > the address come first. And there is also already the precedent of putting > port numbers after an address (using a : for a separator) which goes along > with this (port numbers can be viewed as the least significant part of an > address). Since the scope id is the most significant part, it should be > written before the rest of the address. I'd not necessarily oppose your opinions above, but please let me explain my impression. Is it so obvious that the scope_id part is the most significant part? I'm not sure. It seems to me that we could recognize (for example) a link-local address as follows: 1. Look at the 1st 16 (or at least 10) bits of the address (fe80) and recognize that this is a link-local address. i.e. this is the most significant part. 2. Then look at the scope identifier and recognize to which link the address should belong. (In this scenario, the scope id is the 2nd significant part) 3. Finally use the host id part of the address (i.e. the last 64 bits) to identify the node that the address specifies in the link. So I feel the appropriate portion for the scope_id is subtle. However, I don't stick to the idea that the scope id should be after an address. I'd respect others' opinions. >> PS: I like the '-' character as a delimiter ('@' is already used for >> other purposes). > This could rapidly turn into the same argument regarding reserved characters > and the lack of any remaining unused ones that we had over URL > representation of addresses. But I agree that @ is particularly bad. The > '-' character sounds reasonable to me. We currently use the '/' character > (i.e. scopeid/address) in our implementation, but it'd be easy to change to > scopeid-address. Through the discussion so far, '@' seems bad for the delimiter and '-' seems acceptable. Does anyone have any other suggestions? 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 27 09:54:37 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id d9RGp7Q23370 for ipng-dist; Wed, 27 Oct 1999 09:51:07 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id d9RGp1i23363 for ; Wed, 27 Oct 1999 09:51:02 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.1b+Sun/8.9.1) id JAA00769 for ipng@sunroof.eng.sun.com; Wed, 27 Oct 1999 09:48:38 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id d9REI9i23152 for ; Wed, 27 Oct 1999 07:18:10 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA14858 for ; Wed, 27 Oct 1999 07:18:10 -0700 (PDT) Received: from penguin.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 HAA22452 for ; Wed, 27 Oct 1999 07:18:07 -0700 (PDT) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with SMTP id QAA11409 for ; Wed, 27 Oct 1999 16:18:04 +0200 (MET DST) Received: from heileman by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id QAA21500; Wed, 27 Oct 1999 16:18:03 +0200 Received: from heileman by heileman (8.8.8+Sun/client-1.3) id QAA11663; Wed, 27 Oct 1999 16:18:02 +0200 (MET DST) Message-Id: <199910271418.QAA11663@heileman> Date: Wed, 27 Oct 1999 16:18:02 +0200 (MET DST) From: "Hesham Soliman (M Elfving T/N) 9" Reply-To: "Hesham Soliman (M Elfving T/N) 9" Subject: New version of Mobile IPv6 draft To: ipng@sunroof.eng.sun.com X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4m sparc Content-Type: text X-Sun-Text-Type: ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I forgot to cc this list ... anyway it is probably more relevant here considering the discussions about address privacy that was going on. Dave, I believe there might be one small issue left and it is related to the section on renumbering. If the MN happens to be in a foreign network during renumbering and it receives the new prefix it might generate a new (and not globally unique) interace identifier to form the new address. The draft seems to assume that the last 64 bits are permanent since currently there is no mechanism specified to validate the new address. One simple way of fixing this is that the HA should do a DAD after receiving the MN's new address, and if it fails send the BAck with a new error code (eg invalid address). We have raised this issue in the connectathon in France and it was included in the final report which will be on the web soon I believe. The changes are quite minor to the draft but I believe not doing that can add an unnecessary restriction. I hope this would be the last :) Hesham --------------------------------------------- Hesham Soliman Mobile Systems Research Ericsson Radio Systems Kista, Stockholm. > Date: Tue, 26 Oct 1999 12:28:15 -0400 > From: Dave Johnson > Subject: [MOBILE-IP] New version of Mobile IPv6 draft > X-To: ipng@sunroof.eng.sun.com > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > > On Friday, I submitted a new (and hopefully final) version of the > Mobile IPv6 draft, draft-ietf-mobileip-ipv6-09.txt. Someday soon, > the official announcement of it should come out, but I haven't seen > an announcement yet, so here's an unofficial announcement: Copies of > the new draft are now available from the CMU Monarch Project web pages > at http://www.monarch.cs.cmu.edu/ . The URL for the new draft is: > > http://www.monarch.cs.cmu.edu/internet-drafts/draft-ietf-mobileip-ipv6-09.txt > > Here's a brief list of most of the changes in the draft since the > previous version: > > - Added a new section (Section 10.2), giving guidance to > implementors on the interaction between outbound Mobile IP > processing and outbound IPsec processing for packets sent by a > mobile node while away from home. > > - Changed the optional Care-of Address field in the Binding Update > option format (Section 5.1) to instead be a sub-option. This > better matches the use of other sub-options to encode optional > information in an option, and also makes the specification of the > alignment requirement for the Binding Update option easier. > > - Also removed the Care-of Address Present (C) bit in the Binding > Update option format, as it is no longer needed with the use of a > sub-option to specify the alternate care-of address. NOTE: This > change also resulted in moving the Router (R) bit over by one bit > position in the Binding Update option format. > > - Added explicit specification of the alignment requirements [5] > for each of the Mobile IPv6 destination options and sub-options. > > - Introduced Pad1 and PadN sub-options (Section 5.5) to allow > the sub-options in Mobile IPv6 options to be aligned properly. > To match the option numbering used for the Pad1 and PadN > options defined for use in Hop-by-Hop Options and Destination > Options extension headers [5], these two sub-options have been > numbered 0 and 1, respectively. NOTE: This change also resulted > in changing the sub-option numbers of the other Mobile IPv6 > sub-options. > > - Added an explicit specification of the units in which > the Lifetime and Refresh fields are expressed in the > Binding Acknowledgement option (Section 5.2). As with the > corresponding Lifetime field in the Binding Update option and the > Valid Lifetime and Preferred Lifetime in the Prefix Information > option used by Neighbor Discovery [14], these fields in the > Binding Acknowledgement option are expressed in seconds. > > - Rewrote Section 10.9 to indicate that the Binding Update is sent > to any home agent on the link on which the specified previous > care-of address is located, rather than (necessarily) to the > router that it used as its default router on that link. Also, > the mobile node can establish packet forwarding from any previous > care-of address, not just from its previous primary care-of > address. > > - Removed the Status value of 129 (Poorly formed Binding Update) > for the Binding Acknowledgement option, since this value is not > used. Instead, poorly formed Binding Updates have already been > defined (Section 8.2) to be silently discarded. > > - Removed the Status value of 134 (Sequence Number field value too > small) for the Binding Acknowledgement option, since this value > is not used. Instead, received Binding Updates in which the > Sequence Number field is not greater than the Sequence Number > received in the previous Binding Update for this home address, > if any, have already been defined (Section 8.2) to be silently > discarded. > > - Corrected a few more minor typographical errors in places. > > > Dave > > -- > David B. Johnson dbj@cs.cmu.edu > Associate Professor http://www.cs.cmu.edu/~dbj/ > Computer Science Department http://www.monarch.cs.cmu.edu/ > Carnegie Mellon University Phone: (412) 268-7399 > 5000 Forbes Avenue Fax: (412) 268-5576 > Pittsburgh, PA 15213-3891 --------------------------------------------- Hesham Soliman Mobile Systems Research Ericsson Radio Systems Kista, Stockholm. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 27 10:17:51 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id d9RHCwe23414 for ipng-dist; Wed, 27 Oct 1999 10:12:58 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id d9RHCmi23407 for ; Wed, 27 Oct 1999 10:12:49 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA15831 for ; Wed, 27 Oct 1999 10:12:47 -0700 (PDT) Received: from mailext03.compaq.com (mailext03.compaq.com [207.18.199.41]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA21263 for ; Wed, 27 Oct 1999 11:12:47 -0600 (MDT) Received: from mailint02.im.hou.compaq.com (mailint02.compaq.com [207.18.199.35]) by mailext03.compaq.com (Postfix) with ESMTP id D080715217A for ; Wed, 27 Oct 1999 12:12:46 -0500 (CDT) Received: by mailint02.im.hou.compaq.com (Postfix, from userid 12345) id 5F28DBC4F2; Wed, 27 Oct 1999 12:12:32 -0500 (CDT) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mailint02.im.hou.compaq.com (Postfix) with ESMTP id DA321B2A42; Wed, 27 Oct 1999 12:12:31 -0500 (CDT) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id NAA0000011331; Wed, 27 Oct 1999 13:12:45 -0400 (EDT) From: Jim Bound Message-Id: <199910271712.NAA0000011331@quarry.zk3.dec.com> To: Richard Draves Cc: ipng@sunroof.eng.sun.com Subject: Re: draft-ipngwg-default-addr-select-00.txt In-reply-to: Your message of "Tue, 26 Oct 1999 17:53:47 PDT." <4D0A23B3F74DD111ACCD00805F31D81014515D27@RED-MSG-50> Date: Wed, 27 Oct 1999 13:12:43 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Richard, Good job. I don't see any technical issues with the draft. I think we should all implement it as soon as possible and get UNH to test it on site with the IPv6 machines located at UNH. Then lets do interoperability bake off at Sun Connectathon which I believe is March 2000? Can't really tell if it all will work with the rest of the implementation until we implement it. I will also throw this over the wall to the IPv6 Forum Deployment Technical Directorate to view it from a deployment technical perspective and get the BINDv9 vendors and ISC folks to get some input to this process and most likely bind workers too as the place where it will be implemented for getipxxx will be in our DNS resolvers. I know you can't be at D.C. and I would suggest to the chairs this not be discussed in depth other than update or maybe depicting the algorithms without you there. Unless you want to select a DRI. thanks and good job, /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 27 10:19:05 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id d9RHGsC23430 for ipng-dist; Wed, 27 Oct 1999 10:16:54 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id d9RHGLi23423 for ; Wed, 27 Oct 1999 10:16:27 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA05308 for ; Wed, 27 Oct 1999 10:15:40 -0700 (PDT) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA08525 for ; Wed, 27 Oct 1999 10:15:39 -0700 (PDT) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id TAA16061; Wed, 27 Oct 1999 19:15:38 +0200 (MET DST) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id TAA20375; Wed, 27 Oct 1999 19:15:36 +0200 (MET DST) Message-Id: <199910271715.TAA20375@givry.inria.fr> From: Francis Dupont To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: ipng@sunroof.eng.sun.com Subject: Re: draft-ietf-ipngwg-scopedaddr-format-00.txt In-reply-to: Your message of Thu, 28 Oct 1999 00:12:12 +0900. <14359.5708.218817.40681D@condor.isl.rdc.toshiba.co.jp> Date: Wed, 27 Oct 1999 19:15:19 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: >>>>> On Tue, 26 Oct 1999 22:21:15 +0200, >>>>> Francis Dupont said: > I believe we need a structure too in order to be able to deal with > a scoped address in context where a sockaddr_in6 is not needed > (for instance in RSVP or IKE tools, currently they use addresses > without scope (ie. in6_addr structures), this is obviously *wrong*). Do you mean some API that would be used in the tools? => yes, today these tools use in6_addr structures then scope ids are lost and they work only on a home with only one interface (ie. only where there is no possible ambiguity. If so, why not just use sockaddr_in6 instead of in6_addr? => because of space. You should ask why in6_pktinfo is not replaced by sockaddr_in6 too (because the in6_pktinfo structure is exactly what is needed :-). Although I admit that sockaddr_in6 has redundant fields for such purposes, the structure already has *enough* fields. => too many fields... > Have you a proposal (we need interoperability)? So for now, I'm not convinced why a new structure should be introduced (I don't oppose you, but I'm not sure yet). => I'd like to have an answer from someone involved in a RSVP or IKE tool (I know some of them read the list). I think one of the problems is (was?) the lack of a textual form for a scoped address. Thanks Francis.Dupont@inria.fr PS: my purpose is not to flame RSVP/IKE/... tool writers but in such low layer tools (some parts are in kernels) there are some reasons to use addresses in place of socket addresses with redundant fields. PPS: my current proposal is: struct in6_scaddr { struct in6_addr sc6_addr; uint32_t sc6_scope_id; }; -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 27 13:58:15 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id d9RKsCB23598 for ipng-dist; Wed, 27 Oct 1999 13:54:12 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id d9RKs1i23591 for ; Wed, 27 Oct 1999 13:54:03 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA02939 for ; Wed, 27 Oct 1999 13:54:00 -0700 (PDT) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA03772 for ; Wed, 27 Oct 1999 13:53:55 -0700 (PDT) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id WAA19005; Wed, 27 Oct 1999 22:53:52 +0200 (MET DST) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id WAA12266; Wed, 27 Oct 1999 22:53:51 +0200 (MET DST) Message-Id: <199910272053.WAA12266@givry.inria.fr> From: Francis Dupont To: Robert Elz cc: Richard Draves , "'IPng List'" Subject: Re: draft-ipngwg-default-addr-select-00.txt In-reply-to: Your message of Tue, 26 Oct 1999 17:52:10 +1000. <8379.940924330@munnari.OZ.AU> Date: Wed, 27 Oct 1999 22:53:51 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: That is, I would change section 4.1 to be something like... For the purposes of source address selection, the candidate set of source addresses CandidateSrc(D) for a destination address D contains all the unicast addresses assigned to the interface that will be used to send to the destination D. If no address with scope equal or greater than that of D is in CandidateSrc(D), then addresses of scope greater than, or equal to, the scope of D from other interfaces are added to CandidateSrc(D). => this seems nice (ie. better than the MUST in 4.1) but I don't know if we should take preferred/deprecated property into account too: - if the outgoing interface for D has only deprecated addresses, should we add in CandidateSrc(D) preferred addresses of other interfaces? - on a host this issue is bound to the default router selection which can be connected (or not) to prefix management (ie. we can try select the default router on an interface with a preferred global address). - 6. is empty but a home address is some kind of super-preferred address, ie. we should use it if there is no good reason to use another address. Obviously this "SHOULD" is stronger than the 4.1 provoking "MUST"... Sure - unnumbered interfaces are used for all those point to point links ... => I agree, unnumbered interfaces *are* very important in the IPv4 world. We must have a similar facility for IPv6 (the decision was done when we adopted the address per interface in place of the address per node as in CLNS). When an unnumbered IPv4 interface is used then we take an address from another interface, in the IPv6 world this translates in when an interface with only addresses in too small scopes is used then we take an address from another interface with a larger scope. (ie. I fully support Robert's proposal on this point!) Regards Francis.Dupont@inria.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 27 14:26:31 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id d9RLN9N23649 for ipng-dist; Wed, 27 Oct 1999 14:23:09 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id d9RLMxi23642 for ; Wed, 27 Oct 1999 14:23:00 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id OAA05550 for ; Wed, 27 Oct 1999 14:23:00 -0700 (PDT) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA16579 for ; Wed, 27 Oct 1999 14:22:58 -0700 (PDT) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id XAA19333; Wed, 27 Oct 1999 23:22:38 +0200 (MET DST) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id XAA00873; Wed, 27 Oct 1999 23:22:37 +0200 (MET DST) Message-Id: <199910272122.XAA00873@givry.inria.fr> From: Francis Dupont To: Richard Draves cc: "'Tim Hartrick'" , kre@munnari.oz.au, ipng@sunroof.eng.sun.com Subject: Re: draft-ipngwg-default-addr-select-00.txt In-reply-to: Your message of Tue, 26 Oct 1999 17:53:47 PDT. <4D0A23B3F74DD111ACCD00805F31D81014515D27@RED-MSG-50> Date: Wed, 27 Oct 1999 23:22:36 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: The root issue seems to be the proposed "semi-strong" host model. => semi is semi-strong means a SHOULD in place of a MUST... In our (MSR IPv6) case, configured tunnels are not interfaces; you can't assign an address to a configured tunnel endpoint. => how can we use RIPng over such tunnels? This position has not been defensible since San Jose IETF meeting... Is it useful to have hosts with "unnumbered" interfaces? => yes of course it is useful because a host can have point-to-point interfaces which are natural candidates for being "unnumbered" (because there is nothing to address :-). Regards Francis.Dupont@inria.fr PS: here is a variation on the unidirectional link. At home you have a host with a costly and slow dialup connection and a fast, cheap but unidirectional satellite interface (with only reception, in France 20% of homes with a television have a satellite with interactive capabilities: this is a *real* case). You'd like to use the dialup only as the return path then you'd like to get the satellite interface global address as source even when the outgoing interface is always the dialup one. In fact you'd like to use a dialup interface address only for communications in the dialup link zone (*), ie. when the destination is the local node or the other end of the dialup line. Of course you'd like to get the right setup automagically, ie. source selection won't be the job of applications! PPS: the zone concept was introduced by Steve in Japan, this is nice and to get a document about this will be even nicer (:-)... -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 27 15:11:18 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id d9RM83D23686 for ipng-dist; Wed, 27 Oct 1999 15:08:03 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id d9RM7qi23679 for ; Wed, 27 Oct 1999 15:07:53 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id PAA18704 for ; Wed, 27 Oct 1999 15:07:52 -0700 (PDT) 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 QAA02797 for ; Wed, 27 Oct 1999 16:07:51 -0600 (MDT) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id HAA28734; Thu, 28 Oct 1999 07:07:40 +0900 (JST) To: Francis Dupont cc: ipng@sunroof.eng.sun.com In-reply-to: Francis.Dupont's message of Wed, 27 Oct 1999 19:15:19 +0200. <199910271715.TAA20375@givry.inria.fr> 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: draft-ietf-ipngwg-scopedaddr-format-00.txt From: itojun@iijlab.net Date: Thu, 28 Oct 1999 07:07:39 +0900 Message-ID: <28732.941062059@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >PPS: my current proposal is: >struct in6_scaddr { > struct in6_addr sc6_addr; > uint32_t sc6_scope_id; >}; Do we really need to standardize this structure? Application writers need to define by their own anyway. People who touches IPv6 header (for example) needs to handle in_addr and its associated scope very carefully, anyway (on-wire form is always in6_addr). 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 Wed Oct 27 15:13:52 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id d9RMC9u23711 for ipng-dist; Wed, 27 Oct 1999 15:12:09 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id d9RMBti23704 for ; Wed, 27 Oct 1999 15:11:56 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id PAA19563 for ; Wed, 27 Oct 1999 15:11:56 -0700 (PDT) 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 QAA04430 for ; Wed, 27 Oct 1999 16:11:55 -0600 (MDT) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id HAA28804 for ; Thu, 28 Oct 1999 07:11:54 +0900 (JST) To: ipng@sunroof.eng.sun.com In-reply-to: jinmei's message of Thu, 28 Oct 1999 01:26:49 JST. <14359.10185.853927.4596M@condor.isl.rdc.toshiba.co.jp> 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: draft-ietf-ipngwg-scopedaddr-format-00.txt From: itojun@iijlab.net Date: Thu, 28 Oct 1999 07:11:53 +0900 Message-ID: <28802.941062313@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> This could rapidly turn into the same argument regarding reserved characters >> and the lack of any remaining unused ones that we had over URL >> representation of addresses. But I agree that @ is particularly bad. The >> '-' character sounds reasonable to me. We currently use the '/' character >> (i.e. scopeid/address) in our implementation, but it'd be easy to change to >> scopeid-address. >Through the discussion so far, '@' seems bad for the delimiter and '-' >seems acceptable. Does anyone have any other suggestions? I do not want to start holy war, but "-" is used in many place where we say address ranges, like 10.1.1.1-10.1.1.254 so I fear "-" is not a good bet from porting aspect. 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 Wed Oct 27 15:28:58 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id d9RMPeS23742 for ipng-dist