From owner-ipng@sunroof.eng.sun.com Sat Jun 1 00:39:27 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g517dRrP010608; Sat, 1 Jun 2002 00:39:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g517dQj0010607; Sat, 1 Jun 2002 00:39:26 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g517dMrP010600; Sat, 1 Jun 2002 00:39:22 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA20552; Sat, 1 Jun 2002 00:39:22 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA24488; Sat, 1 Jun 2002 01:40:24 -0600 (MDT) Received: from localhost ([3ffe:501:4819:2000:200:39ff:fed9:21d7]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g517d2880528; Sat, 1 Jun 2002 16:39:02 +0900 (JST) Date: Sat, 01 Jun 2002 16:40:00 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Richard Draves" Cc: "Charles E. Perkins" , "Hesham Soliman (ERA)" , , "IPng Working Group " Subject: Re: RFC 2462 DAD optimization In-Reply-To: <7695E2F6903F7A41961F8CF888D87EA804BC4CDD@red-msg-06.redmond.corp.microsoft.com> References: <7695E2F6903F7A41961F8CF888D87EA804BC4CDD@red-msg-06.redmond.corp.microsoft.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 18 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Fri, 31 May 2002 10:39:18 -0700, >>>>> "Richard Draves" said: > I'm curious about the implementation status. I know the Windows > implementation does not implement the RFC 2462 optimization - it > performs DAD on every address independently. What about other > implementations? KAME (*BSDs) does not implement the optimization either. That's intentional - we once implemented the optimization, but then we changed our mind because doing DAD for every (unicast) address is a SHOULD in RFC 2462 and we did not have any strong reason not to follow the SHOULD (at least at that moment). 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 Sat Jun 1 01:04:00 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g5183xrP010704; Sat, 1 Jun 2002 01:03:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g5183x5B010703; Sat, 1 Jun 2002 01:03:59 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g5183qrP010688; Sat, 1 Jun 2002 01:03:52 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA13462; Sat, 1 Jun 2002 01:03:52 -0700 (PDT) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.139.94]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA18079; Sat, 1 Jun 2002 02:03:45 -0600 (MDT) Received: from localhost (yoshfuji@localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (8.9.3+3.2W/8.9.3/Debian 8.9.3-21) with ESMTP id RAA21767; Sat, 1 Jun 2002 17:03:44 +0900 To: ipng@sunroof.eng.sun.com Cc: charliep@iprg.nokia.com, hesham.soliman@era.ericsson.se, mobile-ip@sunroof.eng.sun.com, richdr@microsoft.com, yoshfuji@linux-ipv6.org Subject: Re: RFC 2462 DAD optimization In-Reply-To: <7695E2F6903F7A41961F8CF888D87EA804BC4CDD@red-msg-06.redmond.corp.microsoft.com> References: <7695E2F6903F7A41961F8CF888D87EA804BC4CDD@red-msg-06.redmond.corp.microsoft.com> X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.1 (AOI) X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 90 22 65 EB 1E CF 3A D1 0B DF 80 D8 48 07 F8 94 E0 62 0E EA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20020601170344V.yoshfuji@linux-ipv6.org> Date: Sat, 01 Jun 2002 17:03:44 +0900 From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= X-Dispatcher: imput version 991025(IM133) Lines: 11 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In article <7695E2F6903F7A41961F8CF888D87EA804BC4CDD@red-msg-06.redmond.corp.microsoft.com> (at Fri, 31 May 2002 10:39:18 -0700), "Richard Draves" says: > I'm curious about the implementation status. I know the Windows > implementation does not implement the RFC 2462 optimization - it > performs DAD on every address independently. What about other > implementations? Linux / USAGI does not support DAD optimization and I don't think DAD optimization is a good idea. --yoshfuji -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 1 02:00:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g5190frP010816; Sat, 1 Jun 2002 02:00:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g5190fOF010815; Sat, 1 Jun 2002 02:00:41 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g5190brP010808 for ; Sat, 1 Jun 2002 02:00:37 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA05419 for ; Sat, 1 Jun 2002 02:00:37 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA12613 for ; Sat, 1 Jun 2002 03:01:39 -0600 (MDT) Received: from localhost ([3ffe:501:4819:2000:200:39ff:fed9:21d7]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g5190V880887; Sat, 1 Jun 2002 18:00:31 +0900 (JST) Date: Sat, 01 Jun 2002 18:01:29 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "kumaravel " Cc: ipng@sunroof.eng.sun.com Subject: Re: Zone clarification In-Reply-To: <20020522175903.22237.qmail@webmail21.rediffmail.com> References: <20020522175903.22237.qmail@webmail21.rediffmail.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 29 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On 22 May 2002 17:59:03 -0000, >>>>> "kumaravel " said: I believe draft-ietf-ipngwg-icmp-v3-02.txt and draft-ietf-ipngwg-scoping-arch-03.txt can give you the answer to all the questions. But roughly speaking, > I am new to IPv6. Forgive me if my query is too naive. > Is there any zone concept in IPv6 Addressing Architecture?? Yes. See the scoping-arch draft. > Can a packet with link local address as source address traverse > beyond link. ( Would the router in that link drop the packet??) The router will drop the packet and send an icmpv6 error to the sender. See the icmp draft. > Is there any difference between organisation local address and > site local address? (Or is there any organisation local address > defined in IPv6... or it is implementor's specific??) Yes. Organization-local is (conceptually) a larger scope than site-local. See the scoping-arch draft. 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 Sat Jun 1 18:51:38 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g521pcrP011875; Sat, 1 Jun 2002 18:51:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g521pcCc011874; Sat, 1 Jun 2002 18:51:38 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g521pVrP011859; Sat, 1 Jun 2002 18:51:31 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA28419; Sat, 1 Jun 2002 18:51:28 -0700 (PDT) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA01448; Sat, 1 Jun 2002 19:51:27 -0600 (MDT) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id EAA27500; Sun, 2 Jun 2002 04:51:19 +0300 Date: Sun, 2 Jun 2002 04:51:19 +0300 Message-Id: <200206020151.EAA27500@burp.tkv.asdf.org> From: Markku Savela To: richdr@microsoft.com CC: charliep@IPRG.nokia.com, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com In-reply-to: <7695E2F6903F7A41961F8CF888D87EA8063CED28@red-msg-06.redmond.corp.microsoft.com> (richdr@microsoft.com) Subject: Re: [mobile-ip] RE: RFC 2462 DAD optimization References: <7695E2F6903F7A41961F8CF888D87EA8063CED28@red-msg-06.redmond.corp.microsoft.com> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: "Richard Draves" > > You are basically arguing for DIID (duplicate interface-id detection) > instead of DAD (duplicate address detection), by using DAD on the > link-local address to perform DIID. I'm very much for the Unique Interface ID on a link (DIID?). I don't see any harm from such policy. It just greatly simplifies the matters. > It seems strange to me to perform DAD on a link-local address that is > not actually being used. For better or worse, it's not the architecture > that we have today and I'm not inclined to change it. It could perphaps be considered, that doing DAD (DIID) on any address on link, would automaticly also reserve the ID for all prefixes. If you don't do unique ID on link, every time a new prefix is announced by RA, there will be a flood of DAD's, as every host on the links is "dadding" their new prefix/id combinations. (And this will go on for global, site local prefixes or 6to4 prefixes. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 1 20:27:03 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g523R2rP012021; Sat, 1 Jun 2002 20:27:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g523R2M7012020; Sat, 1 Jun 2002 20:27:02 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g523QxrP012013; Sat, 1 Jun 2002 20:26:59 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA07717; Sat, 1 Jun 2002 20:27:01 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA29016; Sat, 1 Jun 2002 20:27:01 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id UAA20067; Sat, 1 Jun 2002 20:27:00 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g523R0d02372; Sat, 1 Jun 2002 20:27:00 -0700 X-mProtect: <200206020327> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdVaYcEr; Sat, 01 Jun 2002 20:26:57 PDT Message-ID: <3CF9907B.E0DBFCEB@iprg.nokia.com> Date: Sat, 01 Jun 2002 20:26:51 -0700 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Dave Thaler CC: IPng Working Group , Mobile IP Working Group Subject: Re: [mobile-ip] RE: RFC 2462 DAD optimization References: <2E33960095B58E40A4D3345AB9F65EC1047CF128@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello Dave, Actually, I would be in favor of making link-local to be the same as "subnet-local". I don't see the advantage in making any distinction. And, I think that the advantage of only having to do DAD for a single address per subnet is a very good advantage, one that turns out to be especially handy for mobile nodes while they are traveling. In fact, I would say that not having this feature is tantamount to restricting mobile nodes to a single home address. Otherwise, it gets to be too much work for the home agent. Am I missing some good feature that results from making the distinction? Regards, Charlie P. Dave Thaler wrote: > As mentioned in email I sent a week or two back, this is > related to the issue of whether a link-local address has to be > unique across an entire subnet, not just a link. Today it's > defined as a "link-local" not a "subnet-local" address. This > means that it is not guaranteed to be unique across a subnet. > > Manually configured global addresses don't need to require > rights to the corresponding link-local address since > a) it's not necessary as they don't use the link-local address, > b) it's not sufficient since they need to be unique across the > subnet, not just the link. > > So unless you're proposing we redefine "link-local" addresses > as "subnet-local" addresses (which would at least be a > consistent argument, albeit a change to the architecture), > then what you suggest does not seem to me to be the right solution. > > -Dave -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jun 1 20:41:57 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g523fvrP012138; Sat, 1 Jun 2002 20:41:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g523fuLc012137; Sat, 1 Jun 2002 20:41:56 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g523forP012122; Sat, 1 Jun 2002 20:41:50 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA15778; Sat, 1 Jun 2002 20:41:52 -0700 (PDT) Received: from changeofhabit.mr.itd.umich.edu (changeofhabit.mr.itd.umich.edu [141.211.144.17]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA20946; Sat, 1 Jun 2002 21:41:51 -0600 (MDT) Received: from SGOSWAMIPCL (dsl-65-184-63-5.telocity.com [65.184.63.5]) by changeofhabit.mr.itd.umich.edu (8.9.3/3.2r) with ESMTP id XAA03972; Sat, 1 Jun 2002 23:41:50 -0400 (EDT) From: "Dr. Subrata Goswami" Cc: , "'IPng Working Group'" Subject: RE: [mobile-ip] RE: RFC 2462 DAD optimization Date: Sat, 1 Jun 2002 20:45:32 -0700 Message-ID: <005e01c209e7$f2de5e70$6701a8c0@SGOSWAMIPCL> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <2E33960095B58E40A4D3345AB9F65EC1047CF128@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I am just curious about what are the technical differences between a link-local address and a subnet-local address. I agree with Dave that, doing a DAD for "link-local" type of post-fix address is a unnecessary restriction. 1. There might be global addresss manually configured with the same post-fix but with different pre-fix as the link-local address of a node. What would HA do if a node like that moves into its territory ? 2. For 64-bit post-fix it would render 2**64 perfectly good addresses useless. Subrata -----Original Message----- From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile-ip@sunroof.eng.sun.com] On Behalf Of Dave Thaler Sent: Friday, May 31, 2002 10:59 AM To: Charles E. Perkins; Richard Draves Cc: mobile-ip@sunroof.eng.sun.com; IPng Working Group Subject: [mobile-ip] RE: RFC 2462 DAD optimization As mentioned in email I sent a week or two back, this is related to the issue of whether a link-local address has to be unique across an entire subnet, not just a link. Today it's defined as a "link-local" not a "subnet-local" address. This means that it is not guaranteed to be unique across a subnet. Manually configured global addresses don't need to require rights to the corresponding link-local address since a) it's not necessary as they don't use the link-local address, b) it's not sufficient since they need to be unique across the subnet, not just the link. So unless you're proposing we redefine "link-local" addresses as "subnet-local" addresses (which would at least be a consistent argument, albeit a change to the architecture), then what you suggest does not seem to me to be the right solution. -Dave > -----Original Message----- > From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] > Sent: Friday, May 31, 2002 10:45 AM > To: Richard Draves > Cc: mobile-ip@sunroof.eng.sun.com; IPng Working Group > Subject: Re: RFC 2462 DAD optimization > > > Hello Richard, > > Even manually configured global addresses should be required > to acquire rights to the corresponding link-local address. Why not? > > Regards, > Charlie P. > > > Richard Draves wrote: > > > > I disagree. I think the problem is in the RFC 2462 optimization. The RFC > > 2462 optimization also can fail with manually-configured addresses - > > it's not just a problem with RFC 3041 temporary addresses. > > > > I'm curious about the implementation status. I know the Windows > > implementation does not implement the RFC 2462 optimization - it > > performs DAD on every address independently. What about other > > implementations? > > > > Rich > > > > > -----Original Message----- > > > From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] > > > Sent: Friday, May 31, 2002 10:03 AM > > > To: Hesham Soliman (ERA) > > > Cc: 'mobile-ip@sunroof.eng.sun.com '; 'IPng Working Group ' > > > Subject: Re: [mobile-ip] Issue #23 and Issue #30 > > > > > > > > > > > > Hello Hesham, > > > > > > "Hesham Soliman (ERA)" wrote: > > > > > > > => RFC 2462 makes an optimisation (not a good > > > > one IMHO) that if a node does DAD on link-local > > > > addresses, it 'owns the interface id' for any other > > > > address with any scope. > > > > > > I think this is a good idea. > > > > > > > RFC3041 says that a node can generate a new iid > > > > and does DAD for _that_ address which uses the > > > > new iid. Since this is typically not a link local > > > > address, you could get a conflict if the HA > > > > does not defend all addresses. > > > > > > The problem is that RFC 3041 should require any > > > such node to first acquire rights to the link-local > > > address. I hope that is viewed as an omission, and > > > one which can be quickly repaired. > > > > > > Regards, > > > Charlie P. > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 1 22:41:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g525fZrP012339; Sat, 1 Jun 2002 22:41:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g525fZO9012338; Sat, 1 Jun 2002 22:41:35 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g525fSrP012323; Sat, 1 Jun 2002 22:41:28 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA08178; Sat, 1 Jun 2002 22:41:29 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA13519; Sat, 1 Jun 2002 23:41:28 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id WAA22845; Sat, 1 Jun 2002 22:41:27 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g525fQ030352; Sat, 1 Jun 2002 22:41:26 -0700 X-mProtect: <200206020541> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd9kVvD0; Sat, 01 Jun 2002 22:41:24 PDT Message-ID: <3CF9AFF9.B4DC528F@iprg.nokia.com> Date: Sat, 01 Jun 2002 22:41:13 -0700 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Dr. Subrata Goswami" CC: mobile-ip@sunroof.eng.sun.com, "'IPng Working Group'" Subject: Re: [mobile-ip] RE: RFC 2462 DAD optimization References: <005e01c209e7$f2de5e70$6701a8c0@SGOSWAMIPCL> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello Subrata, I reckon I am missing your point, so here is a request for clarification: "Dr. Subrata Goswami" wrote: > I agree with Dave that, doing a DAD for "link-local" type of post-fix > address is a unnecessary restriction. The choice seems to be to do DAD once for a "link-local" or "subnet-local" address (even if the node didn't configure one (?!?)), vs. doing DAD for _every_ configured address. So, the thing you label a "restriction" seems to bring a large measure of freedom, if I understand you correctly. > 1. There might be global addresss manually configured with the same > post-fix but with different pre-fix as the link-local address of a > node. What would HA do if a node like that moves into its territory ? The HA would deny that node use of the link. This is quite unlikely to ever happen, though. > 2. For 64-bit post-fix it would render 2**64 perfectly good addresses > useless. I don't understand what you mean here. Which addresses are useless? Regards, Charlie P. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jun 2 01:05:14 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g5285DrP012545; Sun, 2 Jun 2002 01:05:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g5285CQB012544; Sun, 2 Jun 2002 01:05:12 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g52855rP012529; Sun, 2 Jun 2002 01:05:05 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA03078; Sun, 2 Jun 2002 01:05:05 -0700 (PDT) Received: from changeofhabit.mr.itd.umich.edu (changeofhabit.mr.itd.umich.edu [141.211.144.17]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA02570; Sun, 2 Jun 2002 02:05:03 -0600 (MDT) Received: from SGOSWAMIPCL (dsl-65-184-63-5.telocity.com [65.184.63.5]) by changeofhabit.mr.itd.umich.edu (8.9.3/3.2r) with ESMTP id EAA10383; Sun, 2 Jun 2002 04:05:01 -0400 (EDT) From: "Dr. Subrata Goswami" Cc: , "'IPng Working Group'" Subject: RE: [mobile-ip] RE: RFC 2462 DAD optimization Date: Sun, 2 Jun 2002 01:08:41 -0700 Message-ID: <005f01c20a0c$b65e16a0$6701a8c0@SGOSWAMIPCL> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0060_01C209D2.09FF3EA0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <3CF9AFF9.B4DC528F@iprg.nokia.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0060_01C209D2.09FF3EA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The HA would deny that node use of the link. This is quite unlikely to ever happen, though. Why is that ? I don't understand what you mean here. Which addresses are useless? Because you are ignoring the pre-fix (which can be 64 bits). -----Original Message----- From: Charlie Perkins [mailto:charliep@iprg.nokia.com] Sent: Saturday, June 01, 2002 10:41 PM To: Dr. Subrata Goswami Cc: mobile-ip@sunroof.eng.sun.com; 'IPng Working Group' Subject: Re: [mobile-ip] RE: RFC 2462 DAD optimization Hello Subrata, I reckon I am missing your point, so here is a request for clarification: "Dr. Subrata Goswami" wrote: > I agree with Dave that, doing a DAD for "link-local" type of post-fix > address is a unnecessary restriction. The choice seems to be to do DAD once for a "link-local" or "subnet-local" address (even if the node didn't configure one (?!?)), vs. doing DAD for _every_ configured address. So, the thing you label a "restriction" seems to bring a large measure of freedom, if I understand you correctly. > 1. There might be global addresss manually configured with the same > post-fix but with different pre-fix as the link-local address of a > node. What would HA do if a node like that moves into its territory ? The HA would deny that node use of the link. This is quite unlikely to ever happen, though. > 2. For 64-bit post-fix it would render 2**64 perfectly good addresses > useless. I don't understand what you mean here. Which addresses are useless? Regards, Charlie P. ------=_NextPart_000_0060_01C209D2.09FF3EA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The HA would deny that node use of the link.  This is quite = unlikely

to ever happen, = though.

 

Why is that = ?

 

 

 

I don't understand what you mean here.  Which addresses are = useless?

 

Because you are ignoring the pre-fix (which can be 64 bits).

 

 

 

 

 

-----Original Message-----
From: Charlie Perkins [mailto:charliep@iprg.nokia.com]
Sent: Saturday, June 01, 2002 10:41 = PM
To: Dr. Subrata Goswami
Cc: mobile-ip@sunroof.eng.sun.com; = 'IPng Working Group'
Subject: Re: [mobile-ip] RE: RFC 2462 DAD optimization

 

 

Hello Subrata,

 

I reckon I am missing your point, so here is a request for clarification:

 

"Dr. Subrata Goswami" = wrote:

 

> I agree with Dave that, doing a DAD for = "link-local" type of post-fix

> address is a unnecessary = restriction.

 

The choice seems to be to do DAD once for a = "link-local" or

"subnet-local" address (even if the node didn't = configure one (?!?)),

vs. doing DAD for _every_ configured = address.

 

So, the thing you label a "restriction" seems to bring = a large

measure of freedom, if I understand you = correctly.

 

> 1. There might be global addresss manually configured with = the same

> post-fix but  = with different pre-fix as the link-local address of = a

> node. What would HA do if a node like that moves into its territory  = ?

 

The HA would deny that node use of the link.  This is quite = unlikely

to ever happen, though.

 

> 2. For 64-bit post-fix it would render  2**64 perfectly good = addresses

> useless.

 

I don't understand what you mean here.  Which addresses are = useless?

 

 

Regards,

Charlie P.

 

------=_NextPart_000_0060_01C209D2.09FF3EA0-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 2 06:57:18 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g52DvIrP012952; Sun, 2 Jun 2002 06:57:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g52DvIJT012951; Sun, 2 Jun 2002 06:57:18 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g52DvErP012944; Sun, 2 Jun 2002 06:57:14 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA18185; Sun, 2 Jun 2002 06:57:14 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA29913; Sun, 2 Jun 2002 07:57:13 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g52Dutc05736; Sun, 2 Jun 2002 15:56:55 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id PAA22643; Sun, 2 Jun 2002 15:56:55 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g52DusT60120; Sun, 2 Jun 2002 15:56:54 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200206021356.g52DusT60120@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Richard Draves" cc: "Charles E. Perkins" , "Hesham Soliman (ERA)" , mobile-ip@sunroof.eng.sun.com, "IPng Working Group " Subject: Re: [mobile-ip] RFC 2462 DAD optimization In-reply-to: Your message of Fri, 31 May 2002 10:39:18 PDT. <7695E2F6903F7A41961F8CF888D87EA804BC4CDD@red-msg-06.redmond.corp.microsoft.com> Date: Sun, 02 Jun 2002 15:56:54 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: I disagree. I think the problem is in the RFC 2462 optimization. The RFC 2462 optimization also can fail with manually-configured addresses - it's not just a problem with RFC 3041 temporary addresses. => I agree: the RFC 2462 optimization is based on many implicit assumptions... We have to drop it or to respecify it clearly/cleanly. I'm curious about the implementation status. I know the Windows implementation does not implement the RFC 2462 optimization - it performs DAD on every address independently. What about other implementations? => in my implementation, DAD was done on every address with an user control to disable it (default was to enable DAD) but the autoconfig client tool didn't perform DAD (it was considered as a bug). Regards Francis.Dupont@enst-bretagne.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 Sun Jun 2 08:29:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g52FTtrP013352; Sun, 2 Jun 2002 08:29:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g52FTtXU013351; Sun, 2 Jun 2002 08:29:55 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g52FTqrP013344; Sun, 2 Jun 2002 08:29:52 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA26557; Sun, 2 Jun 2002 08:29:52 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA13383; Sun, 2 Jun 2002 09:29:51 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g52FTjc09485; Sun, 2 Jun 2002 17:29:45 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id RAA23297; Sun, 2 Jun 2002 17:29:46 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g52FTjT61255; Sun, 2 Jun 2002 17:29:45 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200206021529.g52FTjT61255@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Charles E. Perkins" cc: "Hesham Soliman (ERA)" , "'mobile-ip@sunroof.eng.sun.com '" , "'IPng Working Group '" Subject: Re: [mobile-ip] Issue #23 and Issue #30 In-reply-to: Your message of Fri, 31 May 2002 10:02:59 PDT. <3CF7ACC3.9272AFBF@iprg.nokia.com> Date: Sun, 02 Jun 2002 17:29:45 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > RFC3041 says that a node can generate a new iid > and does DAD for _that_ address which uses the > new iid. Since this is typically not a link local > address, you could get a conflict if the HA > does not defend all addresses. The problem is that RFC 3041 should require any such node to first acquire rights to the link-local address. I hope that is viewed as an omission, and one which can be quickly repaired. => this point is clearly at the advantage of the DIIDD option but don't forget a direct consequence of to choose DIIDD is the MN returning back to home should use an alternative IID (a RFC 3041 one for instance) because its `own' IDD is defended by the HA until the deregistration succeeds: this is clean, easy to implement/understand but costs a DAD (oups, a DIIDD :-) for the temporary IID check in all cases... Regards Francis.Dupont@enst-bretagne.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 Sun Jun 2 12:33:29 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g52JXSrP013563; Sun, 2 Jun 2002 12:33:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g52JXSWC013562; Sun, 2 Jun 2002 12:33:28 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g52JXPrP013555 for ; Sun, 2 Jun 2002 12:33:25 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA21358 for ; Sun, 2 Jun 2002 12:33:26 -0700 (PDT) Received: from thrintun.hactrn.net (dsl092-066-067.bos1.dsl.speakeasy.net [66.92.66.67]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA26044 for ; Sun, 2 Jun 2002 13:34:31 -0600 (MDT) Received: from thangorodrim.hactrn.net (localhost [127.0.0.1]) by thrintun.hactrn.net (Postfix) with ESMTP id 4D8711CC9 for ; Sun, 2 Jun 2002 15:33:24 -0400 (EDT) Received: from thangorodrim.hactrn.net (localhost [127.0.0.1]) by thangorodrim.hactrn.net (Postfix) with ESMTP id D5A6A5BD for ; Sun, 2 Jun 2002 12:10:10 +0000 (GMT) Date: Sun, 02 Jun 2002 14:10:10 +0200 From: Rob Austein To: IPng List Subject: Re: Mandating Route Optimization In-Reply-To: <24554.1022842443@itojun.org> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (Unebigoryòmae) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020602121010.D5A6A5BD@thangorodrim.hactrn.net> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At Fri, 31 May 2002 19:54:03 +0900, Jun-ichiro itojun Hagino wrote: > > then we will have two separate set of IPv6 nodes - without mobile-ipv6 > and with mobile-ipv6, and they cannot even ping each other. > do you feel it acceptable? I'll leave the specific issue (whether MIPv6 should be a MUST) to those who have been tracking this more closely than I have, but addressing the more general question that's lurking here: yes, this sort of thing will happen, and it will be bad, and we will have to deploy updates, and we will move on. We've done it before (eg: IPv4 CIDR, or, if you want to go further back, IPv4 subnets and before that IPv4 address classes other than class A). It's annoying, but the alternative is to wait for all the ducks to be in a row, and those quackers just won't stand still. "The software isn't finished until the last user is dead." -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 2 15:55:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g52MtnrP013661; Sun, 2 Jun 2002 15:55:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g52MtmTv013660; Sun, 2 Jun 2002 15:55:48 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g52MtfrP013645; Sun, 2 Jun 2002 15:55:41 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA25053; Sun, 2 Jun 2002 15:55:42 -0700 (PDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA09270; Sun, 2 Jun 2002 16:55:42 -0600 (MDT) Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Sun, 2 Jun 2002 15:55:41 -0700 Received: from 157.54.8.155 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 02 Jun 2002 15:55:39 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Sun, 2 Jun 2002 15:55:41 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Sun, 2 Jun 2002 15:55:40 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3590.0); Sun, 2 Jun 2002 15:55:39 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [mobile-ip] RE: RFC 2462 DAD optimization Date: Sun, 2 Jun 2002 15:55:40 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC1073840F9@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mobile-ip] RE: RFC 2462 DAD optimization Thread-Index: AcIJ58nXPGJBzaAkS1anYiXRfDqWTAAnxP6A From: "Dave Thaler" To: "Dr. Subrata Goswami" Cc: , "IPng Working Group" X-OriginalArrivalTime: 02 Jun 2002 22:55:39.0297 (UTC) FILETIME=[9D6FB910:01C20A88] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g52MtgrP013646 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > -----Original Message----- > From: Dr. Subrata Goswami [mailto:sgoswami@umich.edu] > Sent: Saturday, June 01, 2002 8:46 PM > Cc: mobile-ip@sunroof.eng.sun.com; 'IPng Working Group' > Subject: RE: [mobile-ip] RE: RFC 2462 DAD optimization > > I am just curious about what are the technical differences between a > link-local address and a subnet-local address. A subnet can cover multiple links, whenever you have some type of RA/ND proxying going on. A link-local address is unique only within a single link, and is never proxied. Today fe80::/10 and ffx2::/16 addresses are defined as being link-local. This means that two links in the same subnet can reuse the same link-local addresses. Ffx3::/16 is a subnet-local multicast range. There is no subnet-local unicast range today. Charlie is arguing that he would like to see fe80::/10 redefined as the "subnet-local" unicast range, rather than the link-local unicast range, which means that a multilink subnet router (of which a home agent is one special case) would be required to proxy ND for link-local addresses. (Personally, I think it's way too late to define fe80 as subnet-local.) Today, a multilink subnet router would have no need to do that, other than the problems resulting from anyone not doing DAD on every address - which does not appear to be a problem today. See draft-ietf-ipngwg-scoping-arch-03.txt and draft-thaler-ipngwg-multilink-subnets-02.txt for more information. > I agree with Dave that, doing a DAD for "link-local" type of post-fix > address is a unnecessary restriction. > > 1. There might be global addresss manually configured with the same > post-fix but with different pre-fix as the link-local address of a > node. What would HA do if a node like that moves into its territory ? > 2. For 64-bit post-fix it would render 2**64 perfectly good addresses > useless. > > Subrata -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 Sun Jun 2 16:13:17 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g52NDHrP013868; Sun, 2 Jun 2002 16:13:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g52NDH7U013867; Sun, 2 Jun 2002 16:13:17 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g52NDErP013860; Sun, 2 Jun 2002 16:13:14 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA20920; Sun, 2 Jun 2002 16:13:15 -0700 (PDT) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA26693; Sun, 2 Jun 2002 17:13:14 -0600 (MDT) Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Sun, 2 Jun 2002 16:13:14 -0700 Received: from 157.54.8.23 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 02 Jun 2002 16:13:13 -0700 Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Sun, 2 Jun 2002 16:13:12 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Sun, 2 Jun 2002 16:13:12 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3590.0); Sun, 2 Jun 2002 16:13:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [mobile-ip] RE: RFC 2462 DAD optimization Date: Sun, 2 Jun 2002 16:13:11 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC1073840FA@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mobile-ip] RE: RFC 2462 DAD optimization Thread-Index: AcIJ5VyRnAUz04u0QkyxrNRt2CtdewAo1k9A From: "Dave Thaler" To: "Charlie Perkins" Cc: "IPng Working Group" , "Mobile IP Working Group" X-OriginalArrivalTime: 02 Jun 2002 23:13:10.0391 (UTC) FILETIME=[0FEFF070:01C20A8B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g52NDErQ013861 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Charlie Perkins writes: > Actually, I would be in favor of making link-local to be the > same as "subnet-local". I don't see the advantage in making > any distinction. [Note: This email is not Mobile-IP specific. I'm talking about the general case, of which a home agent is a special case which corresponds to an ND proxy as defined in the multilink subnet draft.] The distinction in scope is especially important for multicast, which uses two separate ranges for link- and subnet-local today. The distinction is that link-local addresses are never forwarded by any router, and hence are always possible to use even when no multicast routing protocol is deployed. Subnet-local addresses require a routing protocol which must have some concept akin to host routes within the subnet. This is fine for multicast since multicast routing protocols already use address-specific state today, rather than multicast prefixes. For unicast, domains typically don't use host routes, and hence as noted in draft-thaler-ipngwg-multilink-subnets-02.txt, this is a difficult problem with no simple solution in the general case. (Which is why the RA/ND proxy solution that people often use is not tailored to the general case, and indeed can cause problems in the general case, leading to rules to prevent meltdown like in section 5.4 of that draft.) > And, I think that the advantage of only having > to do DAD for a single address per subnet is a very good > advantage, one that turns out to be especially handy for > mobile nodes while they are traveling. [End of explanation, begin personal opinions:] It seems to me that it's just an optimization that's not worth the complexity of creating a problem in the general case. I also don't think we should be changing the addressing architecture (specifically, redefining fe80::/10 as subnet-local) this late, especially if it can cause problems in some cases (which I believe it does, details are in Appendix A of the multilink subnet draft). > In fact, I would say that not having this feature is tantamount > to restricting mobile nodes to a single home address. > Otherwise, it gets to be too much work for the home agent. I don't understand why it's tantamount to having a single home address. Certainly one could conceivably have one home address for each of two separate home agents, without adding any additional work for each home agent, right? It's also non-obvious to me why it's too much work if there's multiple home addresses at the same home agent. Can you elaborate? -Dave > Am I missing some good feature that results from making > the distinction? > > Regards, > Charlie P. > > > Dave Thaler wrote: > > > As mentioned in email I sent a week or two back, this is > > related to the issue of whether a link-local address has to be > > unique across an entire subnet, not just a link. Today it's > > defined as a "link-local" not a "subnet-local" address. This > > means that it is not guaranteed to be unique across a subnet. > > > > Manually configured global addresses don't need to require > > rights to the corresponding link-local address since > > a) it's not necessary as they don't use the link-local address, > > b) it's not sufficient since they need to be unique across the > > subnet, not just the link. > > > > So unless you're proposing we redefine "link-local" addresses > > as "subnet-local" addresses (which would at least be a > > consistent argument, albeit a change to the architecture), > > then what you suggest does not seem to me to be the right solution. > > > > -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 Sun Jun 2 16:33:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g52NX9rP014098; Sun, 2 Jun 2002 16:33:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g52NX931014097; Sun, 2 Jun 2002 16:33:09 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g52NX2rP014082; Sun, 2 Jun 2002 16:33:02 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA22900; Sun, 2 Jun 2002 16:33:03 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA00021; Sun, 2 Jun 2002 17:33:02 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA18327; Sun, 2 Jun 2002 16:33:02 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g52NX1v14756; Sun, 2 Jun 2002 16:33:01 -0700 X-mProtect: <200206022333> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdhvjuXe; Sun, 02 Jun 2002 16:33:00 PDT Message-ID: <3CFAAB2C.B7CA5661@iprg.nokia.com> Date: Sun, 02 Jun 2002 16:33:00 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Dave Thaler CC: mobile-ip@sunroof.eng.sun.com, IPng Working Group Subject: Re: [mobile-ip] RE: RFC 2462 DAD optimization References: <2E33960095B58E40A4D3345AB9F65EC1073840F9@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dave Thaler wrote: > Ffx3::/16 is a subnet-local multicast range. There is no > subnet-local unicast range today. Charlie is arguing that he would > like to see fe80::/10 redefined as the "subnet-local" unicast > range, rather than the link-local unicast range, which means > that a multilink subnet router (of which a home agent is one > special case) would be required to proxy ND for link-local addresses. > (Personally, I think it's way too late to define fe80 as subnet-local.) > > Today, a multilink subnet router would have no need to do that, > other than the problems resulting from anyone not doing DAD on > every address - which does not appear to be a problem today. Today there aren't any problems, but that's because nobody is using very many subnet prefixes on the same {,multi-}link. I think the current design decision essentially codifies that, at least for mobile nodes. Is that the intended result? Another possibility would be to declare that on any link that has the capability to support mobility agents, a link-local address semantically has to be same as a subnet-local address. This would require extra work from the multi-link proxy agent, but would make the life of network administrators much easier since my suggested design choice is much simpler to understand. In fact, I would argue that the current "architecture" of link-local addresses as you have detailed it is wrong, because it's not in the realm of layer-3 design. I'll have to work out the implications for multicast later, but my initial impression is that it's workable. I also owe you more text about why it's a lot of work for home agents. Regards, Charlie P. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jun 2 16:38:50 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g52NcnrP014198; Sun, 2 Jun 2002 16:38:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g52NcnXl014197; Sun, 2 Jun 2002 16:38:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g52NcjrP014190; Sun, 2 Jun 2002 16:38:45 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA23319; Sun, 2 Jun 2002 16:38:47 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA18203; Sun, 2 Jun 2002 17:38:45 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id D65864B24; Mon, 3 Jun 2002 08:38:40 +0900 (JST) To: "Charles E. Perkins" Cc: mobile-ip@sunroof.eng.sun.com, IPng Working Group In-reply-to: charliep's message of Sun, 02 Jun 2002 16:33:00 MST. <3CFAAB2C.B7CA5661@iprg.nokia.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: [mobile-ip] RE: RFC 2462 DAD optimization From: itojun@iijlab.net Date: Mon, 03 Jun 2002 08:38:40 +0900 Message-ID: <2212.1023061120@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Today there aren't any problems, but that's because nobody >is using very many subnet prefixes on the same {,multi-}link. >I think the current design decision essentially codifies that, >at least for mobile nodes. Is that the intended result? (just for clarifications, not sure if it is related to the discussion) i don't quite parse the above paragraph. there are a lot of links where we assign multiple subnet prefixes (different /64 from different upstream ISP). it is useful, for example, for RFC3178. also, if you are willing to use router renumbering and such, a /64 prefix out of fec0::/48 range will be added too. 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 Sun Jun 2 16:43:42 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g52NhgrP014304; Sun, 2 Jun 2002 16:43:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g52Nhg4D014303; Sun, 2 Jun 2002 16:43:42 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g52NhZrP014288; Sun, 2 Jun 2002 16:43:35 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA03629; Sun, 2 Jun 2002 16:43:35 -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 RAA02083; Sun, 2 Jun 2002 17:43:34 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA18612; Sun, 2 Jun 2002 16:43:34 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g52NhYK22703; Sun, 2 Jun 2002 16:43:34 -0700 X-mProtect: <200206022343> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdkhMxvd; Sun, 02 Jun 2002 16:43:32 PDT Message-ID: <3CFAADA4.F74461E5@iprg.nokia.com> Date: Sun, 02 Jun 2002 16:43:32 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: itojun@iijlab.net CC: mobile-ip@sunroof.eng.sun.com, IPng Working Group Subject: Re: [mobile-ip] RE: RFC 2462 DAD optimization References: <2212.1023061120@itojun.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk itojun@iijlab.net wrote: > there are a lot of links where we assign multiple subnet prefixes > (different /64 from different upstream ISP). it is useful, for example, > for RFC3178. also, if you are willing to use router renumbering > and such, a /64 prefix out of fec0::/48 range will be added too. This is interesting information. Can you say how many prefixes are typically advertised? Regards, Charlie P. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jun 2 16:47:43 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g52NlhrP014397; Sun, 2 Jun 2002 16:47:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g52NlhC3014396; Sun, 2 Jun 2002 16:47:43 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g52NldrP014389; Sun, 2 Jun 2002 16:47:39 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA12283; Sun, 2 Jun 2002 16:47:41 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA11565; Sun, 2 Jun 2002 16:47:40 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 70DA14B25; Mon, 3 Jun 2002 08:47:36 +0900 (JST) To: "Charles E. Perkins" Cc: mobile-ip@sunroof.eng.sun.com, IPng Working Group In-reply-to: charliep's message of Sun, 02 Jun 2002 16:43:32 MST. <3CFAADA4.F74461E5@iprg.nokia.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: [mobile-ip] RE: RFC 2462 DAD optimization From: itojun@iijlab.net Date: Mon, 03 Jun 2002 08:47:36 +0900 Message-ID: <2285.1023061656@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> there are a lot of links where we assign multiple subnet prefixes >> (different /64 from different upstream ISP). it is useful, for example, >> for RFC3178. also, if you are willing to use router renumbering >> and such, a /64 prefix out of fec0::/48 range will be added too. >This is interesting information. Can you say how many prefixes >are typically advertised? not sure about "typically", but around 3 to 5 prefixes are advertised in my office, another office, and home. at past IETFs and ipngwg interim meetings, we advertised 2 or 3 prefixes because we were multi-homed. so pls do not assume that there's single subnet prefix on a link. 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 Sun Jun 2 16:59:01 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g52Nx1rP014538; Sun, 2 Jun 2002 16:59:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g52Nx0lv014537; Sun, 2 Jun 2002 16:59:00 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g52NwrrP014519; Sun, 2 Jun 2002 16:58:53 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA06042; Sun, 2 Jun 2002 16:58:54 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA13009; Sun, 2 Jun 2002 18:00:00 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA18962; Sun, 2 Jun 2002 16:58:53 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g52Nwro31414; Sun, 2 Jun 2002 16:58:53 -0700 X-mProtect: <200206022358> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpduKeJB7; Sun, 02 Jun 2002 16:58:51 PDT Message-ID: <3CFAB13C.5B1AC3B7@iprg.nokia.com> Date: Sun, 02 Jun 2002 16:58:52 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: itojun@iijlab.net CC: mobile-ip@sunroof.eng.sun.com, IPng Working Group Subject: Re: [mobile-ip] RE: RFC 2462 DAD optimization References: <2285.1023061656@itojun.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello Itojun, itojun@iijlab.net wrote: > not sure about "typically", but around 3 to 5 prefixes are advertised > in my office, another office, and home. at past IETFs and ipngwg > interim meetings, we advertised 2 or 3 prefixes because we were > multi-homed. so pls do not assume that there's single subnet prefix > on a link. My guess is that you are using this feature more than most IPv6 installations. But anyway, it's not 20 or even a dozen prefixes. Is it reasonable for us to assume that, for most links, the number of advertised prefixes will never exceed 10? 7? I never meant to make the assumption that a links would see only a single advertised prefix. I had thought that most installations were not using the feature very heavily, and that 1 or 2 would be the typical number of prefixes advertised. Now you point out that there are some with up to 5. This is good to know. I wonder if we can get to the point of agreeing on a maximum for all future applications, so that we can agree to avoid designing for problems of scalability that won't exist over the lifetime of IPv6. Regards, Charlie P. PS. Please let me know what I can do to clarify any parsing issues in the above or any previous notes. I am not trying to be writing mysteries or puzzles. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 2 17:07:36 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g5307ZrP014628; Sun, 2 Jun 2002 17:07:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g5307Z8s014627; Sun, 2 Jun 2002 17:07:35 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g5307VrP014620; Sun, 2 Jun 2002 17:07:31 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA25686; Sun, 2 Jun 2002 17:07:33 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA14717; Sun, 2 Jun 2002 18:08:38 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id A821A4B24; Mon, 3 Jun 2002 09:07:25 +0900 (JST) To: "Charles E. Perkins" Cc: mobile-ip@sunroof.eng.sun.com, IPng Working Group In-reply-to: charliep's message of Sun, 02 Jun 2002 16:58:52 MST. <3CFAB13C.5B1AC3B7@iprg.nokia.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: [mobile-ip] RE: RFC 2462 DAD optimization From: itojun@iijlab.net Date: Mon, 03 Jun 2002 09:07:25 +0900 Message-ID: <2462.1023062845@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> not sure about "typically", but around 3 to 5 prefixes are advertised >> in my office, another office, and home. at past IETFs and ipngwg >> interim meetings, we advertised 2 or 3 prefixes because we were >> multi-homed. so pls do not assume that there's single subnet prefix >> on a link. >My guess is that you are using this feature more than most IPv6 >installations. But anyway, it's not 20 or even a dozen prefixes. >Is it reasonable for us to assume that, for most links, the number >of advertised prefixes will never exceed 10? 7? we never know what the future operators will do, so it is safer not to make assumptions. 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 Sun Jun 2 17:20:34 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g530KYrP014733; Sun, 2 Jun 2002 17:20:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g530KXhj014732; Sun, 2 Jun 2002 17:20: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.12.3+Sun/8.12.3) with ESMTP id g530KQrP014717; Sun, 2 Jun 2002 17:20:26 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA09304; Sun, 2 Jun 2002 17:20:28 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA27039; Sun, 2 Jun 2002 18:20:27 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id RAA20022; Sun, 2 Jun 2002 17:20:27 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g530KQ910114; Sun, 2 Jun 2002 17:20:26 -0700 X-mProtect: <200206030020> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdgs8M5O; Sun, 02 Jun 2002 17:20:25 PDT Message-ID: <3CFAB649.45AF7391@iprg.nokia.com> Date: Sun, 02 Jun 2002 17:20:25 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: itojun@iijlab.net CC: mobile-ip@sunroof.eng.sun.com, IPng Working Group Subject: Re: [mobile-ip] RE: RFC 2462 DAD optimization References: <2462.1023062845@itojun.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk itojun@iijlab.net wrote: >> Is it reasonable for us to assume that, for most links, the number >> of advertised prefixes will never exceed 10? 7? > > we never know what the future operators will do, so it is safer > not to make assumptions. In that case, I think we have to do something to avoid doing DAD for all those prefixes. One solution would be to just do it for link-local prefixes, which according to Dave Thaler's argument then become subnet-local prefixes. Regards, Charlie P. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jun 2 17:23:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g530NerP014801; Sun, 2 Jun 2002 17:23:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g530NeL7014800; Sun, 2 Jun 2002 17:23:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g530NbrP014793; Sun, 2 Jun 2002 17:23:37 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA09715; Sun, 2 Jun 2002 17:23:36 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA27730; Sun, 2 Jun 2002 18:23:35 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id D9AA54B24; Mon, 3 Jun 2002 09:23:29 +0900 (JST) To: "Charles E. Perkins" Cc: mobile-ip@sunroof.eng.sun.com, IPng Working Group In-reply-to: charliep's message of Sun, 02 Jun 2002 17:20:25 MST. <3CFAB649.45AF7391@iprg.nokia.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: [mobile-ip] RE: RFC 2462 DAD optimization From: itojun@iijlab.net Date: Mon, 03 Jun 2002 09:23:29 +0900 Message-ID: <2625.1023063809@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> we never know what the future operators will do, so it is safer >> not to make assumptions. >In that case, I think we have to do something to avoid doing DAD >for all those prefixes. One solution would be to just do it for >link-local prefixes, which according to Dave Thaler's argument >then become subnet-local prefixes. i don't think it necessary to do anything about DAD. we perform DAD (not DIIDD) for all addresses assigned, and we will be fine. 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 Sun Jun 2 17:36:34 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g530aYrP014939; Sun, 2 Jun 2002 17:36:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g530aYrS014938; Sun, 2 Jun 2002 17:36:34 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g530aRrP014923; Sun, 2 Jun 2002 17:36:27 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA28340; Sun, 2 Jun 2002 17:36:26 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA20594; Sun, 2 Jun 2002 17:36:25 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id RAA20399; Sun, 2 Jun 2002 17:36:25 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g530aOU18979; Sun, 2 Jun 2002 17:36:24 -0700 X-mProtect: <200206030036> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdnTDBrd; Sun, 02 Jun 2002 17:36:21 PDT Message-ID: <3CFABA06.79CF83E4@iprg.nokia.com> Date: Sun, 02 Jun 2002 17:36:22 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: itojun@iijlab.net CC: mobile-ip@sunroof.eng.sun.com, IPng Working Group , Dave Thaler Subject: Re: [mobile-ip] RE: RFC 2462 DAD optimization References: <2625.1023063809@itojun.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello itojun, itojun@iijlab.net wrote: > >> we never know what the future operators will do, so it is safer > >> not to make assumptions. > >In that case, I think we have to do something to avoid doing DAD > >for all those prefixes. One solution would be to just do it for > >link-local prefixes, which according to Dave Thaler's argument > >then become subnet-local prefixes. > > i don't think it necessary to do anything about DAD. we perform DAD > (not DIIDD) for all addresses assigned, and we will be fine. Do you still think that is true if the mobile node has to send out 10, or some unbounded number, of Binding Updates each time it changes its care-of address? The discussion in the mobile-ip group is whether a single Binding Update can suffice for all home addresses of a mobile node that share the same interface ID. This led to discussion about DAD. The subjects are not inseparably intertwined, but there is a relationship. It has been my understanding that a home agent, charged with the protocol responsibility for defending the addresses of 4,095 mobile nodes (or, say, 500,000 for some cellular plans), would effectively disable the ability of mobile nodes to use multiple prefixes, because equipment vendors would just "say no" if they thought only a few mobile nodes would use this feature. Thus, I thought that it would be a lot better to have a very simple scaling mechanism that would still allow for a large number of prefixes. This is simple, if the home agent can just defend the link-local prefix. It's not so simple if any increase in the number of advertised prefixes requires a linear increase in storage or performance requirements at the home agent. It's really quite bad if the communication requirement at the mobile node experiences a linear increase in capacity requirement at handover time. My guess is that it will just effectively mean people will not use multiple prefixes for mobile nodes. Regards, Charlie P. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jun 2 17:47:04 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g530l4rP015044; Sun, 2 Jun 2002 17:47:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g530l4YV015043; Sun, 2 Jun 2002 17:47:04 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g530l1rP015036 for ; Sun, 2 Jun 2002 17:47:01 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA13267 for ; Sun, 2 Jun 2002 17:47:00 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA16821 for ; Sun, 2 Jun 2002 18:46:59 -0600 (MDT) Message-ID: <003e01c20a97$edf45f30$236015ac@T23KEMPF> From: "James Kempf" To: , "OKABE Nobuo" References: <2913.1022841116@munnari.OZ.AU><24554.1022842443@itojun.org> <20020601.003521.108735690.nov@tahi.org> Subject: Re: Mandating Route Optimization Date: Sun, 2 Jun 2002 17:45:12 -0700 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 Okabe-san, Good observation. I believe we have the rough concensus (in the MIP group at least). The running code is needed yet. jak ----- Original Message ----- From: "OKABE Nobuo" To: Sent: Friday, May 31, 2002 8:35 AM Subject: Re: Mandating Route Optimization > From: itojun@iijlab.net > Subject: Re: Mandating Route Optimization > Date: Fri, 31 May 2002 19:54:03 +0900 > > > >But we can not, now or ever, allow considerations of existing implementations > > >conformance state affect the decisions about what new implementations > > >should be required to implement. > > > > then we will have two separate set of IPv6 nodes - without mobile-ipv6 > > and with mobile-ipv6, and they cannot even ping each other. > > do you feel it acceptable? > > > > i'm very unhappy about the delay of mobile-ipv6 spec. it should have > > defined home address option, set it in stone, and then work on other > > things. implementers cannot support (human resource-wise) drafts > > that drastically change content every time the new version appears. > > even if that technology is a good one, this way that won't deploy. > > How should we apply the IETF motto, e.g. "rough consensus and running code", > (especially latter words) in this case? ^^^^^^^^^^^^ > > If mip6 people shows experience and validity about route optimization > based upon running code, we will be able to have more productive > discussion. > > thanks, > > ---- nobuo > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jun 2 17:54:52 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g530sqrP015063; Sun, 2 Jun 2002 17:54:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g530sqNO015062; Sun, 2 Jun 2002 17:54:52 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g530snrP015055 for ; Sun, 2 Jun 2002 17:54:49 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA19203 for ; Sun, 2 Jun 2002 17:54:49 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA05311 for ; Sun, 2 Jun 2002 18:54:48 -0600 (MDT) Message-ID: <005d01c20a99$00e077e0$236015ac@T23KEMPF> From: "James Kempf" To: "Charles E. Perkins" , Cc: References: <0C1353ABB1DEB74DB067ADFF749C4EEFC652DC@esebe004.NOE.Nokia.com> <3CF7A99F.397DB16B@iprg.nokia.com> Subject: Re: Mandating Route Optimization Date: Sun, 2 Jun 2002 17:52:52 -0700 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 Hi Charlie, One reason might be that the correspondent node has detected an attempt to divert traffic to a node which does not legitimately possess the home address is is trying to divert from. A sysadmin might want to shut off route optimization until the attacker was discovered or gave up. jak ----- Original Message ----- From: "Charles E. Perkins" To: Cc: Sent: Friday, May 31, 2002 9:49 AM Subject: Re: Mandating Route Optimization > > Hello John, > > john.loughney@nokia.com wrote: > > > I do think that additional work > > will be needed to detail how RO is used, if there > > is a need for protocol negotiation, etc. I think > > that the important thing is to have a strong > > statement of support for implementing RO. How > > RO is used probably needs some real deployment > > experience, etc. I think that RO needs to be > > implemented, but its use is probably still open > > to local control, etc. > > If there is any issue here, it is mainly a matter > of allowing mobile nodes to hide their location. > That's simple -- the node should simply do reverse > tunneling, and not issue HoTI and CoTI. > > I can't imagine a reason why a correspondent node > would prefer to have traffic going through the > home network rather than directly to its mobile > communications partner, but if there is a reason, > then certainly the correspondent node can simply > avoid sending HoT and CoT. > > Even with HoTI, CoTI, HoT, CoT, and BU mandated > for implementation, the mobile nodes still have > to correctly and courteously handle the cases > where HoT and CoT and even Binding Error messages > are never received. > > I hope these matters will be viewed as specified > clearly. Anywhere they are not, we should fix. > > Regards, > Charlie P. > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 2 17:55:05 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g530t5rP015073; Sun, 2 Jun 2002 17:55:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g530t5OR015072; Sun, 2 Jun 2002 17:55:05 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g530sxrP015065; Sun, 2 Jun 2002 17:54:59 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA14371; Sun, 2 Jun 2002 17:54:59 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA00381; Sun, 2 Jun 2002 17:54:58 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id A2F9F4B24; Mon, 3 Jun 2002 09:54:54 +0900 (JST) To: "Charles E. Perkins" Cc: mobile-ip@sunroof.eng.sun.com, IPng Working Group , Dave Thaler In-reply-to: charliep's message of Sun, 02 Jun 2002 17:36:22 MST. <3CFABA06.79CF83E4@iprg.nokia.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: [mobile-ip] RE: RFC 2462 DAD optimization From: itojun@iijlab.net Date: Mon, 03 Jun 2002 09:54:54 +0900 Message-ID: <2905.1023065694@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >My guess is that it will just effectively mean people will not >use multiple prefixes for mobile nodes. i guess so too, and therefore, i don't feel a need to provide special hack in DAD. it is not a protocol issue, but an operational matter. 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 Sun Jun 2 18:39:42 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g531dgrP015195; Sun, 2 Jun 2002 18:39:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g531dgAj015194; Sun, 2 Jun 2002 18:39:42 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g531dcrP015187 for ; Sun, 2 Jun 2002 18:39:38 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA22925 for ; Sun, 2 Jun 2002 18:39:38 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA06686 for ; Sun, 2 Jun 2002 18:39:38 -0700 (PDT) Message-ID: <018e01c20a9f$4a820cf0$236015ac@T23KEMPF> From: "James Kempf" To: "James Kempf" , , "OKABE Nobuo" References: <2913.1022841116@munnari.OZ.AU><24554.1022842443@itojun.org> <20020601.003521.108735690.nov@tahi.org> <003e01c20a97$edf45f30$236015ac@T23KEMPF> Subject: Re: Mandating Route Optimization Date: Sun, 2 Jun 2002 18:37:52 -0700 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 So there seems to be some confusion about my statements concerning route optimization, expressed to me in private email by some WG members. Let me clarify that they are being made with my WG member hat on, both in MIP and IPNG. My IAB hat remains on the hat tree. :-) Sorry for any confusion. jak ----- Original Message ----- From: "James Kempf" To: ; "OKABE Nobuo" Sent: Sunday, June 02, 2002 5:45 PM Subject: Re: Mandating Route Optimization > Okabe-san, > > Good observation. I believe we have the rough concensus (in the MIP > group at least). The running code is needed yet. > > jak > > ----- Original Message ----- > From: "OKABE Nobuo" > To: > Sent: Friday, May 31, 2002 8:35 AM > Subject: Re: Mandating Route Optimization > > > > From: itojun@iijlab.net > > Subject: Re: Mandating Route Optimization > > Date: Fri, 31 May 2002 19:54:03 +0900 > > > > > >But we can not, now or ever, allow considerations of existing > implementations > > > >conformance state affect the decisions about what new > implementations > > > >should be required to implement. > > > > > > then we will have two separate set of IPv6 nodes - without > mobile-ipv6 > > > and with mobile-ipv6, and they cannot even ping each other. > > > do you feel it acceptable? > > > > > > i'm very unhappy about the delay of mobile-ipv6 spec. it should > have > > > defined home address option, set it in stone, and then work on other > > > things. implementers cannot support (human resource-wise) drafts > > > that drastically change content every time the new version appears. > > > even if that technology is a good one, this way that won't deploy. > > > > How should we apply the IETF motto, e.g. "rough consensus and running > code", > > (especially latter words) in this case? > ^^^^^^^^^^^^ > > > > If mip6 people shows experience and validity about route optimization > > based upon running code, we will be able to have more productive > > discussion. > > > > thanks, > > > > ---- nobuo > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home 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 Sun Jun 2 18:58:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g531wjrP015214; Sun, 2 Jun 2002 18:58:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g531wjsY015213; Sun, 2 Jun 2002 18:58:45 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g531wfrP015206 for ; Sun, 2 Jun 2002 18:58:41 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA24571 for ; Sun, 2 Jun 2002 18:58:32 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA20474 for ; Sun, 2 Jun 2002 19:58:31 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id SAA22272; Sun, 2 Jun 2002 18:58:31 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g531wVH11460; Sun, 2 Jun 2002 18:58:31 -0700 X-mProtect: <200206030158> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdo0cYYi; Sun, 02 Jun 2002 18:58:27 PDT Message-ID: <3CFACD3C.37887B48@iprg.nokia.com> Date: Sun, 02 Jun 2002 18:58:20 -0700 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: ipng@sunroof.eng.sun.com Subject: Re: Mandating Route Optimization References: <2913.1022841116@munnari.OZ.AU><24554.1022842443@itojun.org> <20020601.003521.108735690.nov@tahi.org> <003e01c20a97$edf45f30$236015ac@T23KEMPF> <018e01c20a9f$4a820cf0$236015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello James, In addition to whatever private mail expressions you may have received, I should point out that it is highly inappropriate for working group members in one working group to supply possibly biased information about the general state of consensus in another working group. I would say that the discussion is far from settled. In fact we are in the middle of it. Regards, Charlie P. James Kempf wrote: > So there seems to be some confusion about my statements concerning route > optimization, expressed to me in private email by some WG members. > > Let me clarify that they are being made with my WG member hat on, both > in MIP and IPNG. My IAB hat remains on the hat tree. :-) > > Sorry for any confusion. > > jak > > ----- Original Message ----- > From: "James Kempf" > To: ; "OKABE Nobuo" > Sent: Sunday, June 02, 2002 5:45 PM > Subject: Re: Mandating Route Optimization > > > Okabe-san, > > > > Good observation. I believe we have the rough concensus (in the MIP > > group at least). The running code is needed yet. > > > > jak > > > > ----- Original Message ----- > > From: "OKABE Nobuo" > > To: > > Sent: Friday, May 31, 2002 8:35 AM > > Subject: Re: Mandating Route Optimization > > > > > > > From: itojun@iijlab.net > > > Subject: Re: Mandating Route Optimization > > > Date: Fri, 31 May 2002 19:54:03 +0900 > > > > > > > >But we can not, now or ever, allow considerations of existing > > implementations > > > > >conformance state affect the decisions about what new > > implementations > > > > >should be required to implement. > > > > > > > > then we will have two separate set of IPv6 nodes - without > > mobile-ipv6 > > > > and with mobile-ipv6, and they cannot even ping each other. > > > > do you feel it acceptable? > > > > > > > > i'm very unhappy about the delay of mobile-ipv6 spec. it should > > have > > > > defined home address option, set it in stone, and then work on > other > > > > things. implementers cannot support (human resource-wise) drafts > > > > that drastically change content every time the new version > appears. > > > > even if that technology is a good one, this way that won't deploy. > > > > > > How should we apply the IETF motto, e.g. "rough consensus and > running > > code", > > > (especially latter words) in this case? > > ^^^^^^^^^^^^ > > > > > > If mip6 people shows experience and validity about route > optimization > > > based upon running code, we will be able to have more productive > > > discussion. > > > > > > thanks, > > > > > > ---- nobuo > > > -------------------------------------------------------------------- > > > IETF IPng Working Group Mailing List > > > IPng Home 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 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 2 19:11:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g532B8rP015240; Sun, 2 Jun 2002 19:11:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g532B8Rb015239; Sun, 2 Jun 2002 19:11:08 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g532B4rP015232; Sun, 2 Jun 2002 19:11:04 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA07924; Sun, 2 Jun 2002 19:11:05 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA13223; Sun, 2 Jun 2002 20:12:10 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5328JM11099; Sun, 2 Jun 2002 22:08:19 -0400 (EDT) Message-Id: <200206030208.g5328JM11099@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Charles E. Perkins" cc: itojun@iijlab.net, mobile-ip@sunroof.eng.sun.com, IPng Working Group Subject: Re: [mobile-ip] RE: RFC 2462 DAD optimization In-reply-to: (Your message of "Sun, 02 Jun 2002 16:58:52 PDT.") <3CFAB13C.5B1AC3B7@iprg.nokia.com> Date: Sun, 02 Jun 2002 22:08:19 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > My guess is that you are using this feature more than most IPv6 > installations. But anyway, it's not 20 or even a dozen prefixes. > Is it reasonable for us to assume that, for most links, the number > of advertised prefixes will never exceed 10? 7? any number of prefixes is probably okay as far as applications are concerned, PROVIDED that all prefixes are equally valid - i.e. any address is as good as any other, and applications aren't expected to pick the "right" prefix in order to be able to interoperate. If this condition does not hold, even two prefixes is too many. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jun 2 19:55:40 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g532terP015376; Sun, 2 Jun 2002 19:55:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g532teHF015375; Sun, 2 Jun 2002 19: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g532tbrP015368 for ; Sun, 2 Jun 2002 19:55:37 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA12817 for ; Sun, 2 Jun 2002 19:55:38 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA23859 for ; Sun, 2 Jun 2002 20:56:43 -0600 (MDT) Message-ID: <01e401c20aa9$e669a830$236015ac@T23KEMPF> From: "James Kempf" To: "Charlie Perkins" Cc: References: <2913.1022841116@munnari.OZ.AU><24554.1022842443@itojun.org> <20020601.003521.108735690.nov@tahi.org> <003e01c20a97$edf45f30$236015ac@T23KEMPF> <018e01c20a9f$4a820cf0$236015ac@T23KEMPF> <3CFACD3C.37887B48@iprg.nokia.com> Subject: Re: Mandating Route Optimization Date: Sun, 2 Jun 2002 19:53:50 -0700 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 Hello Charles, > In addition to whatever private mail expressions you may have received, > I should point out that it is highly inappropriate for working group members > > in one working group to supply possibly biased information about the > general state of consensus in another working group. I would say that > the discussion is far from settled. In fact we are in the middle of it. > No disagreement about where the discussion is, everything is completely open. Also, you are correct in that it is up to the WG chairs to judge whether WG concensus has been met or not. Folks should check with the MIP group chairs for the status there. Now, about implementation. Are you aware of any implementations for the new security algorithm? If there are any, what is the state of their interoperability? jak -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 2 22:03:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g5353erP015475; Sun, 2 Jun 2002 22:03:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g5353eMn015474; Sun, 2 Jun 2002 22:03:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g5353brP015467 for ; Sun, 2 Jun 2002 22:03:37 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA28537 for ; Sun, 2 Jun 2002 22:03:38 -0700 (PDT) Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA13786 for ; Sun, 2 Jun 2002 23:03:37 -0600 (MDT) Received: from ns.iij.ad.jp ([192.168.2.111]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id OAA05122; Mon, 3 Jun 2002 14:03:36 +0900 (JST) Received: from localhost (keiichi01.osaka.iij.ad.jp [192.168.65.66]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id OAA09333; Mon, 3 Jun 2002 14:03:35 +0900 (JST) Date: Mon, 03 Jun 2002 14:03:03 +0900 (JST) Message-Id: <20020603.140303.67979866.keiichi@iij.ad.jp> To: vijayd@IPRG.nokia.com Cc: ipng@sunroof.eng.sun.com Subject: Re: Mandating Route Optimization From: Keiichi SHIMA / =?iso-2022-jp?B?GyRCRWc3RDBsGyhC?= In-Reply-To: <3CF6C09A.7214595A@iprg.nokia.com> References: <20020530.171405.08368244.keiichi@iij.ad.jp> <3CF65DCB.7939B84@iprg.nokia.com> <3CF6C09A.7214595A@iprg.nokia.com> X-Mailer: Mew version 3.0.55 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, From: Vijay Devarapalli > sorry about the earlier mail. I realised it was rude and not > called for. No. Never mind. (I'm afraid my poor wording may make people feel uncomfortable...) > I will try to rephrase what I said. the CN implementation as it > is described in draft-17 is quite simple (IMO). a lot of care was > taken to make the CN as stateless as possible (at the cost of > extra work by the MN). (As I said in a private email,) The stability is a problem for the implementors. Please note, I'm not saying that the current RO/RR is bad. I like RO and the current draft seems OK but should we have more time to check it? If we find a new method for RO and obsolete RR, how do we handle already shipped RR based implementation? There may be a problem. For example, we had (unverified) HAO in old drafts. Some implementation support us and implement it. But it (unverified HAO) is now obsoleted. I think it is too early to make it MUST. It is not too late after all of MIP6 vendors implement the draft and experient several interop tests and all of us are convinced it is OK to go. Best Regards, --- Keiichi SHIMA IIJ Research Laboratory KAME Project -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jun 2 22:35:59 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g535ZxrP015513; Sun, 2 Jun 2002 22:35:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g535Zx1i015512; Sun, 2 Jun 2002 22:35:59 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g535ZurP015505 for ; Sun, 2 Jun 2002 22:35:56 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA03764 for ; Sun, 2 Jun 2002 22:35:57 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA22620 for ; Sun, 2 Jun 2002 23:35:56 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id WAA28303; Sun, 2 Jun 2002 22:35:48 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g535ZlU18474; Sun, 2 Jun 2002 22:35:47 -0700 X-mProtect: <200206030535> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpduHov1f; Sun, 02 Jun 2002 22:35:45 PDT Message-ID: <3CFB0024.45F2CFA6@iprg.nokia.com> Date: Sun, 02 Jun 2002 22:35:32 -0700 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: Mandating Route Optimization References: <20020530.171405.08368244.keiichi@iij.ad.jp> <3CF65DCB.7939B84@iprg.nokia.com> <3CF6C09A.7214595A@iprg.nokia.com> <20020603.140303.67979866.keiichi@iij.ad.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, Keiichi SHIMA / $BEg7D0l(B wrote: > Please note, I'm not saying that the current RO/RR is bad. I like RO > and the current draft seems OK but should we have more time to check > it? Return routability, in general, has been under discussion for well over a year. I think the basic idea came up over 18 months ago. Then there was BAKE and several other drafts. Then there was bu3way. Some of these have been implemented. The basic ideas are pretty well understood, and as with any protocol more experience will further improve our knowledge. > If we find a new method for RO and obsolete RR, how do we handle > already shipped RR based implementation? There may be a problem. For > example, we had (unverified) HAO in old drafts. Some implementation > support us and implement it. But it (unverified HAO) is now > obsoleted. This is a very long story. Until a protocol specification reaches proposed standard, implementations are at risk of becoming obsolete -- even after that. This has happened with practically every protocol I can think of, to some degree or another. For instance, even with IPv6, the planned TLA and SLA bits are now obsolete, even though they were planned out for a long time. To make an analogy, if you wait for the fastest processor technology before buying, you will never buy, because there is always something better on the horizon. At least we can make for compatibility, though. In this circumstance, it is a lot easier to _not use_ return routability if something else turns up, than it is to _use_ return routability, if it is not mandated. I have made several arguments why it should be mandated, and as best I can tell the strongest counterargument is that it's not standard yet, so how can we mandate it? I believe this to be a circular argument. > I think it is too early to make it MUST. It is not too late after all > of MIP6 vendors implement the draft and experient several interop > tests and all of us are convinced it is OK to go. If the behavior is mandated, and something goes wrong, I reckon we'll have to revise our understanding in the future. As it is now, it's the best we know, and it's pretty well understood. Everyone believes we will have something better in the future, and so I am trying my best to make sure the protocol is extensible for that future optimization. Regards, Charlie P. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jun 2 22:36:55 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g535atrP015530; Sun, 2 Jun 2002 22:36:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g535asM4015529; Sun, 2 Jun 2002 22:36:54 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g535aorP015522 for ; Sun, 2 Jun 2002 22:36:50 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA03870 for ; Sun, 2 Jun 2002 22:36:51 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA27587 for ; Sun, 2 Jun 2002 22:36:43 -0700 (PDT) Received: from localhost ([3ffe:501:4819:2000:200:39ff:fed9:21d7]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g535aR892123; Mon, 3 Jun 2002 14:36:27 +0900 (JST) Date: Mon, 03 Jun 2002 14:37:28 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Bob Hinden Cc: IPng List Subject: Re: Mandating Route Optimization In-Reply-To: <4.3.2.7.2.20020530153959.02e04570@mailhost.iprg.nokia.com> References: <4.3.2.7.2.20020530153959.02e04570@mailhost.iprg.nokia.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 90 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Thu, 30 May 2002 16:43:50 -0700, >>>>> Bob Hinden said: > Independent of how this is resolved, I think the best place to define the > route optimization implementation requirements for all IPv6 nodes is in the > IPv6 Node Requirements document. I don't think it should be in the Mobile > IPv6 specification because at a minimum implementers not planning to > implement Mobile IPv6 might not see it. There is a design team effort > underway to produce an IPv6 Node Requirements draft and I think they should > have an -00 version out soon for w.g. review and comments. This discussion > is important input into this document. I fully agree. One of the most unfortunate things about the correspondent node discussion is that it has been discussed only within the mobileip wg. It was reasonable when the support of mobile IP in correspondent nodes was optional. However, I don't think it makes sense to decide something is mandatory for all nodes within a single group that has a very specific goal (mobile IPv6 in this case). In this sense I think it was an unfortunate thing to make the support of home address option mandatory in the mobile ipv6 draft. It should have been approved by the ipv6 (or ipngwg) wg (I don't remember if it was though), and should have been documented in a basic specification of IPv6 once approved. As for SHOULD vs MUST: as other guys pointed out, it depends on how the requirement solves a common situation and how the situation is critical. Since the MUST affects all IPv6 nodes, the argument for the MUST basically must convince all IPv6 implementors, including OS/server vendors, router vendors, and even home appliance vendors. Additionally, if the requirement is not configurable (i.e. there is no knob to turn it off), the argument must also convince all IPv6 operators such as ISPs and (possibly) cellular phone companies. Honestly, the argument for the MUST so far does not seem to me very convincible - after all, mobile-ip (v4 or v6) nodes only occupy a very small part in the current Internet. It may be true that more and more "nomadic" nodes will come in the near future, where "nomadic" means the node moves from a link to another link while working, but I'm not fully convinced that all such "nomadic" nodes are speaking mobile IP. I'm also not sure how many (correspondent-only) nodes will need to communicate with mobile-IP nodes in the depicted by mobileip-ers. Please note, however, that I'm not necessarily making an objection to mobile-IP (v4 or v6) itself. I'm just saying the MUST is too strong, considering the current situation and the uncertainty about the future. With the fact that mobile IP is one of possible (though perhaps likeliest) solutions to support nomadic nodes, I believe it is better to make effects to other nodes as small as possible in order to deploy mobile IP itself. So, I must vote for the SHOULD (or even MAY). Even with the MUST, I can imagine that IPv6 stack implementors who are not convinced will ignore the requirement. The result will be a certain amount of "non-compliant" implementations and loss of interoperability. Even with the SHOULD, the implementors will implement the feature if communicating with mobile-IP nodes using the route optimization becomes attractive enough, while keeping the minimum interoperability. I don't just get why we cannot go with this path. Lastly, just saying "route optimization is mandatory" does not make sense to me, because the specication of mobile ipv6 is far from stabilized. The current specication may require, say, 1,000 new lines to implement, which may or may not be a large cost. But what if it requires 1,000,000 lines in draft-mobileip-ipv6-99? Can we still allow the requirement just because it is the "route optimization" which is a MUST? mobileip-ers may want to say that the standardization will soon be done, but I've been seeing the same phrase for a few years and cannot be that optimistic (e.g. please do not forget that the notion of the "return routability" is very new. how can we be 100% sure that it's stable and will not change?). Even if the next revision of the draft passes a wg last call, we'll still have a review period by the IESG, which is getting longer and longer nowadays. So, we can only discuss if it is reasonable to make "section xx of draft-yy-zz" mandatory for all IPv6 nodes. This, of course, does not make sense much, which is another reason why the SHOULD (or MAY) is better. In summary: - if we're going to make something mandatory for all IPv6 nodes, it must be discussed in the ipv6 wg. - (IMO) we cannot go with the MUST, considering the current situation and some possible scenarios in the future. We should delay the decision, or should go with a SHOULD or a MAY. - it does not make sense just to say "the route optimization is mandatory." we should be more specific. 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 Sun Jun 2 23:25:26 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g536PPrP015721; Sun, 2 Jun 2002 23:25:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g536PP1f015720; Sun, 2 Jun 2002 23:25:25 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g536PMrP015713 for ; Sun, 2 Jun 2002 23:25:22 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA13897 for ; Sun, 2 Jun 2002 23:25:24 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA23088 for ; Sun, 2 Jun 2002 23:25:23 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id XAA00087; Sun, 2 Jun 2002 23:25:23 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g536PMZ12182; Sun, 2 Jun 2002 23:25:22 -0700 X-mProtect: <200206030625> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdCyLkl5; Sun, 02 Jun 2002 23:25:19 PDT Message-ID: <3CFB0BC2.1FC42C0C@iprg.nokia.com> Date: Sun, 02 Jun 2002 23:25:06 -0700 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: jinmei@isl.rdc.toshiba.co.jp, IPng Working Group Subject: Re: Mandating Route Optimization References: <4.3.2.7.2.20020530153959.02e04570@mailhost.iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello folks, JINMEI Tatuya / $B?@L@C#:H(B wrote: > >>>>> On Thu, 30 May 2002 16:43:50 -0700, > >>>>> Bob Hinden said: > > > Independent of how this is resolved, I think the best place to define the > > route optimization implementation requirements for all IPv6 nodes is in the > > IPv6 Node Requirements document. I don't think it should be in the Mobile > > IPv6 specification because at a minimum implementers not planning to > > implement Mobile IPv6 might not see it. There is a design team effort > > underway to produce an IPv6 Node Requirements draft and I think they should > > have an -00 version out soon for w.g. review and comments. This discussion > > is important input into this document. > > I fully agree. One of the most unfortunate things about the > correspondent node discussion is that it has been discussed only > within the mobileip wg. It was reasonable when the support of mobile > IP in correspondent nodes was optional. However, I don't think it > makes sense to decide something is mandatory for all nodes within a > single group that has a very specific goal (mobile IPv6 in this case). What I thought is that the mobile-ip group should decide what makes sense, as far as support for mobility is concerned. Mandated behavior for all nodes clearly requires discussion in this group. We are now having discussion in this group. It would not make sense to have the discussion until the mobile-ip group knew what needed to be done. And, in fact, the level of specification (MUST or SHOULD) has not been decided in the mobile-ip group either. So, this means you are getting your wish. > In this sense I think it was an unfortunate thing to make the support > of home address option mandatory in the mobile ipv6 draft. It should > have been approved by the ipv6 (or ipngwg) wg (I don't remember if it > was though), and should have been documented in a basic specification > of IPv6 once approved. It never got to the point of going through Last Call, so it was never quite ready enough to introduce the discussion here. > As for SHOULD vs MUST: as other guys pointed out, it depends on how > the requirement solves a common situation and how the situation is > critical. Since the MUST affects all IPv6 nodes, the argument for the > MUST basically must convince all IPv6 implementors, including > OS/server vendors, router vendors, and even home appliance vendors. > Additionally, if the requirement is not configurable (i.e. there is no > knob to turn it off), the argument must also convince all IPv6 > operators such as ISPs and (possibly) cellular phone companies. I think that everyone agrees that the behavior should be configurable, either dynamically or by administrative configuration. What do you think about the points I tried to make a few days ago about general scalability and the likely proportion of future nodes that will be mobile nodes. > Honestly, the argument for the MUST so far does not seem to me very > convincible - after all, mobile-ip (v4 or v6) nodes only occupy a very > small part in the current Internet. Likewise, nodes secured by IPv6 IPsec AH occupy only a small portion of the Internet. Do you apply the same argument to convince yourself that the IPsec mandate was a mistake? > It may be true that more and more > "nomadic" nodes will come in the near future, where "nomadic" means > the node moves from a link to another link while working, but I'm not > fully convinced that all such "nomadic" nodes are speaking mobile IP. > I'm also not sure how many (correspondent-only) nodes will need to > communicate with mobile-IP nodes in the depicted by mobileip-ers. A correspondent node CAN be a mobile node or not. The point is not to make a difference. And, you are right that maybe not all such nomadic nodes will use Mobile IP, but I think there is reasonable expectation that they will, and results we have so far indicate that the performance is good and the protocol operates as expected. This will be augmented as soon as is reasonable to expect by additional experience with the return routability protocol. > Please note, however, that I'm not necessarily making an objection to > mobile-IP (v4 or v6) itself. I'm just saying the MUST is too strong, > considering the current situation and the uncertainty about the > future. With the fact that mobile IP is one of possible (though > perhaps likeliest) solutions to support nomadic nodes, I believe it is > better to make effects to other nodes as small as possible in order to > deploy mobile IP itself. So, I must vote for the SHOULD (or even > MAY). Even with the MUST, I can imagine that IPv6 stack implementors > who are not convinced will ignore the requirement. The result will be > a certain amount of "non-compliant" implementations and loss of > interoperability. Even with the SHOULD, the implementors will > implement the feature if communicating with mobile-IP nodes using the > route optimization becomes attractive enough, while keeping the > minimum interoperability. I don't just get why we cannot go with this > path. The reason for mandating the binding management messages, is just as I have stated it already a few days ago. It makes a very noticeable difference in performance when traffic has to be tunneled back and forth through a home agent in a possibly quite distant network. This would be bad for many applications, especially those with various delay bounds. Did you look at my previous note on this, or should I repeat the discussion? > > But what if it > requires 1,000,000 lines in draft-mobileip-ipv6-99? I'm sure you are kidding. There won't be any such draft, and it won't take drastic amounts of code. > > Can we still > allow the requirement just because it is the "route optimization" > which is a MUST? mobileip-ers may want to say that the > standardization will soon be done, but I've been seeing the same > phrase for a few years and cannot be that optimistic (e.g. please do > not forget that the notion of the "return routability" is very new. > how can we be 100% sure that it's stable and will not change?). Indeed, return routability is new. I have myself hoped that we would be done, and the original expectation is that the IPsec group would provide something useful for key establishment. When that did not happen, we were eventually told that we didn't have the luxury of waiting for someone else to do it. Furthermore, if we mandate the return routability tests, and we never get to Proposed Standard, then I reckon people are not going to be very motivated to implement the specification. The point is that if a node is going to support the Mobile IPv6 specification, it has to do the route optimization feature. If IPv6 nodes don't need to support mobility (contrary to the mandate of the original IPv6 directorate), then that needs to be laid out. If IPv6 nodes are going to conform to the original mandate, then this is how they would do so. If we screwed up and the Return Routability test isn't good, then IETF last call is supposed to catch that. My opinion is that it is pretty good, and I hope that after looking it over you will think so too. For the rest of the policy decisions, I can't add much. > Even > if the next revision of the draft passes a wg last call, we'll still > have a review period by the IESG, which is getting longer and longer > nowadays. So, we can only discuss if it is reasonable to make > "section xx of draft-yy-zz" mandatory for all IPv6 nodes. This, of > course, does not make sense much, which is another reason why the > SHOULD (or MAY) is better. According to this logic, all mandates are from now on impossible for IPv6 nodes. MAY is a disaster for mobility, at least from the point of view of Mobile IPv6. > In summary: > > - if we're going to make something mandatory for all IPv6 nodes, it > must be discussed in the ipv6 wg. We are having the discussion. > - (IMO) we cannot go with the MUST, considering the current situation > and some possible scenarios in the future. We should delay the > decision, or should go with a SHOULD or a MAY. Even if it's mandated, I doubt we would see interoperability tests before next year, and then implementation in products not before end of 2003. How much longer shall we delay? > - it does not make sense just to say "the route optimization is > mandatory." we should be more specific. Specifically, Return Routability messages (HoTI, CoTI, HoT, CoT), Home Address Option, and Binding Update. Regards, Charlie P. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 3 03:14:13 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g53AEDrP016002; Mon, 3 Jun 2002 03:14:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g53AEDU5016001; Mon, 3 Jun 2002 03:14:13 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g53AEArP015994; Mon, 3 Jun 2002 03:14:10 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA24386; Mon, 3 Jun 2002 03:14:08 -0700 (PDT) Received: from pec.etri.re.kr (pec.etri.re.kr [129.254.114.50]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA23344; Mon, 3 Jun 2002 04:14:05 -0600 (MDT) Received: from pec.etri.re.kr (mkshin.etri.re.kr [129.254.112.163]) by pec.etri.re.kr (8.11.3/8.11.3) with ESMTP id g53AMDW11162; Mon, 3 Jun 2002 19:22:13 +0900 (KST) Message-ID: <3CFB4279.C7FF9BAC@pec.etri.re.kr> Date: Mon, 03 Jun 2002 19:18:33 +0900 From: Myung-Ki Shin Organization: ETRI X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: members@ipv6forum.com, ipv6-members@ipv6.or.kr CC: ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Global IPv6 Summit in Korea 2002, Seoul, 11-12 July Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 8bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Folks ! IPv6 Forum Korea invites you to Global IPv6 Summit in Korea 2002, Seoul, 11-12 July, just the previous week of the IETF-54 meeting in Yokohama, Japan. For the advanced program, registration, etc. see http://www.ipv6.or.kr/summit The theme of the Summit is "The Next Step for IPv6 Technology, Deployment, and Business". Many people advocate IPv6 is ready, but some people say not yet! So, we'd like to review the current status of IPv6 in the aspect of technology, deployment, and business and then discuss the next steps for IPv6. The IPv6 Forum Korea welcome everyone interested in the theme to attend the ¡°Global IPv6 Summit in Korea 2002¡±. At this summit, industry leaders from Europe, Asian and North America will report on a variety of their current IPv6 activities and a lot of presentations about the next step of IPv6 Technology, Transition, Deployment and Business will be also talked in sober earnest. Seoul is the perfect venue for such a summit. Internet use in Korea has skyrocketed over the past decade, and the country has become one of the fastest growing Internet markets in the world. Thus, the Korean government has recognized the need for IPv6 and is investing time and money into the project. In keeping with IPv6 Forum's mission to increase awareness of IPv6, please take a minute to consider who among your colleagues could benefit from this Summit opportunity, and forward them this conference information. Best regards, Myung-Ki Shin Co-chair of Global IPv6 Summit Korea program committee -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 3 06:48:43 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g53DmhrP016484; Mon, 3 Jun 2002 06:48:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g53DmhHc016483; Mon, 3 Jun 2002 06:48:43 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g53DmerP016476 for ; Mon, 3 Jun 2002 06:48:40 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA03940 for ; Mon, 3 Jun 2002 06:48:39 -0700 (PDT) From: adamson@us.ibm.com Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA04943 for ; Mon, 3 Jun 2002 07:48:38 -0600 (MDT) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.us.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.12.2/8.12.2) with ESMTP id g53DmbFD125372 for ; Mon, 3 Jun 2002 09:48:38 -0400 Received: from d04nm200.raleigh.ibm.com (d04nm200.raleigh.ibm.com [9.67.226.57]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g53DmNV35186 for ; Mon, 3 Jun 2002 09:48:23 -0400 Importance: Normal Sensitivity: Subject: IPv6 MIBs - IPv4-mapped IPv6 addresses To: ipng@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Mon, 3 Jun 2002 09:48:22 -0400 X-MIMETrack: Serialize by Router on D04NM200/04/M/IBM(Build M13TT_05222002 Pre-release 2|May 22, 2002) at 06/03/2002 09:48:22 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=0ABBE15EDFD8FCEF8f9e8a93df938690918c0ABBE15EDFD8FCEF" Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --0__=0ABBE15EDFD8FCEF8f9e8a93df938690918c0ABBE15EDFD8FCEF Content-type: text/plain; charset=US-ASCII We are planning on implementing an SNMP MIB table that represents packet trace parameters per interface. One of the parameters users can specify is the IP address so that we will only trace packets whose source/destination IP address match a user specified IP address value. Due to the fact that SIIT supports IPv4-mapped IPv6 IP addresses on the wire, we permit users to trace packets with IPv4-mapped IPv6 addresses for an IPv6 interface. How should an IPv4-mapped IPv6 address be represented using the SNMP textual conventions from RFC3291? Should the InetAddressType MIB object be set to unknown(0) or ipv6(2)? Should the InetAddress MIB object contain a 16- octet IPv4-mapped IPv6 address? Also, we are confused about the following explanation in RFC3291: The InetAddressIPv4z is intended for use in MIBs (like the TCP-MIB) which report addresses in the address family used on the wire, but where the entity instrumented obtains such addresses from applications or administrators in a form which includes a zone index, such as v4-mapped IPv6 addresses. What is the relationship between a zone index and an IPv4-mapped IPv6 address? Thanks! Kristine Adamson IBM Communications Server for MVS: TCP/IP Development Internet e-mail:adamson@us.ibm.com --0__=0ABBE15EDFD8FCEF8f9e8a93df938690918c0ABBE15EDFD8FCEF Content-type: text/html; charset=US-ASCII Content-Disposition: inline
We are planning on implementing an SNMP MIB table that represents packet trace parameters per interface. One of the parameters users can specify is the IP address so that we will only trace packets whose source/destination IP address match a user specified IP address value. Due to the fact that SIIT supports IPv4-mapped IPv6 IP addresses on the wire, we permit users to trace packets with IPv4-mapped IPv6 addresses for an IPv6 interface. How should an IPv4-mapped IPv6 address be represented using the SNMP textual conventions from RFC3291? Should the InetAddressType MIB object be set to unknown(0) or ipv6(2)? Should the InetAddress MIB object contain a 16-octet IPv4-mapped IPv6 address?

Also, we are confused about the following explanation in RFC3291:
    The InetAddressIPv4z is intended for use in MIBs (like the TCP-MIB) which report addresses in the address family used on the wire, but where the entity instrumented obtains such addresses from applications or administrators in a form which includes a zone index,
    such as v4-mapped IPv6 addresses.
What is the relationship between a zone index and an IPv4-mapped IPv6 address? Thanks!

Kristine Adamson
IBM Communications Server for MVS: TCP/IP Development
Internet e-mail:adamson@us.ibm.com --0__=0ABBE15EDFD8FCEF8f9e8a93df938690918c0ABBE15EDFD8FCEF-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 3 08:47:42 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g53FlfrP016822; Mon, 3 Jun 2002 08:47:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g53FlfAJ016821; Mon, 3 Jun 2002 08:47:41 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g53FlcrP016814 for ; Mon, 3 Jun 2002 08:47:38 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA18486 for ; Mon, 3 Jun 2002 08:47:39 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA14484 for ; Mon, 3 Jun 2002 08:47:38 -0700 (PDT) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g53FlMHs005014; Mon, 3 Jun 2002 08:47:22 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ABU05848; Mon, 3 Jun 2002 08:44:24 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA08295; Mon, 3 Jun 2002 08:47:21 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15611.36745.425209.982766@thomasm-u1.cisco.com> Date: Mon, 3 Jun 2002 08:47:21 -0700 (PDT) To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: Bob Hinden , IPng List Subject: Re: Mandating Route Optimization In-Reply-To: References: <4.3.2.7.2.20020530153959.02e04570@mailhost.iprg.nokia.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= writes: [eminently reasonable assessment of why SHOULD is more appropriate] I'd add tht MUST is primarily a tool for insuring that different implementations will interoperate. Route optimization doesn't meet that criteria since it is, after all, an optimization. If it's a MUST, it would be for, essentially, global policy reasons (death of net, film at 11...). I don't think we have enough information to really make that kind of pronouncement though. MIP isn't the only one creating dog-leg routing on the net these days: VPN's do the same thing. Indeed, VPN+MIP seems like it would be a fairly common deployment scenario. Does route optimization even buy you anything in that case? Mike -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 3 09:13:06 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g53GD6rP016884; Mon, 3 Jun 2002 09:13:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g53GD6dW016882; Mon, 3 Jun 2002 09:13:06 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g53GD2rP016875 for ; Mon, 3 Jun 2002 09:13:02 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA08762 for ; Mon, 3 Jun 2002 09:13:04 -0700 (PDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA00711 for ; Mon, 3 Jun 2002 09:13:03 -0700 (PDT) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g53GD2mG021629 for ; Mon, 3 Jun 2002 18:13:02 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 3 Jun 2002 18:13:02 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF05380498BAE4@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: ipng@sunroof.eng.sun.com Subject: NUD - Cellular host drafts Date: Mon, 3 Jun 2002 18:12:56 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all, After some discussions on the list and off list, it became clear that NUD support would be required unless we can have some analysis of how lower layer can maintain reachability within the 3GPP network. However, since time is not on our side, the authors would like to suggest that this work can be done in further updates of the RFC, if required. For now, we would like to suggest that we go with alternative 3, which was sent earlier last week by Jari. It seemed like we had concensus on that text. I've copied the text from Jari's earlier mail: So hopefully this covers part of the problem. We still have to deal with NUD. We already stated earlier that NUD is mandatory. My understanding is that the discussion relates to the kind of advice we can give to NUD for the suppression of the messages: 1) From the PDP context positive feedback all the way up to and including a working GGSN IP layer, even if this is strictly speaking lower layer from the point of view of the cellular host. 2) From the upper layers, without mentioning specifics. Basically exactly what RFC 2461 says. 3) From the upper layers, with some specific 3GPP guidance. For instance, SIP is heavily used over UDP. It might make sense to state that a SIP application should give the progress information it has to the UDP layer (which doesn't get any progress information) so that it can tell this information to IP. Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 3 09:13:00 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g53GD0rP016873; Mon, 3 Jun 2002 09:13:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g53GD022016872; Mon, 3 Jun 2002 09:13:00 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g53GCurP016865 for ; Mon, 3 Jun 2002 09:12:57 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA27315 for ; Mon, 3 Jun 2002 09:12:58 -0700 (PDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA12245 for ; Mon, 3 Jun 2002 10:12:57 -0600 (MDT) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g53GCu6n015133 for ; Mon, 3 Jun 2002 18:12:56 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 3 Jun 2002 18:12:56 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF05380498BAE3@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: ipng@sunroof.eng.sun.com Subject: Text for MLD - cellular host draft Date: Mon, 3 Jun 2002 18:12:55 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all, After some discussion on the list, I'd like to propose the following text for MLD in the cellular host draft: 2.9 RFC2710 - Multicast Listener Discovery (MLD) for IPv6 MLD may be supported by cellular hosts. 2.9.1 MLD in 3GPP networks Within 3GPP networks, hosts are connected to their default routers (GGSN) via point-to-point links. Consequently, hosts cannot communicate directly with each other using link-local addresses. Hence, joining multicast groups for link-local multicast addresses is not required. However, MLD is required when hosts run applications that need to join multicast groups whose scopes are larger than the link scope. Is this acceptable? Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 3 11:09:40 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g53I9erP017855; Mon, 3 Jun 2002 11:09:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g53I9edn017854; Mon, 3 Jun 2002 11:09:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g53I9YrP017840; Mon, 3 Jun 2002 11:09:34 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA21517; Mon, 3 Jun 2002 11:09:34 -0700 (PDT) Received: from delta.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA12766; Mon, 3 Jun 2002 11:09:32 -0700 (PDT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g53I71624842; Tue, 4 Jun 2002 01:07:01 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: "Charles E. Perkins" cc: itojun@iijlab.net, mobile-ip@sunroof.eng.sun.com, IPng Working Group , Dave Thaler Subject: Re: [mobile-ip] RE: RFC 2462 DAD optimization In-Reply-To: <3CFABA06.79CF83E4@iprg.nokia.com> References: <3CFABA06.79CF83E4@iprg.nokia.com> <2625.1023063809@itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 04 Jun 2002 01:07:01 +0700 Message-ID: <24840.1023127621@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Sun, 02 Jun 2002 17:36:22 -0700 From: "Charles E. Perkins" Message-ID: <3CFABA06.79CF83E4@iprg.nokia.com> | Do you still think that is true if the mobile node has to send | out 10, or some unbounded number, of Binding Updates each time it | changes its care-of address? Can't speak for itojun, but I would. I assume these could all be combined into one packet (not being a MIP person) - if not, why not? | It has been my understanding that a home agent, charged with | the protocol responsibility for defending the addresses of 4,095 | mobile nodes (or, say, 500,000 for some cellular plans), would | effectively disable the ability of mobile nodes to use multiple | prefixes, because equipment vendors would just "say no" if they | thought only a few mobile nodes would use this feature. That may be, many nodes of that type (where there are huge numbers connected to one HA) may quite likely only be offered one prefix. The router config at the home base will make that choice. | My guess is that it will just effectively mean people will not | use multiple prefixes for mobile nodes. Probably true. So what? Other mobile nodes will still use multiple prefixes (the HA that I would be dealing with would perhaps be coping with a half dozen mobile nodes at any one time .. .I think it could cope with my few prefixes). And since all this is related, from an earlier message of yours ... charliep@iprg.nokia.com said: | Even manually configured global addresses should be required to | acquire rights to the corresponding link-local address. Why not? Simple. There is no requirement that a node configure an address from every available prefix. (See above for a reason why some modes might choose not to). And, there's no reason at all why if a link has prefix1::/64 and prefix2::/64 assigned to it, I shouldn't be able to manually configure prefix1::1/128 as the address of one node, and prefix2::1/128 as the address of an entirely different node. They cannot both claim fe80::1 In some cases doing this might be the reason for adding a new prefix to a link - if I have a system with a well known address (prefix1::1) and I want to move it to a link that is currently prefix2::/64 and where prefix2::1 is already allocated, I might choose to assign prefix1::/64 to this link (perhaps disable auto-config of addresses in that prefix, or perhaps not) just so my node can keep using the well known address it has become accustomed to (as much as I hate well known addresses, I know this kind of thing will happen). The argument for going from a link-local which has had DAD performed upon it, to allowing auto-config from the same IID using other prefixes has some attraction, though it really doesn't seem to work at all in the multi-link prefix cases (and no, changing link local to become subnet local is not the way out of this). But going the other way, and requiring link local to every wider scope address is simply impossible, no matter how much easier that might make life for home agents. kre ps: don't we already have a way to tell from RAs which prefix is multi-link and which is not (because it matters to whether we send packets to routers of just do ND for them?). If so, we can use that to solve the DAD optimisation problem can't we? That is, simply prohibit DAD optimisation for multi-link prefixes. If we don't currently have such a method, there are still spare bits in the RA that can easily be used to mark a prefix as multi-subnet and hence ban DAD optimisation for 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 Jun 3 11:25:10 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g53IP9rP018036; Mon, 3 Jun 2002 11:25:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g53IP9Pp018035; Mon, 3 Jun 2002 11:25:09 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g53IP5rP018028 for ; Mon, 3 Jun 2002 11:25:05 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA18791 for ; Mon, 3 Jun 2002 11:25:06 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA02937 for ; Mon, 3 Jun 2002 12:25:03 -0600 (MDT) Received: from localhost ([3ffe:501:100f:1041::6]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g53IOs898440; Tue, 4 Jun 2002 03:24:54 +0900 (JST) Date: Tue, 04 Jun 2002 03:24:49 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Charlie Perkins Cc: IPng Working Group Subject: Re: Mandating Route Optimization In-Reply-To: <3CFB0BC2.1FC42C0C@iprg.nokia.com> References: <4.3.2.7.2.20020530153959.02e04570@mailhost.iprg.nokia.com> <3CFB0BC2.1FC42C0C@iprg.nokia.com> <3CEBBEE4.F91C21B3@iprg.nokia.com> <3CF5037A.9B7B7890@iprg.nokia.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 135 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, thanks for the prompt and detailed response. >>>>> On Sun, 02 Jun 2002 23:25:06 -0700, >>>>> Charlie Perkins said: > What I thought is that the mobile-ip group should decide what makes > sense, as far as support for mobility is concerned. Mandated behavior > for all nodes clearly requires discussion in this group. We are now > having discussion in this group. It would not make sense to have the > discussion until the mobile-ip group knew what needed to be done. > And, in fact, the level of specification (MUST or SHOULD) has not > been decided in the mobile-ip group either. So, this means you are > getting your wish. Okay. I really hope this rule will be kept in future discussions. (Of course, proposal related to mobile-ip will typically come from the mobileip wg, including the ones that affect all nodes.) >> In this sense I think it was an unfortunate thing to make the support >> of home address option mandatory in the mobile ipv6 draft. It should >> have been approved by the ipv6 (or ipngwg) wg (I don't remember if it >> was though), and should have been documented in a basic specification >> of IPv6 once approved. > It never got to the point of going through Last Call, so it was never > quite ready enough to introduce the discussion here. Okay. I was actually concerned about arguments like: >>>>> On Wed, 22 May 2002 08:53:08 -0700, >>>>> "Charles E. Perkins" said: > That is under discussion. In fact, I strongly believe that EVERY > IPv6 correspondent node MUST implement return routability procedures. > Furthermore, every IPv6 node already MUST implement Home Address Option. I understood this was a personal opinion, but I read this to mean that 1. the decision about Home Address Option was already done. it's a MUST. 2. now that Home Address Option is a MUST, it should be quite natural to mandate return routability (or the entire function of route optimization) as well. (though I may have misunderstood the nuance in the first place) if this kind of logic is justified, we'll be able to make arbitrary extensions that affect all nodes by a proposal in a draft written and discussed within a particular group. I was afraid about this stroy. But, I'm okay if the ipv6 wg (in this case) will discuss if an extension mandating something to all nodes is acceptable, and the wg can even start with rejecting former proposals which are MUST. (here I'm just talking about the general procedure, rather than the particular issue of Home Address Option). > I think that everyone agrees that the behavior should be configurable, > either dynamically or by administrative configuration. Okay. > What do you think about the points I tried to make a few days ago > about general scalability and the likely proportion of future nodes > that will be mobile nodes. I respect your insight, but my honest feeling is that it was a guess. We do not have actual results about the delay when communicating without route optimization. We're (or I am) not sure about the real rate of nomadic nodes *speaking mobile-ip* in the future Internet. IMO, requiring a MUST (for all nodes) due to a performance issue needs a concrete evidence like results of performance tests, not a guess. We can say that a SHOULD means every implementation can be compliant without supporting route optimization at the cost of efficiency in mobile-ip environments. However, we can also say that a MUST means any implementation can be faulted not to be compliant even if the implementation was not expected to make frequent communication with mobile-ip nodes and wanted to omit route optimization due to (e.g.) very limited resources. I recall the discussion about "minimum requirements" for low-cost appliances or for 3G devices. The authors of the drafts proposed to omit some features which are mandated in existing RFCs, due to limited resources and usages. The result of the discussion was "we cannot allow such non-compliant implementations that easily". Once we mandate route optimization, the same situation may happen in the future. Since such low-cost devices will also be in a large part of the future Internet (v6) (though some of such low-cost devices can act as a frequent correspondent nodes), I don't think it a good idea to add another restriction at this early stage. In theory, we can change requirements described in RFCs if we find them inappropriate in the future. However, the recent discussion about the low-cost devices shows it will be very hard in practice. >> Honestly, the argument for the MUST so far does not seem to me very >> convincible - after all, mobile-ip (v4 or v6) nodes only occupy a very >> small part in the current Internet. > Likewise, nodes secured by IPv6 IPsec AH occupy only a small portion > of the Internet. Do you apply the same argument to convince yourself > that the IPsec mandate was a mistake? No, because in this case it's an all-or-nothing choice; if we do not implement IPsec, we cannot be secure (at least at the IP level). On the other hand, even if we do not implement the route optimization, we can still communicate with mobile nodes in some less-efficient manner. Of course, one can say that the mobility case is also an all-or-nothing choice, i.e. that "the less-efficient manner" means not working. But, at least to me, the latter argument is not as clear as the former - again, we do not have concrete results about the performance. Going back to the route optimization issue, I don't just get why we cannot go with a SHOULD. Some implementors have already said that they will implement the feature (even with a SHOULD). So, we'll at least have an environment to test the effectiveness, interoperability, performance (and whatever necessary) of the optimization to make a further decision. If the deployment schedule is as you expected: > Even if it's mandated, I doubt we would see interoperability tests before > next year, and then implementation in products not before end of 2003. then I think we can wait for results of the experiments, rather than to make a strong requirement for all nodes at this stage. (I won't make responses to other parts of your reply, because they would almost be a repeat of the points above. If you feel it unfair, please point it out). Thanks, 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 Mon Jun 3 11:32:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g53IWfrP018133; Mon, 3 Jun 2002 11:32:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g53IWfX5018132; Mon, 3 Jun 2002 11:32:41 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g53IWYrP018117; Mon, 3 Jun 2002 11:32:34 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA09844; Mon, 3 Jun 2002 11:32:34 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA10390; Mon, 3 Jun 2002 11:32:34 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA28004; Mon, 3 Jun 2002 11:32:28 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g53IWSH10437; Mon, 3 Jun 2002 11:32:28 -0700 X-mProtect: <200206031832> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdEZpYM0; Mon, 03 Jun 2002 11:32:25 PDT Message-ID: <3CFBB63A.30DCB2E9@iprg.nokia.com> Date: Mon, 03 Jun 2002 11:32:26 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Robert Elz CC: mobile-ip@sunroof.eng.sun.com, IPng Working Group Subject: Re: [mobile-ip] RE: RFC 2462 DAD optimization References: <3CFABA06.79CF83E4@iprg.nokia.com> <2625.1023063809@itojun.org> <24840.1023127621@munnari.OZ.AU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert Elz wrote: > | My guess is that it will just effectively mean people will not > | use multiple prefixes for mobile nodes. > > Probably true. So what? Other mobile nodes will still use > multiple prefixes (the HA that I would be dealing with would perhaps > be coping with a half dozen mobile nodes at any one time .. .I think > it could cope with my few prefixes). No doubt that many IPv6 networks will have only a few nodes, and many will have only a few prefixes. My questions were related whether that model should be our design goal. > And since all this is related, from an earlier message of yours ... > > charliep@iprg.nokia.com said: > | Even manually configured global addresses should be required to > | acquire rights to the corresponding link-local address. Why not? > > Simple. ...?... > There is no requirement that a node configure an address from every > available prefix. (See above for a reason why some modes might choose > not to). I was by no means suggesting that a node should configure an address from every available prefix. > And, there's no reason at all why if a link has prefix1::/64 and > prefix2::/64 assigned to it, I shouldn't be able to manually configure > prefix1::1/128 as the address of one node, and prefix2::1/128 as the > address of an entirely different node. > > They cannot both claim fe80::1 Exactly -- and I am suggesting that there are enough IPv6 addresses available so that there is no motivation to support the use of prefix{1,2}::1 for two different nodes on the same link. Maybe one of them could find a different interface ID. I didn't yet see why enabling the behavior you suggest has any advantages. > In some cases doing this might be the reason for adding a new prefix > to a link - if I have a system with a well known address (prefix1::1) > and I want to move it to a link that is currently prefix2::/64 and > where prefix2::1 is already allocated, I might choose to assign > prefix1::/64 to this link (perhaps disable auto-config of addresses > in that prefix, or perhaps not) just so my node can keep using the well > known address it has become accustomed to (as much as I hate well known > addresses, I know this kind of thing will happen). Honestly, I think IPv6 would be better off by prohibiting this behavior. > But going the other way, and requiring link local to every wider scope > address is simply impossible, no matter how much easier that might make > life for home agents. Either I didn't understand this, or I don't see why it's impossible. Actually, I was only concerned with global scope and site-local scope. Is the only roadblock the desire to maintain an interface ID when moving a node to a new subnet? > ps: don't we already have a way to tell from RAs which prefix is multi-link > and which is not (because it matters to whether we send packets to routers > of just do ND for them?). If so, we can use that to solve the DAD > optimisation problem can't we? That is, simply prohibit DAD optimisation > for multi-link prefixes. If we don't currently have such a method, there > are still spare bits in the RA that can easily be used to mark a prefix as > multi-subnet and hence ban DAD optimisation for it. This solution works for me, I guess because I don't see any driving need to put home agents on multi-link subnets. Regards, Charlie P. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 3 11:46:13 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g53IkCrP018291; Mon, 3 Jun 2002 11:46:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g53IkCmm018290; Mon, 3 Jun 2002 11:46:12 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g53Ik5rP018275; Mon, 3 Jun 2002 11:46:05 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA05246; Mon, 3 Jun 2002 11:46:05 -0700 (PDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA08957; Mon, 3 Jun 2002 12:46:05 -0600 (MDT) Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 3 Jun 2002 11:46:04 -0700 Received: from 157.54.6.150 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 03 Jun 2002 11:46:04 -0700 Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 3 Jun 2002 11:46:04 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 3 Jun 2002 11:46:04 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3604.0); Mon, 3 Jun 2002 11:46:03 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [mobile-ip] RE: RFC 2462 DAD optimization Date: Mon, 3 Jun 2002 11:46:03 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC1047CF14D@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mobile-ip] RE: RFC 2462 DAD optimization Thread-Index: AcILKdMWC7Yd1V5NTs2H+SufA1CfeAABE90w From: "Dave Thaler" To: "Robert Elz" , "Charles E. Perkins" Cc: , , "IPng Working Group" X-OriginalArrivalTime: 03 Jun 2002 18:46:03.0977 (UTC) FILETIME=[E9DCFB90:01C20B2E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g53Ik5rP018276 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert Elz writes: > ps: don't we already have a way to tell from RAs which prefix is multi- > link > and which is not No. In fact, I would expect that if any prefix is multilink, then all of them should be. > (because it matters to whether we send packets to routers > of just do ND for them?). There is a bit that says whether to send packets to routers or just do ND for them, which is probably what you're thinking of. However, a multilink subnet can work either way (see section 4.1 of the multilink draft), so that bit doesn't tell you anything about whether you're on a multilink subnet. > If so, we can use that to solve the DAD > optimisation problem can't we? That is, simply prohibit DAD optimisation > for multi-link prefixes. If we don't currently have such a method, there > are still spare bits in the RA that can easily be used to mark a prefix as > multi-subnet and hence ban DAD optimisation for it. My preference is that we just ban DAD optimization in all cases. -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 Mon Jun 3 12:49:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g53JnkrP018519; Mon, 3 Jun 2002 12:49:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g53Jnji5018518; Mon, 3 Jun 2002 12:49:45 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g53JngrP018511 for ; Mon, 3 Jun 2002 12:49:42 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA28446 for ; Mon, 3 Jun 2002 12:49:43 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA22556 for ; Mon, 3 Jun 2002 13:49:43 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id MAA01341; Mon, 3 Jun 2002 12:49:38 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g53JnbQ17875; Mon, 3 Jun 2002 12:49:37 -0700 X-mProtect: <200206031949> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdnNl9QR; Mon, 03 Jun 2002 12:49:35 PDT Message-ID: <3CFBC84F.55A2D263@iprg.nokia.com> Date: Mon, 03 Jun 2002 12:49:35 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "JINMEI, Tatuya" CC: IPng Working Group Subject: Re: Mandating Route Optimization References: <4.3.2.7.2.20020530153959.02e04570@mailhost.iprg.nokia.com> <3CFB0BC2.1FC42C0C@iprg.nokia.com> <3CEBBEE4.F91C21B3@iprg.nokia.com> <3CF5037A.9B7B7890@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello again, JINMEI Tatuya / $B?@L@C#:H(B wrote: > But, I'm okay if the ipv6 wg (in this case) will discuss if an > extension mandating something to all nodes is acceptable, and the wg > can even start with rejecting former proposals which are MUST. > (here I'm just talking about the general procedure, rather than the > particular issue of Home Address Option). I reckon that before IETF last call on any universal IPv6 mandate, the mobile-ip working group will have the responsibility to make the reasons for the mandate clear. >> What do you think about the points I tried to make a few days ago >> about general scalability and the likely proportion of future nodes >> that will be mobile nodes. > > I respect your insight, but my honest feeling is that it was a guess. It's not a guess that reverse tunneling lengthens the response time for packets sent from a mobile node. That's just arithmetic. In my previous note, I clearly labeled the facts and opinions. Did you dispute the points I listed as facts? Did you dispute the points I labeled as opinions? > We do not have actual results about the delay when communicating > without route optimization. This, again, is arithmetic. Plus, there have been publications carrying out the arithmetic and simulations, albeit from IPv4 route optimization. The difference between IPv4 and IPv6 does not matter here. > We're (or I am) not sure about the real > rate of nomadic nodes *speaking mobile-ip* in the future Internet. > IMO, requiring a MUST (for all nodes) due to a performance issue needs > a concrete evidence like results of performance tests, not a guess. I'd be very interested to hear how you can resolve the following problem: - If we do NOT mandate the required feature, and a lot of millions of mobile nodes implement Mobile IPv6, then there will be a lot of millions of IPv6 nodes built between now and then that will not work well. - If we DO mandate the required feature, and Mobile IPv6 is a flop, then there will be a lot (but probably somewhat fewer than above) nodes that "unnecessarily" implement the feature(s). - If we mandate the feature LATER, then in the meantime and for a year afterwards, many of the devices manufactured to be compliant with IPv6 specifications (that is, _many more_ than we have now) will suddenly become noncompliant. The intended effect is to reduce the long-term pain of noncompliance. If we settle on SHOULD, then I think that we should also agree to periodically re-evaluate the evolution of mobile networking in the IPv6 Internet, and also to make it clear to manufacturers of all IPv6 devices that noncompliance entails peformance penalties for all communications with mobile devices (that implement Mobile IPv6). A manufacturer that fully understands the trade-offs, and believes that the applications running on their device do not have any special needs for faster performance for streams to/from mobile devices, would then take the option to streamline their implementation. This would be reasonable. The approach of interpreting SHOULD as a license to speed up product introduction is the problem I am mostly worried about, and many people express concern that SHOULD is taken with the unfortunate meaning instead of the literal meaning from RFC 2119. > I recall the discussion about "minimum requirements" for low-cost > appliances or for 3G devices. The authors of the drafts proposed to > omit some features which are mandated in existing RFCs, due to limited > resources and usages. The result of the discussion was "we cannot > allow such non-compliant implementations that easily". Once we > mandate route optimization, the same situation may happen in the > future. I thought the discussion about "minimum requirements" was pretty good! In fact, it's just the kind of discussion that was needed, as shown by recent conclusions about NUD. I also think that similar analysis is needed by vendors before they decide whether or not to implement the route optimization features. > Since such low-cost devices will also be in a large part of the future > Internet (v6) (though some of such low-cost devices can act as a > frequent correspondent nodes), I don't think it a good idea to add > another restriction at this early stage. In theory, we can change > requirements described in RFCs if we find them inappropriate in the > future. However, the recent discussion about the low-cost devices > shows it will be very hard in practice. It is important to keep IPv6 implementable for low-cost devices. This has been a driving force behind the design of HoTI, CoTI, HoT, and CoT, as well as HoA. These are expressly intended to be light-weight signals. I feel that you are making the discussion in the abstract, instead of determining exactly how much harder it is to do the route optimization messaging. Furthermore, the analysis should be taken with respect to the _incremental_ cost, once IPsec has already been implemented. >> ... nodes secured by IPv6 IPsec AH occupy only a small portion >> of the Internet. Do you apply the same argument to convince yourself >> that the IPsec mandate was a mistake? > > No, because in this case it's an all-or-nothing choice; if we do not > implement IPsec, we cannot be secure (at least at the IP level). Actually, I think it's exactly the same from THIS argument. A node that does not implement IPsec, cannot run secure applications. A node that does not implement route optimization, is far less likely to be able to meet delay bounds, and also will experience some (perhaps quite significant) loss of robustness in communications. > On the other hand, even if we do not implement the route optimization, we > can still communicate with mobile nodes in some less-efficient manner. > Of course, one can say that the mobility case is also an > all-or-nothing choice, i.e. that "the less-efficient manner" means not > working. But, at least to me, the latter argument is not as clear as > the former - again, we do not have concrete results about the > performance. No, it is just as you have described it. But, for some applications, performance matters. You wouldn't watch a TV show with insufficient bandwidth to your device, I'm sure. You wouldn't use a handset for voice applications if handover performance stunk. To be precise, mandating route optimization will enlarge the realm of applicability for deployment of applications on IPv6 mobile devices. Not doing so means you'll have to find other protocols to run those applications. Full employment! Regards, Charlie P. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 3 21:18:29 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g544ITrP020004; Mon, 3 Jun 2002 21:18:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g544ISYE020003; Mon, 3 Jun 2002 21:18:28 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g544IOrP019996 for ; Mon, 3 Jun 2002 21:18:24 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA27893 for ; Mon, 3 Jun 2002 21:18:25 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA22917 for ; Mon, 3 Jun 2002 21:18:24 -0700 (PDT) Received: from localhost ([3ffe:501:4819:2000:200:39ff:fed9:21d7]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g544IG801119; Tue, 4 Jun 2002 13:18:16 +0900 (JST) Date: Tue, 04 Jun 2002 13:18:14 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Charles E. Perkins" Cc: IPng Working Group Subject: Re: Mandating Route Optimization In-Reply-To: <3CFBC84F.55A2D263@iprg.nokia.com> References: <4.3.2.7.2.20020530153959.02e04570@mailhost.iprg.nokia.com> <3CFB0BC2.1FC42C0C@iprg.nokia.com> <3CEBBEE4.F91C21B3@iprg.nokia.com> <3CF5037A.9B7B7890@iprg.nokia.com> <3CFBC84F.55A2D263@iprg.nokia.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 126 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Mon, 03 Jun 2002 12:49:35 -0700, >>>>> "Charles E. Perkins" said: >>> What do you think about the points I tried to make a few days ago >>> about general scalability and the likely proportion of future nodes >>> that will be mobile nodes. >> >> I respect your insight, but my honest feeling is that it was a guess. > It's not a guess that reverse tunneling lengthens the response time > for packets sent from a mobile node. That's just arithmetic. Perhaps I was not very correct about the wording. It's true that reverse tunneling lengthens the response time. But it's not sure about how long the response time takes. It's not sure how it is serious for typical applications using mobile-ip. It's not sure about how many correspondent nodes will actually lengthen the response time in practical operations if we make the requirement a SHOULD... > In my previous note, I clearly labeled the facts and opinions. > Did you dispute the points I listed as facts? Did you dispute > the points I labeled as opinions? I did not necessarily to dispute your facts and opinions. They may be true or false. I could just not be sure. I admit this argument is not fair in general, because I did not provide concrete (negative) evidence either. However, in this case those who are trying to mandate something are responsible for giving concrete evidence. >> We're (or I am) not sure about the real >> rate of nomadic nodes *speaking mobile-ip* in the future Internet. >> IMO, requiring a MUST (for all nodes) due to a performance issue needs >> a concrete evidence like results of performance tests, not a guess. > I'd be very interested to hear how you can resolve the following > problem: > - If we do NOT mandate the required feature, and a lot of millions > of mobile nodes implement Mobile IPv6, then there will be a lot > of millions of IPv6 nodes built between now and then that will not > work well. if a lot of millions of mobile nodes implement Mobile IPv6 and a lot of millions of correspondent nodes do not implement the optimization (due to a SHOULD) and not implementing the optimization is really critical, then it can be a problem. I'm just saying we're not (yet) sure about all the conditions at this stage. > - If we DO mandate the required feature, and Mobile IPv6 is a flop, > then there will be a lot (but probably somewhat fewer than above) > nodes that "unnecessarily" implement the feature(s). And the cost of the devices will unnecessarily be raised, the ship timing will unnecessarily be delayed. Not mandating the feature (at this moment) can solve the situation. > - If we mandate the feature LATER, then in the meantime and for > a year afterwards, many of the devices manufactured to be compliant > with IPv6 specifications (that is, _many more_ than we have now) > will suddenly become noncompliant. Yes, but as some other guys pointed out, we cannot always avoid the situation that makes some older implementations non-compliant. Additionally, if we decide mandating the feature LATER, then we'll have found very convincing evidence (with some concrete results) before that point. During the procedure, some implementors may find the merit of supporting the optimization and implement it. So, not all implementations that choose skipping the optimization now will "suddenly" be non-compliant. According to your expected deployment schedule: >>>>> On Sun, 02 Jun 2002 23:25:06 -0700, >>>>> Charlie Perkins said: > Even if it's mandated, I doubt we would see interoperability tests before > next year, and then implementation in products not before end of 2003. I don't get why we cannot live with the gradually deployment. Please let me rephrase my opinion again: >>>>> On Tue, 04 Jun 2002 03:24:49 +0900, >>>>> JINMEI Tatuya said: > Going back to the route optimization issue, I don't just get why we > cannot go with a SHOULD. Some implementors have already said that > they will implement the feature (even with a SHOULD). So, we'll at > least have an environment to test the effectiveness, interoperability, > performance (and whatever necessary) of the optimization to make a > further decision. (snip) > then I think we can wait for results of the experiments, rather than > to make a strong requirement for all nodes at this stage. Regarding the "minimum requirements" discussion: > I thought the discussion about "minimum requirements" was pretty > good! In fact, it's just the kind of discussion that was needed, > as shown by recent conclusions about NUD. I also think that similar > analysis is needed by vendors before they decide whether or not to > implement the route optimization features. I agree, but I don't think we have enough evidence for vendors to decide whether or not to implement the route optimization. Thus, I'd like to let the vendors to make the decision after we collect enough (concrete) information, rather than to mandate the feature at this moment. === I believe I've fully dumped my opinions and understood yours. Those two are so opposite, and I'm not sure if we can reach a consensus by further discussions. So I'd like to hear other implementors for now. After all, if all (or overwhelmingly majority of) related vendors are convinced to mandate the route optimization (I doubt that though), the discussion will just be over. (Of course, please feel free to make comments to this message.) Regards, 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 Mon Jun 3 22:42:27 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g545gQrP020098; Mon, 3 Jun 2002 22:42:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g545gQ9i020097; Mon, 3 Jun 2002 22:42:26 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g545gNrP020090 for ; Mon, 3 Jun 2002 22:42:23 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA13555 for ; Mon, 3 Jun 2002 22:42:25 -0700 (PDT) Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA25968 for ; Mon, 3 Jun 2002 23:42:21 -0600 (MDT) Received: from ns.iij.ad.jp ([192.168.2.111]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id OAA19083; Tue, 4 Jun 2002 14:42:20 +0900 (JST) Received: from localhost (keiichi01.osaka.iij.ad.jp [192.168.65.66]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id OAA01972; Tue, 4 Jun 2002 14:42:19 +0900 (JST) Date: Tue, 04 Jun 2002 14:41:45 +0900 (JST) Message-Id: <20020604.144145.64269022.keiichi@iij.ad.jp> To: charliep@iprg.nokia.com Cc: ipng@sunroof.eng.sun.com Subject: Re: Mandating Route Optimization From: Keiichi SHIMA / =?iso-2022-jp?B?GyRCRWc3RDBsGyhC?= In-Reply-To: <3CFB0024.45F2CFA6@iprg.nokia.com> References: <3CF6C09A.7214595A@iprg.nokia.com> <20020603.140303.67979866.keiichi@iij.ad.jp> <3CFB0024.45F2CFA6@iprg.nokia.com> X-Mailer: Mew version 3.0.55 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello Charlie, From: Charlie Perkins > > Please note, I'm not saying that the current RO/RR is bad. I like RO > > and the current draft seems OK but should we have more time to check > > it? > > Return routability, in general, has been under discussion for well > over a year. I think the basic idea came up over 18 months ago. > Then there was BAKE and several other drafts. Then there was > bu3way. Some of these have been implemented. The basic > ideas are pretty well understood, and as with any protocol more > experience will further improve our knowledge. Yes. It has been discussed for over a year, but none of us has not made it work. As an implementor, I think it is dangerous to make such a specification mandate for all IPv6 nodes. It is too late if we find any problems after we have mandated it. But it is not too late to decide whether we make it mandate or not after all of (or most of) us are convinced it must be. Before the decision, we should experience more. Fortunately, the latest MIP6 works with IPv6 nodes which do not support even HAO. There is no impact against the current Internet. After this experience, if people think RO must be MUST, lets' revise the node requirement draft. I think it is better to move gradually (and we can with the latest draft). I don't understand why you are in so haste. There are already many IPv6 nodes shipped in the world. All of them do not support MIP6. We can live with them using MIP6. Also, we can move gradually to the RO'ed world. > > If we find a new method for RO and obsolete RR, how do we handle > > already shipped RR based implementation? There may be a problem. For > > example, we had (unverified) HAO in old drafts. Some implementation > > support us and implement it. But it (unverified HAO) is now > > obsoleted. > > This is a very long story. Until a protocol specification reaches > proposed standard, implementations are at risk of becoming > obsolete -- even after that. This has happened with practically > every protocol I can think of, to some degree or another. > For instance, even with IPv6, the planned TLA and SLA bits > are now obsolete, even though they were planned out for a long > time. > > To make an analogy, if you wait for the fastest processor technology > before buying, you will never buy, because there is always something > better on the horizon. At least we can make for compatibility, though. > > In this circumstance, it is a lot easier to _not use_ return routability > if something else turns up, than it is to _use_ return routability, if it > is not mandated. I have made several arguments why it should be > mandated, and as best I can tell the strongest counterargument is that > it's not standard yet, so how can we mandate it? I believe this to be > a circular argument. I think most of the vendors will choose what their customers want. If many people want RO, the vendors are going to ship their products with RO support. I beleive the vendors never discard the SHOULD spec just because it is easy way. They don't implement the specs because it is not what people want. > > I think it is too early to make it MUST. It is not too late after all > > of MIP6 vendors implement the draft and experient several interop > > tests and all of us are convinced it is OK to go. > > If the behavior is mandated, and something goes wrong, I reckon > we'll have to revise our understanding in the future. As it is now, > it's the best we know, and it's pretty well understood. Everyone > believes we will have something better in the future, and so I am > trying my best to make sure the protocol is extensible for that future > optimization. Needless to say, RO is better than not RO. I think the point is how to deploy RO. I don't think it good idea to make it mandate now because the reasons described above. Best Regards, --- Keiichi SHIMA IIJ Research Laboratory KAME Project -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 3 23:18:59 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g546IxrP020146; Mon, 3 Jun 2002 23:18:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g546IwVm020145; Mon, 3 Jun 2002 23:18:58 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g546IsrP020138; Mon, 3 Jun 2002 23:18:55 -0700 (PDT) Received: from lillen ([192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g546Img10862; Tue, 4 Jun 2002 08:18:49 +0200 (MEST) Date: Mon, 3 Jun 2002 22:05:46 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [mobile-ip] RFC 2462 DAD optimization To: Richard Draves Cc: "Charles E. Perkins" , "Hesham Soliman (ERA)" , mobile-ip@sunroof.eng.sun.com, IPng Working Group In-Reply-To: "Your message with ID" <7695E2F6903F7A41961F8CF888D87EA804BC4CDD@red-msg-06.redmond.corp.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I'm curious about the implementation status. I know the Windows > implementation does not implement the RFC 2462 optimization - it > performs DAD on every address independently. What about other > implementations? FWIW The Solaris implementation does supress DAD on addresses configured using the stateless mechanism except the link local address. It does perform DAD on all manually configured addresses. My person opinion is that we should fix that implementation and other implementations that have this behavior. Forcing implementations to have more than one link-local address due to RFC 3041 (and potentially lots of them - one for every valid RFC 3041 address) since quite odd both conceptually and messy to deal with from an implementation perspective (need to track which is the "real" link-local address.) 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 Jun 4 02:43:51 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g549horP020540; Tue, 4 Jun 2002 02:43:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g549hoXL020539; Tue, 4 Jun 2002 02:43:50 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g549hlrP020532; Tue, 4 Jun 2002 02:43:47 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA24128; Tue, 4 Jun 2002 02:43:49 -0700 (PDT) Received: from delta.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA07499; Tue, 4 Jun 2002 02:43:42 -0700 (PDT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g549ZV600759; Tue, 4 Jun 2002 16:35:31 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: "Charles E. Perkins" cc: mobile-ip@sunroof.eng.sun.com, IPng Working Group Subject: Re: [mobile-ip] RE: RFC 2462 DAD optimization In-Reply-To: <3CFBB63A.30DCB2E9@iprg.nokia.com> References: <3CFBB63A.30DCB2E9@iprg.nokia.com> <3CFABA06.79CF83E4@iprg.nokia.com> <2625.1023063809@itojun.org> <24840.1023127621@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 04 Jun 2002 16:35:31 +0700 Message-ID: <757.1023183331@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 03 Jun 2002 11:32:26 -0700 From: "Charles E. Perkins" Message-ID: <3CFBB63A.30DCB2E9@iprg.nokia.com> | My questions were related whether that model should be our design goal. Maximum flexibility. Long term we will find a way to use that. This implies minimum assumptions, and even fewer unnecessary rules. | Exactly -- and I am suggesting that there are enough IPv6 | addresses available so that there is no motivation to support | the use of prefix{1,2}::1 for two different nodes on the same | link. Maybe one of them could find a different interface ID. You missed the point of the example. prefix1::1 and prefix2::1 were originally assigned to different nodes on different links. Then the links were merged into one. | I didn't yet see why enabling the behavior you suggest has | any advantages. The alternative is renumbering nodes sometimes. Not renumbering is almost always an advantage. And here we're talking about the IID part changing, so we don't even get the benefit of local connections continuing to work using site local addresses - everything stops. | Honestly, I think IPv6 would be better off by prohibiting | this behavior. I certainly disagree with that. I see no compelling reason here to prohibit anything. 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 Jun 4 02:48:14 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g549mErP020670; Tue, 4 Jun 2002 02:48:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g549mENn020669; Tue, 4 Jun 2002 02:48:14 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g549mBrP020662; Tue, 4 Jun 2002 02:48:11 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA25262; Tue, 4 Jun 2002 02:48:12 -0700 (PDT) Received: from delta.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA05600; Tue, 4 Jun 2002 03:48:09 -0600 (MDT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g549dB600772; Tue, 4 Jun 2002 16:39:16 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: "Dave Thaler" cc: "Charles E. Perkins" , itojun@iijlab.net, mobile-ip@sunroof.eng.sun.com, "IPng Working Group" Subject: Re: [mobile-ip] RE: RFC 2462 DAD optimization In-Reply-To: <2E33960095B58E40A4D3345AB9F65EC1047CF14D@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> References: <2E33960095B58E40A4D3345AB9F65EC1047CF14D@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 04 Jun 2002 16:39:11 +0700 Message-ID: <770.1023183551@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 3 Jun 2002 11:46:03 -0700 From: "Dave Thaler" Message-ID: <2E33960095B58E40A4D3345AB9F65EC1047CF14D@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> | No. In fact, I would expect that if any prefix is multilink, then all | of them should be. Why? I'm no expert on multi-link, in fact, I'm not sure I understand the need for it at all really, but nor do I know enough to object. | There is a bit that says whether to send packets to routers or just do | ND for them, which is probably what you're thinking of. Yes, that's probably it. | However, a multilink | subnet can work either way (see section 4.1 of the multilink draft), OK. | My preference is that we just ban DAD optimization in all cases. That's certainly an option. The "new prefix causes several thousand nodes to all attempt DAD at the same time" argument is the one which makes me hesitant to simply support this without further investigation. 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 Jun 4 02:56:51 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g549uprP020815; Tue, 4 Jun 2002 02:56:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g549uolx020814; Tue, 4 Jun 2002 02:56:50 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g549ulrP020807 for ; Tue, 4 Jun 2002 02:56:47 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA26840 for ; Tue, 4 Jun 2002 02:56:50 -0700 (PDT) Received: from web8104.in.yahoo.com (web8104.in.yahoo.com [203.199.70.104]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with SMTP id CAA19850 for ; Tue, 4 Jun 2002 02:56:48 -0700 (PDT) Message-ID: <20020604095647.79445.qmail@web8104.in.yahoo.com> Received: from [203.196.146.243] by web8104.mail.in.yahoo.com via HTTP; Tue, 04 Jun 2002 10:56:47 BST Date: Tue, 4 Jun 2002 10:56:47 +0100 (BST) From: =?iso-8859-1?q?santra=20thomas?= Subject: Ipv6 interface configuration in WindowsXP To: ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all, I have a WindowsXP machine with IPv6 support .By default, the IPv6 protocol for Windows XP automatically configures link-local addresses for each interface that corresponds to installed Ethernet network adapters But i donn't have a IPv6 interface for the ethernet .For configuring an interface for the ethrnet , what i have to do ? or is it a problem of ] ethernet card driver installation problem .. with regards, santra ________________________________________________________________________ Everything you always wanted to know about cars and bikes,now at: http://in.autos.yahoo.com/cricket/tracker.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 Tue Jun 4 03:21:47 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g54ALlrP020855; Tue, 4 Jun 2002 03:21:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g54ALlhi020854; Tue, 4 Jun 2002 03:21:47 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g54ALhrP020847; Tue, 4 Jun 2002 03:21:43 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g54ALeg01465; Tue, 4 Jun 2002 12:21:40 +0200 (MEST) Date: Tue, 4 Jun 2002 12:20:34 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [mobile-ip] RE: RFC 2462 DAD optimization To: itojun@iijlab.net Cc: mobile-ip@sunroof.eng.sun.com, IPng Working Group In-Reply-To: "Your message with ID" <2905.1023065694@itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >My guess is that it will just effectively mean people will not > >use multiple prefixes for mobile nodes. > > i guess so too, and therefore, i don't feel a need to provide > special hack in DAD. it is not a protocol issue, but an operational > matter. > I agree that we don't need to change DAD here. Doing multiple DAD messages (one per home address) should be in the noise from a performance perspective. If there is a concern that a mobile node shouldn't need to send multiple binding updates, then I think that concern applies to both having multiple prefixes on the home link as well as using RFC 3041 home addresses (and presumably DHCPv6 assigned home addresses as well). With RFC 3041 a host will by default have 7 home addresses - 6 deprecated and 1 preferred temporary address - plus whatever stable (non-temporary) home addresses it has. Allowing for a single BU to the home agent with RFC 3041 home addresses requires that the home agent to maintain the set of home address each mobile node is using and e.g. treat a BU for any address in the set as applying to the whole set. The current mechanism (with ICMP Mobile Prefix Solicitation/Advertisement) only allows the HA to guess the set of home addresses when stateless address conf is used. So perhaps this part of the protocol should be extended with explicit messages from the MN to HA to indicate which home addresses it is using. Then one can always do a single BU independent of how many home addresses a mobile node is using, and idependently of how the MN has acquired those home addresses. My 2 cents, Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 4 03:27:44 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g54ARirP020975; Tue, 4 Jun 2002 03:27:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g54ARiie020974; Tue, 4 Jun 2002 03:27:44 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g54ARdrP020967; Tue, 4 Jun 2002 03:27:40 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g54ARbg01874; Tue, 4 Jun 2002 12:27:37 +0200 (MEST) Date: Tue, 4 Jun 2002 12:26:31 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [mobile-ip] RE: RFC 2462 DAD optimization To: Robert Elz Cc: Dave Thaler , "Charles E. Perkins" , itojun@iijlab.net, mobile-ip@sunroof.eng.sun.com, IPng Working Group In-Reply-To: "Your message with ID" <770.1023183551@munnari.OZ.AU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > | My preference is that we just ban DAD optimization in all cases. > > That's certainly an option. The "new prefix causes several thousand > nodes to all attempt DAD at the same time" argument is the one which > makes me hesitant to simply support this without further investigation. If that is a problem then the "MAY" for the optimization in RFC 2462 wouldn't be sufficient as a solution - very few implementations do the optimization today. Possible solutions to the new prefix DAD flood could be: - mandate the DAD optimization with a MUST - update RFC 2462 to day that when a new prefix is configured (past the original "attachment" to the link) the host MUST insert a random delay before performing the DAD. - others? But do we agree that the DAD flood when a new prefix is announced is an important problem to solve? 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 Jun 4 03:37:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g54AbNrP021091; Tue, 4 Jun 2002 03:37:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g54AbNFs021090; Tue, 4 Jun 2002 03:37:23 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g54AbKrP021083 for ; Tue, 4 Jun 2002 03:37:20 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA09215 for ; Tue, 4 Jun 2002 03:37:21 -0700 (PDT) From: lassi.hippelainen@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA16300 for ; Tue, 4 Jun 2002 04:37:20 -0600 (MDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g54Abf611060 for ; Tue, 4 Jun 2002 13:37:41 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 4 Jun 2002 13:37:14 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 4 Jun 2002 13:37:14 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Mandating Route Optimization Date: Tue, 4 Jun 2002 13:37:14 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Mandating Route Optimization Thread-Index: AcILOD6iRkty6/seQAyADMeBKbP5xwAd+X2A To: X-OriginalArrivalTime: 04 Jun 2002 10:37:14.0665 (UTC) FILETIME=[CAA4E190:01C20BB3] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g54AbLrP021084 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear list, this issue is taking much time and ammunition, and it's mostly wasted. We know that the decision between MUST and SHOULD will be made in the IESG, not here. It all boils down to interpreting the words of RFC2119. The make some progress, I'd like to suggest a work plan. Step 1: someone near to the IESG members asks, if we have an option at all. Even an unofficial opinion would help. Step 2: if MUST seems possible, list the reasons for it. A few use cases and pointers to research reports would be ideal. Step 3: if the IESG keeps on throwing the book at us, accept SHOULD, but add the results of step 2 to the draft. Even SHOULD with the explanations seems acceptable to me ("SHOULD with teeth" said John Loughney). Good reasons can be more persuasive than plain orders. > -----Original Message----- > From: ext Charles E. Perkins [mailto:charliep@iprg.nokia.com] <...> > I reckon that before IETF last call on any universal IPv6 mandate, > the mobile-ip working group will have the responsibility to make > the reasons for the mandate clear. Excellent! We already have a volunteer for step 2 :-) -- Lassi -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 4 06:10:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g54DAtrP021279; Tue, 4 Jun 2002 06:10:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g54DAtSN021278; Tue, 4 Jun 2002 06:10:55 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g54DAqrP021271 for ; Tue, 4 Jun 2002 06:10:52 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA28359 for ; Tue, 4 Jun 2002 06:10:54 -0700 (PDT) Received: from mail4.nc.rr.com (fe4.southeast.rr.com [24.93.67.51]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA18754 for ; Tue, 4 Jun 2002 06:10:54 -0700 (PDT) Received: from nc.rr.com ([24.162.252.183]) by mail4.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Tue, 4 Jun 2002 09:10:18 -0400 Message-ID: <3CFCBB87.18857169@nc.rr.com> Date: Tue, 04 Jun 2002 09:07:19 -0400 From: Brian Haberman X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Hesham Soliman (ERA)" CC: ipng@sunroof.eng.sun.com Subject: Re: Text for MLD - cellular host draft References: <4DA6EA82906FD511BE2F00508BCF05380498BAE3@Esealnt861.al.sw.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hesham, The text looks fine to me. Regards, Brian "Hesham Soliman (ERA)" wrote: > > Hi all, > > After some discussion on the list, I'd like to > propose the following text for MLD in the cellular > host draft: > > 2.9 RFC2710 - Multicast Listener Discovery (MLD) for IPv6 > > MLD may be supported by cellular hosts. > > 2.9.1 MLD in 3GPP networks > > Within 3GPP networks, hosts are connected to their > default routers (GGSN) via point-to-point links. > Consequently, hosts cannot communicate directly with > each other using link-local addresses. Hence, joining > multicast groups for link-local multicast addresses is > not required. However, MLD is required when hosts run > applications that need to join multicast groups whose > scopes are larger than the link scope. > > Is this acceptable? > > Hesham > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 4 06:22:19 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g54DMJrP021306; Tue, 4 Jun 2002 06:22:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g54DMJtU021305; Tue, 4 Jun 2002 06:22:19 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g54DMFrP021298 for ; Tue, 4 Jun 2002 06:22:15 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA00142 for ; Tue, 4 Jun 2002 06:22: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 HAA24266 for ; Tue, 4 Jun 2002 07:22:15 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id E969E4B24; Tue, 4 Jun 2002 22:22:10 +0900 (JST) To: "Hesham Soliman (ERA)" Cc: ipng@sunroof.eng.sun.com In-reply-to: hesham.soliman's message of Mon, 03 Jun 2002 18:12:55 +0200. <4DA6EA82906FD511BE2F00508BCF05380498BAE3@Esealnt861.al.sw.ericsson.se> 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: Text for MLD - cellular host draft From: itojun@iijlab.net Date: Tue, 04 Jun 2002 22:22:10 +0900 Message-ID: <525.1023196930@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >After some discussion on the list, I'd like to >propose the following text for MLD in the cellular >host draft: > 2.9 RFC2710 - Multicast Listener Discovery (MLD) for IPv6 > > MLD may be supported by cellular hosts. > > 2.9.1 MLD in 3GPP networks > > Within 3GPP networks, hosts are connected to their > default routers (GGSN) via point-to-point links. > Consequently, hosts cannot communicate directly with > each other using link-local addresses. Hence, joining > multicast groups for link-local multicast addresses is > not required. However, MLD is required when hosts run > applications that need to join multicast groups whose > scopes are larger than the link scope. i still don't understand why you are trying to impose additional restriction for link-local multicast groups (maybe i'm dumb). without MLD joins for link-local multicast groups, default routers won't be able to know which multicast group the 3GPP node is interested in. there's no special text available in RFC2710 for p2p links. 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 Jun 4 07:14:44 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g54EEirP021454; Tue, 4 Jun 2002 07:14:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g54EEhAX021453; Tue, 4 Jun 2002 07:14:43 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g54EEerP021446; Tue, 4 Jun 2002 07:14:40 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA12419; Tue, 4 Jun 2002 07:14:41 -0700 (PDT) Received: from delta.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA01676; Tue, 4 Jun 2002 08:14:35 -0600 (MDT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g54EAZ601835; Tue, 4 Jun 2002 21:10:38 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: mobile-ip@sunroof.eng.sun.com, IPng Working Group cc: Erik Nordmark Subject: Re: [mobile-ip] RE: RFC 2462 DAD optimization In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 04 Jun 2002 21:10:35 +0700 Message-ID: <1833.1023199835@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 4 Jun 2002 12:26:31 +0200 (CEST) From: Erik Nordmark Message-ID: | If that is a problem then the "MAY" for the optimization in RFC 2462 | wouldn't be sufficient as a solution - very few implementations do | the optimization today. It depends upon whether the problem is one that always needs solving, or just one that needs to be able to be solved. | Possible solutions to the new prefix DAD flood could be: | - mandate the DAD optimization with a MUST So, I don't think we need to do that, whatever else happens. Then we get to implementation quality and all that - in an environment where it matters, users may want to insist on implementations that work well. In any case, we would need a way to indicate which prefixes should not be DAD optimized (MUST NOT) because of the multi-link issue. | - update RFC 2462 to day that when a new prefix is configured (past | the original "attachment" to the link) the host MUST insert a random | delay before performing the DAD. That's certainly a reasonable approach (though I'd prase it as "before configuring an address using the prefix" to make it more clear that it isn't only the DAD that needs to be delayed). | But do we agree that the DAD flood when a new prefix is announced is | an important problem to solve? Like a lot of this, I suspect this may be known only when we get IPv6 nets that are really big enough that the effects can be measured. I'm not sure there are all that many. I suspect that even the IETF net won't have enough IPv6 nodes actively connected to it to run an experiment there and see what happens. 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 Jun 4 08:07:32 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g54F7WrP021750; Tue, 4 Jun 2002 08:07:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g54F7WCk021749; Tue, 4 Jun 2002 08:07:32 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g54F7TrP021742 for ; Tue, 4 Jun 2002 08:07:29 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA02812 for ; Tue, 4 Jun 2002 08:07:30 -0700 (PDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA29705 for ; Tue, 4 Jun 2002 09:07:28 -0600 (MDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g54F7QmG005561; Tue, 4 Jun 2002 17:07:26 +0200 (MEST) Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.38.50]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g54F7Qa9020242; Tue, 4 Jun 2002 18:07:26 +0300 (EET DST) Message-ID: <3CFCD7AE.E27B07C2@lmf.ericsson.se> Date: Tue, 04 Jun 2002 18:07:26 +0300 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: itojun@iijlab.net, bkhabs@nc.rr.com CC: "Hesham Soliman (ERA)" , ipng@sunroof.eng.sun.com Subject: Re: Text for MLD - cellular host draft References: <525.1023196930@itojun.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Itojun, > i still don't understand why you are trying to impose additional > restriction for link-local multicast groups (maybe i'm dumb). > without MLD joins for link-local multicast groups, default routers > won't be able to know which multicast group the 3GPP node is > interested in. there's no special text available in RFC2710 for > p2p links. First some motivation in the practical situation. The GGSN has no applications, and hence there wouldn't be a link-local video distribution from it, as an example. Furthermore, I believe IPv6 ND packets are sent to the link regardless of the state of the MLD situation on e.g. a Solicited Node address -- or perhaps I have missed some text somewhere? Hence there'd be no use of the MLD for the IPv6 routing functioanality either. Obviously, there are no switches around in these interfaces. Finally, MLD packets do consume bandwidth, particularly if they need to be sent even when there is no traffic and we are just listening e.g. on our solicited node mcast address. (I'm not exactly sure how much this bandwidth is -- perhaps someone could enlighten me? At least some initial packets have to be sent, but is there a periodic refresh as well?) But I do understand that the RFCs must be followed. However, I wonder if you Brian could say something about the background for the link-local and the Solicited Node multicast address requirements, were they done specifically to allow switches to operate or for some other reason? I also wonder about text in Section 2, which says that MLD should be on all interfaces from which an application or upper-layer protocol has requested reception of multicast packets. I wonder what "upper layer" means in this particular case...? If it means above IP then we could argue that we are following the RFC. I also wonder if the timers -- which are configurable per the RFC -- could be tuned to minimize overhead? Finally, I have a compromise proposal. I do appreciate Itojun's point some time ago that MLD even on a p2p link would allow the router to reduce traffic to the link. This is because it would know whether there are listeners or not. Perhaps in the future there will be some new parts of IPv6, or some new applications for which this would be useful, even in a 3GPP environment. However, I do wonder about the Solicited Node multicast address case. Assuming the rules about this are in the RFC for the support of switches, could we use MLD for all link-local and global addresses, except for all nodes and solicited node multicast addresses? Given that I can't find a place where ND would depend on MLD, I think this would work well. And the case is important, as all hosts would have these addresses and would have to announce them over the network otherwise. So, the proposal is to have the following text: 2.9 RFC2710 - Multicast Listener Discovery (MLD) for IPv6 MLD should be supported by cellular hosts. 2.9.1 MLD in 3GPP networks Within 3GPP networks, hosts are connected to their default routers (GGSN) via point-to-point links. This arrangement also precludes any network switches. Consequently, hosts cannot communicate directly with each other using link-local addresses. Furthermore, none of the entities along the link will be doing any address-based switching, and all messages sent to the point-to-point link normally arrive to the other end. As Neighbor Discovery operates without relying on MLD, joining on solicited node and all nodes multicast addresses is not required. However, MLD is required for all other multicast addresses in all scopes. Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 4 08:30:07 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g54FU7rP021806; Tue, 4 Jun 2002 08:30:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g54FU7ao021805; Tue, 4 Jun 2002 08:30:07 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g54FU2rP021798 for ; Tue, 4 Jun 2002 08:30:03 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g54FU1g05643 for ; Tue, 4 Jun 2002 17:30:01 +0200 (MEST) Date: Tue, 4 Jun 2002 17:28:56 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: DNS discovery thoughts To: ipng@sunroof.eng.sun.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I've been thinking about the DNS discovery, as well as the larger "service discovery with no 3rd party dependencies" issue, for a while. Just like Steve Deering and many others I'd like the IETF to explore the larger issue, since I'm very much interested in making the future Internet more robust than what we have today. But this effort needs to be done carefully to make sure that we are solving a well-defined and well-constrained problem. Thus I think it would make sense to hold a BoF on this topic (perhaps in Yokohama if there are folks willing to work on putting such a BoF together in the very short time that remains). Level 1 of the current DNS discovery draft is likely to set a precedent that well-known unicast addresses will be allocated for services. The IETF has never done that before - we've only allocated well-known *multicast* addresses for services. Going down the path of allocating well-known unicast addresses, even if they are site-local addresses, is something I would be very uncomfortable doing, especially if it is done as a "quick fix" for a short-term DNS discovery solution without knowing what a potential future "service discovery with no 3rd party dependencies" scheme might look like. This concern appears to be shared by some other IESG members based on some discussions last week. These concerns would probably be less strong if the fixed unicast address was one part of a larger architecture, in which the reservation of fixed address was limited and necessary as part of an overall solution. Instead, it appears that this particular choice is being driven by a particular short-term problem with no apparent relationship to future and more general work. So if I was an implementor that wanted a DNS discovery solution as soon as possible, I'd just go with DHCPv6 information-request for now, while participating in the larger, and necessarily longer term, discussions about "service discovery with no 3rd party dependencies". Comments? Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 4 08:30:21 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g54FUKrP021816; Tue, 4 Jun 2002 08:30:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g54FUKbn021815; Tue, 4 Jun 2002 08:30:20 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g54FUGrP021808 for ; Tue, 4 Jun 2002 08:30:17 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA00533 for ; Tue, 4 Jun 2002 08:30:18 -0700 (PDT) Received: from mail8.nc.rr.com (fe8.southeast.rr.com [24.93.67.55]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA24546 for ; Tue, 4 Jun 2002 09:31:28 -0600 (MDT) Received: from nc.rr.com ([24.162.252.183]) by mail8.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Tue, 4 Jun 2002 11:30:08 -0400 Message-ID: <3CFCDC50.D472E4A9@nc.rr.com> Date: Tue, 04 Jun 2002 11:27:12 -0400 From: Brian Haberman X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jari Arkko CC: itojun@iijlab.net, "Hesham Soliman (ERA)" , ipng@sunroof.eng.sun.com Subject: Re: Text for MLD - cellular host draft References: <525.1023196930@itojun.org> <3CFCD7AE.E27B07C2@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jari, > But I do understand that the RFCs must be followed. > However, I wonder if you Brian could say something > about the background for the link-local and the > Solicited Node multicast address requirements, > were they done specifically to allow switches to operate > or for some other reason? Using MLD to signal interest in link-local multicast addresses allows for two things: 1. Signal interest in a group to all link-local listeners (hosts and routers) 2. Allowing switches to properly forward link-local multicast addresses In the specific case of GGSN <--> UE, there are no switches and the GGSN has already configured the UE with the Interface ID. So, the GGSN already knows what the corresponding Solicited Node multicast address will be. In that case, sending an MLD Report will not benefit either the GGSN or the UE. > > I also wonder about text in Section 2, which says > that MLD should be on all interfaces from which > an application or upper-layer protocol has requested > reception of multicast packets. I wonder what "upper > layer" means in this particular case...? If it > means above IP then we could argue that we are following > the RFC. It means any code in the device that wishes to utilize IP multicast. Neighbor Discovery qualifies by that definition and it is the primary user of the Solicited Node multicast address. I believe that the important text is the first paragraph of Section 2: The purpose of Multicast Listener Discovery (MLD) is to enable each IPv6 router to discover the presence of multicast listeners (that is, nodes wishing to receive multicast packets) on its directly attached links, and to discover specifically which multicast addresses are of interest to those neighboring nodes. Since the GGSN already knows which link-local multicast addresses the UE is interested in, I believe the cellular host doc is compliant with RFC 2710. > > I also wonder if the timers -- which are configurable > per the RFC -- could be tuned to minimize overhead? Sure. Section 7 of RFC 2710 defines all the timers and identifies which ones can be modified. One final comment. The future evolution of 3GPP standards may lead towards more usage of IP multicast (including the subnet-local range). If that occurs, 3GPP will have to look very closely at how MLD (or MLDv2) fits in the architecture. Regards, 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 Jun 4 08:43:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g54Fh8rP021860; Tue, 4 Jun 2002 08:43:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g54Fh7RE021859; Tue, 4 Jun 2002 08:43:07 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g54Fh4rP021852 for ; Tue, 4 Jun 2002 08:43:04 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA03736 for ; Tue, 4 Jun 2002 08:43:06 -0700 (PDT) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA00195 for ; Tue, 4 Jun 2002 09:43:04 -0600 (MDT) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id SAA10697; Tue, 4 Jun 2002 18:42:57 +0300 Date: Tue, 4 Jun 2002 18:42:57 +0300 Message-Id: <200206041542.SAA10697@burp.tkv.asdf.org> From: Markku Savela To: itojun@iijlab.net CC: hesham.soliman@era.ericsson.se, ipng@sunroof.eng.sun.com In-reply-to: <525.1023196930@itojun.org> Subject: Re: Text for MLD - cellular host draft References: <525.1023196930@itojun.org> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: itojun@iijlab.net > > i still don't understand why you are trying to impose additional > restriction for link-local multicast groups (maybe i'm dumb). > without MLD joins for link-local multicast groups, default routers > won't be able to know which multicast group the 3GPP node is > interested in. there's no special text available in RFC2710 for > p2p links. Once again, I must have missed something. Why is there ever any reason to do MLD on any link-local group? - any host on link will automaticly receive all multicast traffic that is sent to link-local group, at least if it itself is listening that group. - what use would default router have for the info? There is nothing coming into link-local group from outside the link. Perhaps, the RFC just should say "MAY use MLD" for link-local groups, if someone really wants to do it for some reason. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 4 10:12:14 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g54HCErP021970; Tue, 4 Jun 2002 10:12:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g54HCDDJ021969; Tue, 4 Jun 2002 10:12:13 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g54HCArP021962 for ; Tue, 4 Jun 2002 10:12:10 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA24145 for ; Tue, 4 Jun 2002 10:12:13 -0700 (PDT) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA04624 for ; Tue, 4 Jun 2002 10:12:07 -0700 (PDT) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id UAA10797; Tue, 4 Jun 2002 20:12:02 +0300 Date: Tue, 4 Jun 2002 20:12:02 +0300 Message-Id: <200206041712.UAA10797@burp.tkv.asdf.org> From: Markku Savela To: msa@burp.tkv.asdf.org CC: itojun@iijlab.net, hesham.soliman@era.ericsson.se, ipng@sunroof.eng.sun.com In-reply-to: <200206041542.SAA10697@burp.tkv.asdf.org> (message from Markku Savela on Tue, 4 Jun 2002 18:42:57 +0300) Subject: Re: Text for MLD - cellular host draft References: <525.1023196930@itojun.org> <200206041542.SAA10697@burp.tkv.asdf.org> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: Markku Savela > > Once again, I must have missed something. Why is there ever any reason > to do MLD on any link-local group? Well, from other posts here, I guess it's to help those switches and such. However, it does somewhat bother me, that we have an exact specification, and before the standard is even ready, we are already adding things that are on the verge of "layer breaking". [ as far as IPv6 is concerned, anything you send to a link, is supposed to be seen by anyone on the link without any additional work] -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 4 11:54:29 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g54IsTrP023311; Tue, 4 Jun 2002 11:54:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g54IsTTK023310; Tue, 4 Jun 2002 11:54:29 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g54IsQrP023303 for ; Tue, 4 Jun 2002 11:54:26 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA17875 for ; Tue, 4 Jun 2002 11:54:27 -0700 (PDT) Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA02102 for ; Tue, 4 Jun 2002 11:54:27 -0700 (PDT) Received: from northrelay03.pok.ibm.com (northrelay03.pok.ibm.com [9.56.224.151]) by e3.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g54IsLBj108676; Tue, 4 Jun 2002 14:54:21 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.9.21]) by northrelay03.pok.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g54IsHd95838; Tue, 4 Jun 2002 14:54:18 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id g54IiwH01042; Tue, 4 Jun 2002 14:44:58 -0400 Message-Id: <200206041844.g54IiwH01042@rotala.raleigh.ibm.com> To: john.loughney@nokia.com cc: ipng@sunroof.eng.sun.com Subject: More review comments on cellular hosts... In-Reply-To: Message from "Tue, 04 Jun 2002 20:40:42 +0300." <0C1353ABB1DEB74DB067ADFF749C4EEFC65317@esebe004.NOE.Nokia.com> Date: Tue, 04 Jun 2002 14:44:58 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Here are some additional review comments from various IESG reviewers: > RFC 3155 should be added to the normative refs in my > opinion. I'm not opposed to keeping the non-normative > ref to the 2.5/3G TCP issues draft that started me on > this. Another reviewer: > Comments on draft-ietf-ipv6-cellular-host-02.txt > 2.4.1 says that the host must support receipt of > Neighbor Solicitation and Advertisement messages. > But 2.5.1 says "will not be sent or received" which might seem > conflicting at least with respect to the receive part. > DAD for 3041 addresses? > Will the router only have a link-local address on the link? > If not, how to detect a 3041 conflicting with one of the routers > addresses? > 2.12 - 3041 MAY be used. Do we want something stronger? > MLD: > multicast services. There is no need for MLD if the host only > supports the well-known (hard coded in IPv6 implementations) link > local multicast addresses. MLD is not used for listening on such > addresses. > Only applies to all-nodes address (ff02::1). > RFC2461 says that a node must join > the solicited-node multicast address(es) on multicast-capable interface, > and point-to-point interface are specifically treated as > point-to-point - Neighbor Discovery handles such links just like > multicast links. > > Thus per the letter of the specifications MLD must be implemented > by cellular hosts. > This also effects the need to support RFC2711 (section 2.10). > 2.11 > (IPv4 vs. IPv6). Cellular hosts should not support configured or > automatic tunnels to avoid unnecessary tunneling over the air > interface, unless there are no other mechanisms available. Tunneling > can lead to poor usage of available bandwidth. > The bandwidth concern is a reason not to *use* tunneling, but > the point about it being a last resort seems to say that it would > be useful to implement this. However, the text "should bot support" > seems to mean "should not implement". > Same issue for section 2.13 on 6to4 tunneling. > 2.15: and all useful hosts have at least a link-local address > and a larger scope address. So why not say "must be supported" > instead of qualifying it with a tautology? > 2.16 - add reference to RFC 3152. RFC 1886 talks about ip6.int > thus the ip6.arpa document must be referenced. > Section 3 - how about adding that future IPsec algoritms might be > useful/supported in the future. > Currently only DES, HMAC-MD5, and HMAC-SHA1 are listed. More comments: > AES is coming, should be supported in fugure. Mention this? > > The docuent is vague on key management. It basically doesn't say what > will be used for key management, and that begs the question of what > kind of interoperability will be achieved. > > If AKA is the solution, then this needs to be made more clear in the > document. Isn't it the case that AKA is what the overall > theme for 3GPP? > > What is needed is a clear statement on how interoperability with > regards to key management will be obtained. If this is not actually > known today, then the document should just say we haven't decided yet, > but will decide down the road. > > The document lists 7 authors. This number is considered on the high > side. See draft-rfc-editor-author-lists-00.txt (which is being Last > Called as we speak). -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 4 12:53:10 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g54Jr9rP023378; Tue, 4 Jun 2002 12:53:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g54Jr8rp023377; Tue, 4 Jun 2002 12:53:08 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g54Jr4rP023370 for ; Tue, 4 Jun 2002 12:53:04 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA01390 for ; Tue, 4 Jun 2002 12:53:06 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA26247 for ; Tue, 4 Jun 2002 13:54:16 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id BA4B16A906; Tue, 4 Jun 2002 22:52:58 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id C317D6A904; Tue, 4 Jun 2002 22:52:56 +0300 (EEST) Message-ID: <3CFD1AE1.2070507@kolumbus.fi> Date: Tue, 04 Jun 2002 22:54:09 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Thomas Narten Cc: john.loughney@nokia.com, ipng@sunroof.eng.sun.com Subject: Re: More review comments on cellular hosts... References: <200206041844.g54IiwH01042@rotala.raleigh.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=7.0 tests= version=2.20 X-Spam-Level: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thanks Thomas (and the IESG) for the comments. Some responses inline: >>RFC 3155 should be added to the normative refs in my >>opinion. I'm not opposed to keeping the non-normative >>ref to the 2.5/3G TCP issues draft that started me on >>this. Ok! >>2.4.1 says that the host must support receipt of >>Neighbor Solicitation and Advertisement messages. >>But 2.5.1 says "will not be sent or received" which might seem >>conflicting at least with respect to the receive part. Right. 2.4.1 and it's latest revs that have been discussed on the list is correct here. 2.5.1 should say "Duplicate Address Detection will not be initiated by the cellular host.". >>DAD for 3041 addresses? >>Will the router only have a link-local address on the link? >>If not, how to detect a 3041 conflicting with one of the routers >>addresses? Router will have only a link-local address on the link. >>2.12 - 3041 MAY be used. Do we want something stronger? Well, isn't the current keyword for 3041 essentially a MAY in the v6 standards? Note also that the cellular network privacy situation is not as bad as, say my fixed IP DSL situation. The prefixes change over time, as you turn off/on the device or go temporarily out of coverage. >>MLD: >> multicast services. There is no need for MLD if the host only >> supports the well-known (hard coded in IPv6 implementations) link >> local multicast addresses. MLD is not used for listening on such >> addresses. >>Only applies to all-nodes address (ff02::1). >>RFC2461 says that a node must join >>the solicited-node multicast address(es) on multicast-capable interface, >>and point-to-point interface are specifically treated as >> point-to-point - Neighbor Discovery handles such links just like >> multicast links. >> >>Thus per the letter of the specifications MLD must be implemented >>by cellular hosts. Discussion ongoing on the list though, see e.g. Brian's e-mail. >>This also effects the need to support RFC2711 (section 2.10). Yes. We could clarify the text in 2.10 to say that it is required if you do MLD. >>2.11 >> (IPv4 vs. IPv6). Cellular hosts should not support configured or >> automatic tunnels to avoid unnecessary tunneling over the air >> interface, unless there are no other mechanisms available. Tunneling >> can lead to poor usage of available bandwidth. > >>The bandwidth concern is a reason not to *use* tunneling, but >>the point about it being a last resort seems to say that it would >>be useful to implement this. However, the text "should bot support" >>seems to mean "should not implement". >>Same issue for section 2.13 on 6to4 tunneling. These have been, I believe, satisfactorily resolved after a discussion with Margaret: basically, we are letting the ngtrans design team to specify this, in the documents. >>2.15: and all useful hosts have at least a link-local address >>and a larger scope address. So why not say "must be supported" >>instead of qualifying it with a tautology? Ok! >>2.16 - add reference to RFC 3152. RFC 1886 talks about ip6.int >>thus the ip6.arpa document must be referenced. Sounds good. >>Section 3 - how about adding that future IPsec algoritms might be >>useful/supported in the future. >>Currently only DES, HMAC-MD5, and HMAC-SHA1 are listed. We actually had that at one point in time. We could add a note that some good algorithms are coming in the future. I fear that AES isn't an RFC yet. Don't want to reference I-Ds. >>The docuent is vague on key management. It basically doesn't say what >>will be used for key management, and that begs the question of what >>kind of interoperability will be achieved. >> >>If AKA is the solution, then this needs to be made more clear in the >>document. Isn't it the case that AKA is what the overall >>theme for 3GPP? >> >>What is needed is a clear statement on how interoperability with >>regards to key management will be obtained. If this is not actually >>known today, then the document should just say we haven't decided yet, >>but will decide down the road. All of the above is true, but then again this is an IP layer document and doesn't specify a complete system. Basically, I believe we are more or less equally vague with the IPv6 standards. In practise, the situation is likely the following: * IPsec in general will use IKE or its successors. * The IP multimedia system will use IPsec, but key itself via AKA-generated keys * Web, wap, etc. is likely to use TLS. I'm open to suggestions but I'm not sure exactly what we can say. Can we mandate key management and its interoperability in IPv6 standards? Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 4 15:33:50 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g54MXnrP023534; Tue, 4 Jun 2002 15:33:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g54MXnI4023533; Tue, 4 Jun 2002 15:33:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g54MXkrP023526 for ; Tue, 4 Jun 2002 15:33:46 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA23314 for ; Tue, 4 Jun 2002 15:33:48 -0700 (PDT) Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA20096 for ; Tue, 4 Jun 2002 16:34:59 -0600 (MDT) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id 0A8B91E095; Tue, 4 Jun 2002 18:33:47 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id SAA09240; Tue, 4 Jun 2002 18:33:46 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id PAA03809; Tue, 4 Jun 2002 15:33:46 -0700 (PDT) Message-Id: <200206042233.PAA03809@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: adamson@us.ibm.com Subject: Re: IPv6 MIBs - IPv4-mapped IPv6 addresses Cc: ipng@sunroof.eng.sun.com Date: Tue, 4 Jun 2002 15:33:45 -0700 Versions: dmail (solaris) 2.4/makemail 2.9b Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I think SIIT communication using v4-mapped addresses should be represented as InetAddressType ipv6(2), and InetAddress of ::ffff:x.y.z.q . >What is the relationship between a zone index and an IPv4-mapped IPv6 >address? Thanks! I think that some implementations provide the zone concept for IPv4 communication, but no sin_scope_id in the sockaddr_in; thus the way to provide zone info is to use AF_INET6 sockets and IPv4-mapped addresses to communicate via IPv4 on the wire. However, since the address family in the MIB is supposed to reflect the address family on the wire, ipv4z is required to represent the zone info when performing this trick. (The zone concept is useful in v4 in some of the same ways as in v6, e.g. two different zones both using 10.0.1/24) Bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 4 16:13:06 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g54ND6rP023564; Tue, 4 Jun 2002 16:13:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g54ND58q023563; Tue, 4 Jun 2002 16:13:05 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g54ND2rP023556 for ; Tue, 4 Jun 2002 16:13:02 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA22808 for ; Tue, 4 Jun 2002 16:13:04 -0700 (PDT) Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA05834 for ; Tue, 4 Jun 2002 16:13:04 -0700 (PDT) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id 5DA161E014; Tue, 4 Jun 2002 19:13:00 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id TAA09490; Tue, 4 Jun 2002 19:12:58 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id QAA04281; Tue, 4 Jun 2002 16:12:59 -0700 (PDT) Message-Id: <200206042312.QAA04281@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: Jari.Arkko@lmf.ericsson.se Subject: Re: Text for MLD - cellular host draft Cc: itojun@iijlab.net, bkhabs@nc.rr.com, hesham.soliman@era.ericsson.se, ipng@sunroof.eng.sun.com References: <525.1023196930@itojun.org> <3CFCD7AE.E27B07C2@lmf.ericsson.se> Date: Tue, 4 Jun 2002 16:12:58 -0700 Versions: dmail (solaris) 2.4/makemail 2.9b Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > As > Neighbor Discovery operates without relying on > MLD, joining on solicited node and all nodes > multicast addresses is not required. I read "join" to mean the action performed on the IP stack to indicate group membership (e.g. adding the group to the list of groups listened to and notifying the link), but I don't think that's what's intended here. Perhaps more specific wording, like "sending MLD reports for link-local multicast addresses is not required"? Bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 4 17:20:47 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g550KlrP023833; Tue, 4 Jun 2002 17:20:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g550Kl9O023832; Tue, 4 Jun 2002 17:20:47 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g550KirP023825 for ; Tue, 4 Jun 2002 17:20:44 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA13070 for ; Tue, 4 Jun 2002 17:20:46 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA15069 for ; Tue, 4 Jun 2002 18:20:46 -0600 (MDT) Message-ID: <007301c20c26$994df9b0$1e6015ac@T23KEMPF> From: "James Kempf" To: "Erik Nordmark" , References: Subject: Re: DNS discovery thoughts Date: Tue, 4 Jun 2002 17:18:59 -0700 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 Erik, I know there is considerable prejudice against SLP as a solution to the general problem, but it certainly is available. It supports discovery without a 3rd party. The only definitive criticism that I've ever heard about SLP is the coupling of a directory service function with service discovery. I think a place to start might be understanding what SLP does and why its critics don't like it. jak ----- Original Message ----- From: "Erik Nordmark" To: Sent: Tuesday, June 04, 2002 8:28 AM Subject: DNS discovery thoughts > > I've been thinking about the DNS discovery, as well as the larger > "service discovery with no 3rd party dependencies" issue, for a while. > > Just like Steve Deering and many others I'd like the IETF to explore > the larger issue, since I'm very much interested in making the future > Internet more robust than what we have today. > But this effort needs to be done carefully to make sure that we > are solving a well-defined and well-constrained problem. Thus I think > it would make sense to hold a BoF on this topic (perhaps in Yokohama > if there are folks willing to work on putting such a BoF together > in the very short time that remains). > > Level 1 of the current DNS discovery draft is likely to set a precedent > that well-known unicast addresses will be allocated for services. > The IETF has never done that before - we've only allocated well-known > *multicast* addresses for services. > Going down the path of allocating well-known unicast addresses, > even if they are site-local addresses, is something I would be > very uncomfortable doing, especially if it is done as a "quick fix" > for a short-term DNS discovery solution without knowing what a potential > future "service discovery with no 3rd party dependencies" scheme might > look like. This concern appears to be shared by some other IESG members > based on some discussions last week. > > These concerns would probably be less strong if the fixed unicast > address was one part of a larger architecture, in which the reservation > of fixed address was limited and necessary as part of an overall solution. > Instead, it appears that this particular choice is being driven by a > particular short-term problem with no apparent relationship to future and > more general work. > > > So if I was an implementor that wanted a DNS discovery solution as > soon as possible, I'd just go with DHCPv6 information-request for now, > while participating in the larger, and necessarily longer term, discussions > about "service discovery with no 3rd party dependencies". > > Comments? > Erik > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 4 17:56:58 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g550uwrP023970; Tue, 4 Jun 2002 17:56:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g550uwAQ023969; Tue, 4 Jun 2002 17:56:58 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g550usrP023962 for ; Tue, 4 Jun 2002 17:56:54 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA14227 for ; Tue, 4 Jun 2002 17:56:55 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA17877 for ; Tue, 4 Jun 2002 18:56:53 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g550ukM10886; Tue, 4 Jun 2002 20:56:47 -0400 (EDT) Message-Id: <200206050056.g550ukM10886@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "James Kempf" cc: "Erik Nordmark" , ipng@sunroof.eng.sun.com Subject: Re: DNS discovery thoughts In-reply-to: (Your message of "Tue, 04 Jun 2002 17:18:59 PDT.") <007301c20c26$994df9b0$1e6015ac@T23KEMPF> Date: Tue, 04 Jun 2002 20:56:46 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk actually, SLP seems like a much better fit than DNS for the problem of discovering hosts on an ad hoc network - not just because SLP is desinged to work without an third-party server but also because "service discovery" seems to fit the likely use model better than "host name lookup". in particular, you've got no good way of ensuring unique and meaningful host names for hosts on an ad hoc network - they can't assert their normal DNS names (even if they have such) because such assertions might conflict with DNS, or with one another - so it doesn't match DNS "one RRset per name" semantics at all. and the very notion of zero configuration seems to imply that such hosts don't know what their (human meaningful, user assigned) names are - they can at most advertise what service(s) they provide and their serial #s and let applications look for them. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 4 18:02:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g5512NrP023990; Tue, 4 Jun 2002 18:02:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g5512NRP023989; Tue, 4 Jun 2002 18:02:23 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g5512KrP023982 for ; Tue, 4 Jun 2002 18:02:20 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA22839 for ; Tue, 4 Jun 2002 18:02:21 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA24761 for ; Tue, 4 Jun 2002 19:03:32 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id A75124B24; Wed, 5 Jun 2002 10:02:15 +0900 (JST) To: Keith Moore Cc: ipng@sunroof.eng.sun.com In-reply-to: moore's message of Tue, 04 Jun 2002 20:56:46 -0400. <200206050056.g550ukM10886@astro.cs.utk.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: DNS discovery thoughts From: itojun@iijlab.net Date: Wed, 05 Jun 2002 10:02:15 +0900 Message-ID: <5582.1023238935@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >actually, SLP seems like a much better fit than DNS for the >problem of discovering hosts on an ad hoc network - not just >because SLP is desinged to work without an third-party >server but also because "service discovery" seems to fit the >likely use model better than "host name lookup". > >in particular, you've got no good way of ensuring unique >and meaningful host names for hosts on an ad hoc network - >they can't assert their normal DNS names (even if they have >such) because such assertions might conflict with DNS, >or with one another - so it doesn't match DNS "one RRset >per name" semantics at all. and the very notion of zero >configuration seems to imply that such hosts don't know >what their (human meaningful, user assigned) names are - >they can at most advertise what service(s) they provide >and their serial #s and let applications look for them. you seem to be mixing two things up... the former paragraph speaks about "discovery of DNS server", the latter paragraph speaks about "name resolution under environment without DNS server". 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 Jun 4 18:07:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g5517arP024050; Tue, 4 Jun 2002 18:07:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g5517YFE024049; Tue, 4 Jun 2002 18:07:34 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g5517VrP024042 for ; Tue, 4 Jun 2002 18:07:31 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA25554 for ; Tue, 4 Jun 2002 18:07:32 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA26829 for ; Tue, 4 Jun 2002 19:08:43 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5514pM10981; Tue, 4 Jun 2002 21:04:51 -0400 (EDT) Message-Id: <200206050104.g5514pM10981@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: itojun@iijlab.net cc: Keith Moore , ipng@sunroof.eng.sun.com Subject: Re: DNS discovery thoughts In-reply-to: (Your message of "Wed, 05 Jun 2002 10:02:15 +0900.") <5582.1023238935@itojun.org> Date: Tue, 04 Jun 2002 21:04:50 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk sorry, I was even more confused than that - I got two message threads from different groups mixed up. please disregard my previous message. > >actually, SLP seems like a much better fit than DNS for the > >problem of discovering hosts on an ad hoc network - not just > >because SLP is desinged to work without an third-party > >server but also because "service discovery" seems to fit the > >likely use model better than "host name lookup". > > > >in particular, you've got no good way of ensuring unique > >and meaningful host names for hosts on an ad hoc network - > >they can't assert their normal DNS names (even if they have > >such) because such assertions might conflict with DNS, > >or with one another - so it doesn't match DNS "one RRset > >per name" semantics at all. and the very notion of zero > >configuration seems to imply that such hosts don't know > >what their (human meaningful, user assigned) names are - > >they can at most advertise what service(s) they provide > >and their serial #s and let applications look for them. > > you seem to be mixing two things up... > the former paragraph speaks about "discovery of DNS server", the > latter paragraph speaks about "name resolution under environment > without DNS server". > > 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 Jun 4 22:27:15 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g555RFk7024461; Tue, 4 Jun 2002 22:27:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g555RFWN024460; Tue, 4 Jun 2002 22:27:15 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g555RBk7024453 for ; Tue, 4 Jun 2002 22:27:11 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA08807 for ; Tue, 4 Jun 2002 22:27:13 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA13027 for ; Tue, 4 Jun 2002 22:27:12 -0700 (PDT) Received: by p2.piuha.net (Postfix, from userid 962) id 64F146A906; Wed, 5 Jun 2002 08:27:06 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 8AD366A904; Wed, 5 Jun 2002 08:27:04 +0300 (EEST) Message-ID: <3CFDA171.4060200@kolumbus.fi> Date: Wed, 05 Jun 2002 08:28:17 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Bill Fenner Cc: itojun@iijlab.net, bkhabs@nc.rr.com, hesham.soliman@era.ericsson.se, ipng@sunroof.eng.sun.com Subject: Re: Text for MLD - cellular host draft References: <525.1023196930@itojun.org> <3CFCD7AE.E27B07C2@lmf.ericsson.se> <200206042312.QAA04281@windsor.research.att.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=7.0 tests= version=2.20 X-Spam-Level: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bill Fenner wrote: >> As >> Neighbor Discovery operates without relying on >> MLD, joining on solicited node and all nodes >> multicast addresses is not required. > > I read "join" to mean the action performed on the IP stack to indicate > group membership (e.g. adding the group to the list of groups listened > to and notifying the link), but I don't think that's what's intended > here. Perhaps more specific wording, like "sending MLD reports for > link-local multicast addresses is not required"? Yes. Thanks. Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 5 00:03:26 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5573Qk7024619; Wed, 5 Jun 2002 00:03:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5573Q4I024618; Wed, 5 Jun 2002 00:03:26 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5573Nk7024611 for ; Wed, 5 Jun 2002 00:03:23 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA00323 for ; Wed, 5 Jun 2002 00:03:24 -0700 (PDT) Received: from delta.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA15041 for ; Wed, 5 Jun 2002 00:54:45 -0600 (MDT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g555U4R01993; Wed, 5 Jun 2002 12:30:50 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: "James Kempf" cc: "Erik Nordmark" , ipng@sunroof.eng.sun.com Subject: Re: DNS discovery thoughts In-Reply-To: <007301c20c26$994df9b0$1e6015ac@T23KEMPF> References: <007301c20c26$994df9b0$1e6015ac@T23KEMPF> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 05 Jun 2002 12:30:04 +0700 Message-ID: <1991.1023255004@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 4 Jun 2002 17:18:59 -0700 From: "James Kempf" Message-ID: <007301c20c26$994df9b0$1e6015ac@T23KEMPF> | I think a place to start might be understanding what SLP does and why | its critics don't like it. I agree. Certainly SLP (or even if necessary, a SLP subset) looks like a much better fit to the problem than anything depending upon well known addresses (which seems to have as its prime benefit only that no new code needs to be written to implement it, just pick the addresses and stick them in the current configuration files - which as a design feature is about the last consideration I'd be using in choosing a solution) kre ps: there's much more info to discover than where a DNS back end is located (please everyone, stop calling this a DNS server, finding DNS servers isn't what we need, it is the DNS back end resolver that we are seeking) - the one which concerns me most is how a host auto-configures its hostname (when it isn't using DHCP). Though from Keith's messages it seems that someone else somewhere else might be considering that question. What list was that on Keith? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 5 02:42:21 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g559gKk7024897; Wed, 5 Jun 2002 02:42:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g559gKAE024896; Wed, 5 Jun 2002 02:42:20 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g559gGk7024889 for ; Wed, 5 Jun 2002 02:42:17 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g559gFg05717; Wed, 5 Jun 2002 11:42:15 +0200 (MEST) Date: Wed, 5 Jun 2002 11:41:09 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Text for MLD - cellular host draft To: Jari Arkko Cc: itojun@iijlab.net, bkhabs@nc.rr.com, "Hesham Soliman (ERA)" , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3CFCD7AE.E27B07C2@lmf.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > MLD, joining on solicited node and all nodes > multicast addresses is not required. The term "joining" could mean e.g. "record the group membership in the IP stack". Saying "sending MLD reports" would be much more exact for what you are trying to say. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 5 03:35:04 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g55AZ3k7024996; Wed, 5 Jun 2002 03:35:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g55AZ3QG024995; Wed, 5 Jun 2002 03:35:03 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g55AYxk7024988; Wed, 5 Jun 2002 03:34:59 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA21469; Wed, 5 Jun 2002 03:35:00 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA10847; Wed, 5 Jun 2002 03:35:00 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id DCA744B24; Wed, 5 Jun 2002 19:34:56 +0900 (JST) To: v6-lists: ; 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: IETF54: IPv6 showroom From: itojun@iijlab.net Date: Wed, 05 Jun 2002 19:34:56 +0900 Message-ID: <15613.1023273296@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk sorry for off topic posting. when you come to tokyo for IETF54, do not forget to visit IPv6 demonstration booth operated by promotion council. they have whole bunch of IPv6-ready gadgets. it is in central Tokyo so you need 1 hour train ride from the venue. http://contents.pr.v6pc.jp/apwg/en/event_sr01.html (IPv4 only right now, should be reachable over IPv6 soon) 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 Jun 5 04:02:34 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g55B2Yk7025112; Wed, 5 Jun 2002 04:02:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g55B2YGn025111; Wed, 5 Jun 2002 04:02:34 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g55B2Vk7025104 for ; Wed, 5 Jun 2002 04:02:31 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA03880 for ; Wed, 5 Jun 2002 04:02:32 -0700 (PDT) From: lassi.hippelainen@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA28427 for ; Wed, 5 Jun 2002 05:02:31 -0600 (MDT) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g55B2u620538 for ; Wed, 5 Jun 2002 14:02:56 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 5 Jun 2002 14:02:29 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 5 Jun 2002 14:02:29 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: DNS discovery thoughts Date: Wed, 5 Jun 2002 14:02:29 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DNS discovery thoughts Thread-Index: AcIL3S6iV/rEyZtQSJa3y0vACP/VNgAmfu4Q To: X-OriginalArrivalTime: 05 Jun 2002 11:02:29.0365 (UTC) FILETIME=[7BE38250:01C20C80] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g55B2Vk7025105 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > -----Original Message----- > From: ext Erik Nordmark [mailto:Erik.Nordmark@sun.com] > Sent: Tuesday, June 04, 2002 6:29 PM > To: ipng@sunroof.eng.sun.com > Subject: DNS discovery thoughts > > > > I've been thinking about the DNS discovery, as well as the larger > "service discovery with no 3rd party dependencies" issue, for a while. The same problem has been in my mind. And I think I solved it. The solution seems so outrageously simple that there must be something that I have missed... Anyway, my problem appears in 3GPP networks. A roaming mobile may connect to a visited network without any idea of its service configuration. The service discovery and client configuration mechanism shouldn't use extra messages to 3rd parties, because each packet over the air carries a price tag. What I wanted is an architecture that can deliver all services - past, present, and future - without first having to configure the mobile end. The solution: ask the Janitor. * If I visit a strange building and want to know how the plumbing works, what will I do? I'll go and ask the Janitor. The network analogy would be a Virtual Janitor that knows which server provides which service(s). The visitor needs only the address of the Janitor, which can be preconfigured. No "discovery" needed. * For example, the visitor wants the IP address of something. The DNS request goes to the Janitor address, and the Janitor responds with the number. In fact it was the local DNS service who responded, but the visitor doesn't care. * The Janitor isn't a 3rd party. It is implemented as a well-known anycast address that every server listens at. They read the Janitor packets, and if the packet belongs to a service that the server is configured to provide, it responds to it. It is up to the network admin to make sure that one and only one server responds - the usual anycast management requirement. That wraps up the basic idea. The Janitor service provides built-in possibility of resilience and load balancing. It doesn't need any changes to existing application protocols or clients. They just configure the Janitor as the default server. The Janitor address should be from the IANA range (RFC2526). There is no other need to allocate identifiers. The servers that participate in the Janitor service will use the existing protocol and port numbers as triggers. Even application layer triggers can be used, because the servers (and applications) will decide themselves which packets they react to. I haven't done any serious security analysis yet. One potential problem comes from load balancing. If a stateful application is supported by several hosts, the client needs to know the real address of the host that keeps the state. The service address changes from the Janitor address to the real address, and that obviously opens the possibility of session hijack and spoofing attacks. Giving the real address would also act as an optimization. For example, the DNS client could cache the source address of the first DNS response, and use it in stead of the anycast address, saving the other servers some trouble. My two cents so far... -- Lassi -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 5 09:47:11 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g55GlBk7025422; Wed, 5 Jun 2002 09:47:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g55GlB3j025421; Wed, 5 Jun 2002 09:47:11 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g55Gl7k7025414 for ; Wed, 5 Jun 2002 09:47:07 -0700 (PDT) Received: from lillen ([192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g55GkxK24722; Wed, 5 Jun 2002 18:46:59 +0200 (MEST) Date: Wed, 5 Jun 2002 18:45:49 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Comments on draft-ietf-ipngwg-ipv6-anycast-analysis To: itojun@iijlab.net, ettikan.kandasamy.karuppiah@intel.com Cc: ipng@sunroof.eng.sun.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The anycast-analysis has been sitting in front of Thomas and I for quite a long time while we were trying to figure out if the IETF needs to do something more significant in the anycast space (such as an anycast WG; such as a way to resolve or at least document the differences between the IPv4 DNS anycast usage and the IPv6 architecture). But it is time to finish this document since it provides useful information. So here are our comments on draft-ietf-ipgnwg-ipv6-anycast-analysis-00.txt In general this is a quite useful document since it attempts to write things down that haven't been written down before. But it makes sense to make the document more clear and succinct, and perhaps also to add some missing pieces to give a more complete picture. Note that there are duplicate comments from Erik and Thomas here - hopefully they are consistent and not contradictory :-) Comments from Erik ------------------ I completely fail to see what section 1.1 is trying to say other than "there are different forms of anycast". It assigns the tag "BGP" anycast to both the Hardie and Ohta-san document, even though only the latter is an interdomain anycast scheme. And contrasting this against RFC 1546 seems odd, since RFC 1546 doesn't say anything whether it limits itself to intradomain anycast or not. Section 1.1 doesn't mention (but section 2.1 does) that RFC 1546 and RFC 2373 are different with respect to being able to syntactically distinguish between unicast and anycast, which seems to be an important technical difference. What high-level thing is section 1.1 trying to say? > RFC2373 IPv6 anycast is very similar to RFC1546 IPv4 anycast. The Given RFC 1546's suggestion to use a separate range of addresses for anycast, this doesn't seem to be true. > BGP anycast tries to replicate unicast servers in distant domains. The > distribution of servers is worldwide. BGP anycast is being used for > specific upper-layer protocols only, like DNS and HTTP. There is no > consideration given for the cases when a client contacts multiple > servers by chance (transport layer protocol will get confused), since it > is unlikely to see BGP route changes during the short lifetime of the > transport layer protocols being used. While typically http connections might be short, there is nothing in the http protocol that mandates or assumes that they are short. ---- Section 2.2 says: After we have discovered the unicast address of the server, we should use the server's unicast address for the protocol exchange. It would be useful to state something about this security implications (or high-level requirements) when doing something like that in the security considerations section. Section 2.3 should at a minimum have a "not yet" added - the magma WG is chartered to extend MLD to allow hosts to join anycast groups. But perhaps it can be written more in the form of When RFC 2373 was written there was no standard way for hosts to join anycast groups (short of having the hosts fully participate in the routing protocol which has trust issues). Therefore, ... If this section talks about the intent to extend MLD to support anycast, it would also be useful to add a sentence or two about the security issues in this area in the security considerations section. Section 2.4 is correct, but doesn't help people understand what the technical issues are in having a single source address identify more than one node. Since these implications are not written down anywhere as far as I know, it would make sense to add the currently known implications in this document. The ones I'm aware of are: - Incorrect reassembly of fragmented packets due to multiple anycast members sending packets with the same fragment ID to the same destination at about the same time; the same the source IP address, destination IP address, nextheader, and fragment ID numbers might be accidentally used at the same time by different senders. - Errors and other response packets might be delivered to a different anycast member than sent the packet. This might be very likely since asymmetric routing is rather prevalent on the Internet. Particular cases of such errors that are known to cause protocol problems are - ICMP packet too big making path MTU discovery impossible. - The misdelivery of other errors might cause operational problems - making the network harder to trouble-shoot when anycast source addresses are used. Section 2.5. Aren't there also replay protection issues when manual keying is used for anycast addresses? (Such issues exist for multicast and manual keying, so I'd be surprised if they didn't exist for anycast.) Section 3.1 last paragraph seems to say that anycast can never be used interdomain due to route scaling issues. This is clearly the case if there are lots of interdomain anycast addresses being used. But having lots of global anycast addresses where the anycast members are in the same topological region, would presumably automatically be aggregated as part of the prefix for advertised by that topological region. (Whether one would call this interdomain or intradomain is an interesting terminology issue; the point is that the anycast service provided by multiple nodes in a single domain is accessible from outside the domain.) Section 3.4 and 3.5 don't seem to be finished - they just contain a "TBD". Is there something which you intended to put in there? If not, presumably the sections can be dropped. (The document doesn't *have to* suggest improvement everywhere.) Section 4.1 says: > Note that, however, bad guys can still inject fabricated results to the > client, even if the client checks the source address of the reply. The > check does not improve security of the exchange at all. I think that DNS folks would disagree with that. Having the resolver check the source address of replies prevents, when ingress filtering is in use, off-path attackers from spoofing responses. Thus it adds some non-zero amount of protection to do this. Same IMHO incorrect statement is repeated in this section: > The source address check itself has no real protection It might make sense, for DNS query/replies over UDP, to instead look into relaxing the anycast source address restriction under appropriate constraints (e.g. must not send larger than MIN MTU since path MTU discovery is unlikely to work). Another possibility, which you may or may not want to add to the document, is to specify a protocol which can establish a binding between the anycast address and the unicast address of one of its members with as much security as the routing system provides for routing packets to the anycast address in the first place. IMHO such a protocol can be built by reusing pieces of MIPv6. I think (but I haven't verified) that (many) tftp implementations verify the source address. Perhaps I'm confused and it is only the server that does this and not the client. But using TFTP as an example of how secure protocols should be done is not a very strong argument to say the least. NITS: > destination node, out of a group of destination nodes. IP datagram will s/IP/The IP/ > If multiple packets carry an anycast address in IPv6 destionation Spell check needed - "destionation"? > check source address, based on RFC2181 section 4.1. TFTP The "TFTP" looks like extra characters at the end of the line. References: The Hardie document is now RFC 3258. Comments from Thomas: -------------------- > destination node. The destination node is identified by an unicast s/an unicast/a unicast/ >destination node, out of a group of destination nodes. IP datagram will s/datagram/datagrams/ ? (or "An IP datagram") > based on routing measure of distance. The source node does not need to s/on/on the/ > Today, there are so-called "anycast" operated mostly for critical > servers including DNS servers and web servers (like those for Olympic > games) [Hardie, 2001; Ohta, 2000] . We call the technique "BGP anycast" Sentence doesn't parse. s/"anycast"/"anycast" services/ Also, name "BGP anycast" is not really very accurate. draft-ietf-dnsop-hardie-shared-root-server-03.txt doesn't rely on BGP only. The technique works also within a single AS where no BGP is used. > o A provider-independent IPv4 address prefix is allocated from an RIR. Not required that the address be PI. > o The address prefix is configured at multiple distant locations on the > Internet. > o BGP routes are advertised from all of the locations. Not sure what this means, especially the first bullet. > BGP anycast tries to replicate unicast servers in distant domains. The Not sure I agree. The replication is within a single AS. That may or may not involve services is "distant domains". Maybe you want to say something like: BGP anycast tries to replicate unicast servers in different topological locations. > distribution of servers is worldwide. BGP anycast is being used for > specific upper-layer protocols only, like DNS and HTTP. There is no Where is it being used for HTTP? The documents you cite talk about DNS and UDP exclusively. > specific upper-layer protocols only, like DNS and HTTP. There is no > consideration given for the cases when a client contacts multiple > servers by chance (transport layer protocol will get confused), since it > is unlikely to see BGP route changes during the short lifetime of the > transport layer protocols being used. It is misleading to say this is all a BGP issue. The Hardie document says that within an AS routes are advertised statically (even if a particular server becomes unavailable) precisely so that routes stay pinned and don't change. Note that this is within an AS, so its not just BGP. > RFC2373 anycast is defined in more generic manner, and does not limit > the routing infrastructure nor upper-layer protocol, Therefore, RFC2373 The first part of the sentence suggests that 2373 does NOT limit upper-layer protocols. This would imply that the "BGP" approach does. Actually, some might argue the opposite. 2373 says a source address cannot be an anycast address. This implies that higher-layer protocols that make use of anycast addresses need to be changed to understand anycast addressing. This is in contrast with the BGP approach. > depending on stability of the routing table. The property leads to a > couple of interesting symptoms. s/symptoms/observations/ ? > protocol exchange. If we use more than 2 packets, 1st and 2nd packet s/exchange/exchanges/ Text should make clear that it assumes when server responds, source address is unicast, not anycast. And point out that this causes problems for some existing protocols. --- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 5 10:50:42 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g55Hogk7025511; Wed, 5 Jun 2002 10:50:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g55Hofa3025510; Wed, 5 Jun 2002 10:50:41 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g55Hobk7025503 for ; Wed, 5 Jun 2002 10:50:38 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA13214 for ; Wed, 5 Jun 2002 10:50:39 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA05967 for ; Wed, 5 Jun 2002 11:51:53 -0600 (MDT) Received: from kenawang ([147.11.233.11]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id KAA22434 for ; Wed, 5 Jun 2002 10:49:23 -0700 (PDT) Message-Id: <4.2.2.20020605134805.0245def0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 05 Jun 2002 13:50:36 -0400 To: ipng@sunroof.eng.sun.com From: Margaret Wasserman Subject: Fwd: IPv6 Scoped Addresses and Routing Protocols Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I sent the attached message to the routing area discussion list. I thought that people on the IPv6 list might be interested in this discussion, so I will forward a message containing the responses after this one. I suppose I just should have cc:ed the IPv6 group in the first place... Margaret >Date: Fri, 24 May 2002 12:17:04 -0400 >To: routing-discussion@ietf.org >From: Margaret Wasserman >Subject: IPv6 Scoped Addresses and Routing Protocols > > > >Hi All, > >I raised some questions with Bill Fenner in Minneapolis regarding IPv6 scoped >addressing and our current IPv6 routing protocol specifications, and Bill suggested >that I should send my questions to this list for discussion. So, here they are. > >First, some background... > >As many of you probably know, IPv6 includes the concept of scoped unicast >addressing -- a unicast address can have link-local scope, site-local scope >or global scope. The address scopes are defined in the IPv6 Addressing >Architecture: > >http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-addr-arch-v3-07.txt > >Additional information can be found in the IPv6 Scoped Address >Architecture: > >http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-scoping-arch-03.txt > >I would suggest that all of you read the IPv6 Scoped Address Architecture >document, if you haven't already, as it contains information regarding >the expected configuration and forwarding behaviour of IPv6 routers. >It also defines the concept of an IPv6 site, which is important to understanding >the questions that I am about to raise. > >In IPv6, there is a concept of site-local addressing that is quite different >from the concept of "net 10" addresses in IPv4. Sites are administratively >defined entities that must be "convex" (i.e. the best route between two nodes >in the site must, at all scopes, fall completely within the site). Sites boundaries >run through routers, so a single router (called a site border router (SBR)) can >have interfaces in more than one site. And, IPv6 site-local addresses can be >used for site-constrained communication, even when a site is globally >connected and global addresses are available. > >Because all site-local addresses use the same well-known site-local prefix, the >only way to tell that a particular site-local address belongs to a particular >site is to know which site originated the address. SBRs will need >to enforce site boundaries, not mixing site-local routing information, and not >forwarding packets outside of a given site. To do this, it is expected that >SBRs will need to maintain multiple "conceptual routing tables", including one >site-local routing table for each attached site, and one global routing table. > >Unfortunately, I can't find any indication that these concepts have been reflected >in the current IPv6 routing protocols. None of our IPv6 routing protocol documents >deal with site-local boundaries or SBR behaviour explicitly. > >There are currently four standards for how IPv6 routes will be handled in BGP, OSPF, >IS-IS and RIP. I will refer to these documents as BGP-IPv6, OSPF-IPv6 and IS-IS-IPv6, >and RIP-IPv6 respectively: > >Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing: >http://www.ietf.org/rfc/rfc2545.txt > >OSPF for IPv6 >http://www.ietf.org/rfc/rfc2740.txt > >Routing IPv6 with IS-IS: >http://www.ietf.org/internet-drafts/draft-ietf-isis-ipv6-02.txt > >RIPng for IPv6 >http://www.ietf.org/rfc/rfc2080.txt > >So here are my actual questions: > >(1) Are the statements regarding the routing system in the IPv6 Scoped Addressing Architecture >draft valid? Will they work in real life? Please read it, and comment to the IPv6 WG if you think that >there are any issues with what it says. > >(2) BGP-IPv6: > >BGP-IPv6 states: "As this document makes no assumption on the characteristics of a particular >routing realm where BGP-4 is used, it makes no distinction between global and site-local addresses >and refers to both as "global" or "non-link-local"." > >Would it ever be reasonable for BGP to propagate site-local routing information? Why, under >what circumstances? Would it be reasonable to assume that an Inter-Domain Routing protocol >shouldn't propagate site-local information at all? > >If BGP should be capable of propagating site-local information, will it be possible, using existing >BGP standards for a BGP SBR router with four interfaces (A, B, C & D), in two sites (A & B in S1, >and C & D in S2) to maintain two separate sets of information for prefix FEC0::/10, one that applies >to S1 (interfaces A & B) and one that applies to S2 (interfaces C & D), and to propagate that information >accordingly? Is this really just an issue of configuring the router properly, as BGP-IPv6 implies? > >(3) OSPF-IPV6: > >In this specification, no distinction is made between site-local and global addresses. Unlike the >previous specification (BGP-IPv6), this assumption is not stated up-front. Instead, everywhere in >the draft where either site-local or global addresses are mentioned they are both mentioned (i.e. >"site-local or global IPv6 addresses"). > >Again this specification makes no provision for separate sets of site local information. There is >also no mention of a boundary for site-local route propagation, and no mention of multiple conceptual >sets of site-local routing information. Would it make sense to tie the concept of an IPv6 site to >one of the existing propagation boundaries in OSPF, such as an OSPF area? Or to assume that >an OSPF AS will always be completely contained within one site -- which is what the current draft >seems to assume? > >(4) IS-IS-IPv6: > >IS-IS-IPv6 makes no mention of site-local or scoped addressing at all. Is this appropriate? How will IS-IS >SBRs know not to propagate site-local routing information between two attached sites? I don't yet >know enough about IS-IS to understand how site-local routing information would best be handled >in IS-IS. Any thoughts? > >(5) RIP-IPv6: > >The RIP-IPv6 document explicitly states that there is a single IPv6 routing table, and it makes no >mention of sites. I think it would be fine to constrain RIP to operating within a single IPv6 >site, but that should be explicitly stated somewhere. > >(6) Will the MIBs for any of these routing tables be capable of representing multiple independent, >possibly overlapping sets of site-local routing information? I looked them over quickly, and it >wasn't immediately obvious to me how they could do this. > >(7) Do you think that there would be some utility to defining the actual routing architecture (as >opposed to just the addressing architecture) for IPv6? If so, what would be the best way to do >that? > >(8) Should we mention link-local addresses anywhere in these specifications? We certainly would >not want to propagate routing information for link-local addresses. > >If there is some work that needs to be done here, I am very happy to provide some IPv6 expertise >to that effort. > >Margaret > > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 5 10:58:52 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g55Hwqk7025534; Wed, 5 Jun 2002 10:58:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g55HwqfH025533; Wed, 5 Jun 2002 10:58:52 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g55Hwmk7025526 for ; Wed, 5 Jun 2002 10:58:48 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA23600 for ; Wed, 5 Jun 2002 10:58:50 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA00314 for ; Wed, 5 Jun 2002 10:58:50 -0700 (PDT) Received: from kenawang ([147.11.233.11]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id KAA28847 for ; Wed, 5 Jun 2002 10:57:34 -0700 (PDT) Message-Id: <4.2.2.20020605135542.0246c6c0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 05 Jun 2002 13:58:49 -0400 To: IPng@sunroof.eng.sun.com From: Margaret Wasserman Subject: Fwd: Re: IPv6 Scoped Addresses and Routing Protocols Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >X-Sender: ncbelkov@pop.theworld.com >Date: Fri, 24 May 2002 21:29:52 -0400 >To: Margaret Wasserman , routing-discussion@ietf.org >From: Jeff Parker >Subject: Re: IPv6 Scoped Addresses and Routing Protocols > >At 12:17 PM -0400 5/24/02, Margaret Wasserman wrote: >>I raised some questions with Bill Fenner in Minneapolis regarding IPv6 scoped >>addressing and our current IPv6 routing protocol specifications >>... >>(4) IS-IS-IPv6: >> >>IS-IS-IPv6 makes no mention of site-local or scoped addressing at all. Is this appropriate? How will IS-IS >>SBRs know not to propagate site-local routing information between two attached sites? I don't yet >>know enough about IS-IS to understand how site-local routing information would best be handled >>in IS-IS. Any thoughts? > >Margaret - > I don't know anymore about site-local than what I've read above, but perhaps I can help with how you might use ISIS. > ISIS is used today is as an interior routing protocol. The boarder routers run ISIS on the 'inside' ('in site', in your terminology?) and use BGP to peer with the rest of the world. In this scheme, BGP could filter out the site addresses when communicating with the outside. > Neither IS-IS nor OSPF scales past a certain size, somewhere in the 100 to 1000 router range. But both have the notion of an area, and it should be possible to connect multiple sites (areas) together using the ISIS Level 2 notion, or OSPFs Area 0. There would have to be provision to filter site address announcements from leaking into Level 2 (Area 0) if you tied multiple sites together with the IGP. > >- jeff parker >From: Francis Dupont >To: Margaret Wasserman >cc: routing-discussion@ietf.org >Subject: Re: IPv6 Scoped Addresses and Routing Protocols >Date: Sat, 25 May 2002 18:48:50 +0200 >Sender: Francis.Dupont@enst-bretagne.fr >X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr > > In your previous mail you wrote: > > Sites boundaries run through routers, so a single router (called a > site border router (SBR)) can have interfaces in more than one site. > >=> a SBR is a nightmare... It needs a scoped routing table in the kernel >and separate IGPs for each site. I don't want to imagine how we can >support site reconfiguration on a running SBR. > > SBRs will need to enforce site boundaries > >=> this part is easy: a very small number of lines of code in the forwarding >routine. > > not mixing site-local routing information > >=> this is called a scoped routing table (zoned should be a better term >but unfortunately it is too late to fix RFC 2553 or even 2553bis...) > > and not forwarding packets outside of a given site. > >=> this is "enforcing site boundaries", isn't this? > > To do this, it is expected that SBRs will need to maintain multiple > "conceptual routing tables", including one site-local routing table > for each attached site, and one global routing table. > >=> in fact usually a zone ID is added to addresses for the same result. > > None of our IPv6 routing protocol documents deal with site-local > boundaries or SBR behaviour explicitly. > >=> one can expect a site is a routing domain and an internal gateway protocol >should be run in the site. As routing protocols carry raw addresses (i.e., >in a case of a scoped address, the address without its zone indication) >this is the only reasonable way. > > Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing: > http://www.ietf.org/rfc/rfc2545.txt > >=> two remarks: > - usually BGP is used as an inter-domain routing protocol so is supposed > to manage routes for global prefixes. > - the issue is partially addressed in the section 2 (partially == not > fully solved). >In fact, the multi-protocol feature of BGP 4+ provides some ways to carry >extra information in a NLRI. For instance, we can reuse a VPN-like >(cf RFC 2547) way to manage site-local addresses with site identifiers. > > RIPng for IPv6 > http://www.ietf.org/rfc/rfc2080.txt > >=> its poor scalability makes RIPng a bad candidate for multi-sited stuff. > > So here are my actual questions: > > (2) BGP-IPv6: > > Would it ever be reasonable for BGP to propagate site-local routing > information? > >=> I've already answered this should be possible in the hard (== multi-sited) >case. Personally I believe site-local addresses should be reserved to the >not-connected organizations: the "non-link-local" argument applies. >(PS: here not-connected is at the network layer) > > Why, under what circumstances? > >=> very large not-connected organizations? > > Would it be reasonable to assume that an Inter-Domain Routing protocol > shouldn't propagate site-local information at all? > >=> I'd like to say site-local information should not cross site boundaries. > > If BGP should be capable of propagating site-local information, > will it be possible, using existing BGP standards for a BGP SBR router > with four interfaces (A, B, C & D), in two sites (A & B in S1, and C & > D in S2) to maintain two separate sets of information for prefix > FEC0::/10, one that applies to S1 (interfaces A & B) and one that > applies to S2 (interfaces C & D), and to propagate that information > accordingly? > >=> I am not an expert of RFC 2547 but site-local addressing fulfills >the 1.3 requirement about overlapping address spaces so a similar >tagging of site-local addresses (RFC 2547 adds a "Route Distinguisher" >which identifies a VPN, we can use the same concept for identifications >of sites) should work. > > Is this really just an issue of configuring the router properly, as > BGP-IPv6 implies? > >=> not for the multi-sited case because a router is not supposed to run >more than one BGP-IPv6 process. But in other cases I agree with the >suggession of BGP-IPv6 (i.e., I still believe BGP-IPv6 doesn't need >to be updated). > > (3) OSPF-IPV6: > >=> OSPF-IPv6 has the new (over OSPFv2) property that one is allowed to >run more than one OSPF-IPv6 process per router. So with a dangerous but >possible configuration the multi-sited case can be handled. > > Unlike the previous specification (BGP-IPv6), this assumption is > not stated up-front. Instead, everywhere in the draft where either > site-local or global addresses are mentioned they are both mentioned > (i.e. "site-local or global IPv6 addresses"). > >=> results are 5 and 80 pages (totally unfair comparison :-)! > > Or to assume that an OSPF AS will always be completely contained > within one site -- which is what the current draft seems to assume? > >=> I agree but this is not a limitation because one may run multiple >OSPF-IPv6 processes per router, i.e. put a router in multiple ASs. > > (4) IS-IS-IPv6: > > Any thoughts? > >=> I believe IS-IS-IPv6 assumes an AS is completely contained in one site >but there is no multiple process capability (my argument is the CLNS >addressing is per node, not per interface. A well-known consequence is >IS-IS can not run as an external gateway protocol). But this applies >to the original IS-IS lightly modified to carry IPv4 addresses (as decribed >in the reference). > > (5) RIP-IPv6: > > The RIP-IPv6 document explicitly states that there is a single IPv6 > routing table. > >=> so RIP-IPv6 has explicitly no provision for the multi-sited case. > > (6) Will the MIBs for any of these routing tables be capable of > representing multiple independent, possibly overlapping sets of > site-local routing information? > >=> in the case of BGP 4 (the only one I know because MIBs are the reason >the RFC 2553 is not yet a Draft Standard :-) all references in >draft-ietf-idr-bgp4-mibv2-02.txt point to RFC 3291 which defines ipv6z >addresses: "A non-global IPv6 address including a zone index as >defined by the InetAddressIPv6z textual convention"! > > (7) Do you think that there would be some utility to defining the > actual routing architecture (as opposed to just the addressing > architecture) for IPv6? > >=> no because we shan't easily get a consensus (there are two strong >opposite opinions about the use of sites). > > (8) Should we mention link-local addresses anywhere in these specifications? > >=> not in specifications when they are enough clear but in applicability >documents. > > We certainly would not want to propagate routing information for > link-local addresses. > >=> perhaps this is the opportunity to solve a very old issue raised by >Jean-Luc Richier many years ago: a topology discovery tool using SNMP >to dump routing tables can not go beyond directly connected routers >because it gets useless link-local addresses of next routers... > >Thanks > >Francis.Dupont@enst-bretagne.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 Jun 5 11:00:13 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g55I0Dk7025569; Wed, 5 Jun 2002 11:00:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g55I0CO8025568; Wed, 5 Jun 2002 11:00:12 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g55I07k7025561 for ; Wed, 5 Jun 2002 11:00:07 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA16884 for ; Wed, 5 Jun 2002 11:00:09 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA28004 for ; Wed, 5 Jun 2002 12:00:08 -0600 (MDT) Received: from kenawang ([147.11.233.11]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id KAA29974 for ; Wed, 5 Jun 2002 10:58:52 -0700 (PDT) Message-Id: <4.2.2.20020605135616.02471140@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 05 Jun 2002 14:00:04 -0400 To: ipng@sunroof.eng.sun.com From: Margaret Wasserman Subject: Fwd: Re: IPv6 Scoped Addresses and Routing Protocols Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >From: Francis Dupont >To: Margaret Wasserman >cc: routing-discussion@ietf.org >Subject: Re: IPv6 Scoped Addresses and Routing Protocols >Date: Sat, 25 May 2002 18:48:50 +0200 >Sender: Francis.Dupont@enst-bretagne.fr >X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr > > In your previous mail you wrote: > > Sites boundaries run through routers, so a single router (called a > site border router (SBR)) can have interfaces in more than one site. > >=> a SBR is a nightmare... It needs a scoped routing table in the kernel >and separate IGPs for each site. I don't want to imagine how we can >support site reconfiguration on a running SBR. > > SBRs will need to enforce site boundaries > >=> this part is easy: a very small number of lines of code in the forwarding >routine. > > not mixing site-local routing information > >=> this is called a scoped routing table (zoned should be a better term >but unfortunately it is too late to fix RFC 2553 or even 2553bis...) > > and not forwarding packets outside of a given site. > >=> this is "enforcing site boundaries", isn't this? > > To do this, it is expected that SBRs will need to maintain multiple > "conceptual routing tables", including one site-local routing table > for each attached site, and one global routing table. > >=> in fact usually a zone ID is added to addresses for the same result. > > None of our IPv6 routing protocol documents deal with site-local > boundaries or SBR behaviour explicitly. > >=> one can expect a site is a routing domain and an internal gateway protocol >should be run in the site. As routing protocols carry raw addresses (i.e., >in a case of a scoped address, the address without its zone indication) >this is the only reasonable way. > > Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing: > http://www.ietf.org/rfc/rfc2545.txt > >=> two remarks: > - usually BGP is used as an inter-domain routing protocol so is supposed > to manage routes for global prefixes. > - the issue is partially addressed in the section 2 (partially == not > fully solved). >In fact, the multi-protocol feature of BGP 4+ provides some ways to carry >extra information in a NLRI. For instance, we can reuse a VPN-like >(cf RFC 2547) way to manage site-local addresses with site identifiers. > > RIPng for IPv6 > http://www.ietf.org/rfc/rfc2080.txt > >=> its poor scalability makes RIPng a bad candidate for multi-sited stuff. > > So here are my actual questions: > > (2) BGP-IPv6: > > Would it ever be reasonable for BGP to propagate site-local routing > information? > >=> I've already answered this should be possible in the hard (== multi-sited) >case. Personally I believe site-local addresses should be reserved to the >not-connected organizations: the "non-link-local" argument applies. >(PS: here not-connected is at the network layer) > > Why, under what circumstances? > >=> very large not-connected organizations? > > Would it be reasonable to assume that an Inter-Domain Routing protocol > shouldn't propagate site-local information at all? > >=> I'd like to say site-local information should not cross site boundaries. > > If BGP should be capable of propagating site-local information, > will it be possible, using existing BGP standards for a BGP SBR router > with four interfaces (A, B, C & D), in two sites (A & B in S1, and C & > D in S2) to maintain two separate sets of information for prefix > FEC0::/10, one that applies to S1 (interfaces A & B) and one that > applies to S2 (interfaces C & D), and to propagate that information > accordingly? > >=> I am not an expert of RFC 2547 but site-local addressing fulfills >the 1.3 requirement about overlapping address spaces so a similar >tagging of site-local addresses (RFC 2547 adds a "Route Distinguisher" >which identifies a VPN, we can use the same concept for identifications >of sites) should work. > > Is this really just an issue of configuring the router properly, as > BGP-IPv6 implies? > >=> not for the multi-sited case because a router is not supposed to run >more than one BGP-IPv6 process. But in other cases I agree with the >suggession of BGP-IPv6 (i.e., I still believe BGP-IPv6 doesn't need >to be updated). > > (3) OSPF-IPV6: > >=> OSPF-IPv6 has the new (over OSPFv2) property that one is allowed to >run more than one OSPF-IPv6 process per router. So with a dangerous but >possible configuration the multi-sited case can be handled. > > Unlike the previous specification (BGP-IPv6), this assumption is > not stated up-front. Instead, everywhere in the draft where either > site-local or global addresses are mentioned they are both mentioned > (i.e. "site-local or global IPv6 addresses"). > >=> results are 5 and 80 pages (totally unfair comparison :-)! > > Or to assume that an OSPF AS will always be completely contained > within one site -- which is what the current draft seems to assume? > >=> I agree but this is not a limitation because one may run multiple >OSPF-IPv6 processes per router, i.e. put a router in multiple ASs. > > (4) IS-IS-IPv6: > > Any thoughts? > >=> I believe IS-IS-IPv6 assumes an AS is completely contained in one site >but there is no multiple process capability (my argument is the CLNS >addressing is per node, not per interface. A well-known consequence is >IS-IS can not run as an external gateway protocol). But this applies >to the original IS-IS lightly modified to carry IPv4 addresses (as decribed >in the reference). > > (5) RIP-IPv6: > > The RIP-IPv6 document explicitly states that there is a single IPv6 > routing table. > >=> so RIP-IPv6 has explicitly no provision for the multi-sited case. > > (6) Will the MIBs for any of these routing tables be capable of > representing multiple independent, possibly overlapping sets of > site-local routing information? > >=> in the case of BGP 4 (the only one I know because MIBs are the reason >the RFC 2553 is not yet a Draft Standard :-) all references in >draft-ietf-idr-bgp4-mibv2-02.txt point to RFC 3291 which defines ipv6z >addresses: "A non-global IPv6 address including a zone index as >defined by the InetAddressIPv6z textual convention"! > > (7) Do you think that there would be some utility to defining the > actual routing architecture (as opposed to just the addressing > architecture) for IPv6? > >=> no because we shan't easily get a consensus (there are two strong >opposite opinions about the use of sites). > > (8) Should we mention link-local addresses anywhere in these specifications? > >=> not in specifications when they are enough clear but in applicability >documents. > > We certainly would not want to propagate routing information for > link-local addresses. > >=> perhaps this is the opportunity to solve a very old issue raised by >Jean-Luc Richier many years ago: a topology discovery tool using SNMP >to dump routing tables can not go beyond directly connected routers >because it gets useless link-local addresses of next routers... > >Thanks > >Francis.Dupont@enst-bretagne.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 Jun 5 15:22:22 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g55MMMk7026266; Wed, 5 Jun 2002 15:22:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g55MMMGv026265; Wed, 5 Jun 2002 15:22:22 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g55MMIk7026258 for ; Wed, 5 Jun 2002 15:22:18 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA05788 for ; Wed, 5 Jun 2002 15:22:20 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA23515 for ; Wed, 5 Jun 2002 16:22:19 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 990364B24; Thu, 6 Jun 2002 07:22:10 +0900 (JST) To: Margaret Wasserman Cc: ipng@sunroof.eng.sun.com In-reply-to: mrw's message of Wed, 05 Jun 2002 13:50:36 -0400. <4.2.2.20020605134805.0245def0@mail.windriver.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols From: itojun@iijlab.net Date: Thu, 06 Jun 2002 07:22:10 +0900 Message-ID: <21624.1023315730@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Unfortunately, I can't find any indication that these concepts have been reflected >in the current IPv6 routing protocols. None of our IPv6 routing protocol documents >deal with site-local boundaries or SBR behaviour explicitly. > >There are currently four standards for how IPv6 routes will be handled in BGP, OSPF, >IS-IS and RIP. I will refer to these documents as BGP-IPv6, OSPF-IPv6 and IS-IS-IPv6, >and RIP-IPv6 respectively: in my opinion, site border routers need to have ability to run separate entity of RIP/OSPFv3/IS-IS for each site (don't mix them up). there's no need for protocol modification, since there will be no interaction between routes in site A and site B. NEC IX router is the only implementation supporting this, as far as i know (i'm a bit embarrassed, KAME doesn't handle this - yet). 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 Jun 5 19:54:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g562s8k7026955; Wed, 5 Jun 2002 19:54:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g562s8VX026954; Wed, 5 Jun 2002 19:54:08 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g562s4k7026947 for ; Wed, 5 Jun 2002 19:54:05 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA25078 for ; Wed, 5 Jun 2002 19:54:07 -0700 (PDT) Received: from oahu.i.wcom.com.hk (oahu.wcom.com.hk [202.130.139.16]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA13110 for ; Wed, 5 Jun 2002 20:54:06 -0600 (MDT) Received: from mailhost4.wcom.com.hk (202.130.139.15) by oahu.i.wcom.com.hk (6.0.021) id 3C9A8635000828C6; Thu, 6 Jun 2002 02:53:04 +0000 Received: from cnhon1gw0.wcom.com.hk (awork013064.netvigator.com [166.45.172.46]) by mailhost4.wcom.com.hk with SMTP (MailShield v2.0 - SOLARIS/SPARC Oct 16 2000 14:25:15); Thu, 06 Jun 2002 02:56:45 -0000 Received: by cnhon1gw0.i.wcom.com.hk with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Jun 2002 10:53:54 +0800 Message-ID: From: "Smith, Mark - Sydney" To: "'itojun@iijlab.net'" , Margaret Wasserman Cc: ipng@sunroof.eng.sun.com Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols Date: Thu, 6 Jun 2002 10:52:01 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-SMTP-HELO: cnhon1gw0.wcom.com.hk X-SMTP-MAIL-FROM: smith.r.mark@wcom.com.au X-SMTP-PEER-INFO: awork013064.netvigator.com [166.45.172.46] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I've only briefly read through the scoped architecture draft, running an IGP per zone might be more correct, although I can only think of one instance where there would be multiple zones and multiple IGPs running, and that is for site-level zones, so the SBR / ZBR(?) terminology is really the same thing. Mark. > -----Original Message----- > From: itojun@iijlab.net [mailto:itojun@iijlab.net] > Sent: Thursday, 6 June 2002 8:22 > To: Margaret Wasserman > Cc: ipng@sunroof.eng.sun.com > Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols > > > >Unfortunately, I can't find any indication that these > concepts have been reflected > >in the current IPv6 routing protocols. None of our IPv6 > routing protocol documents > >deal with site-local boundaries or SBR behaviour explicitly. > > > >There are currently four standards for how IPv6 routes will > be handled in BGP, OSPF, > >IS-IS and RIP. I will refer to these documents as BGP-IPv6, > OSPF-IPv6 and IS-IS-IPv6, > >and RIP-IPv6 respectively: > > in my opinion, site border routers need to have ability to run > separate entity of RIP/OSPFv3/IS-IS for each site > (don't mix them up). > there's no need for protocol modification, since there > will be no > interaction between routes in site A and site B. > > NEC IX router is the only implementation supporting > this, as far as > i know (i'm a bit embarrassed, KAME doesn't handle this - yet). > > 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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 5 20:49:02 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g563n1k7026999; Wed, 5 Jun 2002 20:49:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g563n1fc026998; Wed, 5 Jun 2002 20:49:01 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g563mvk7026991 for ; Wed, 5 Jun 2002 20:48:57 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA03318 for ; Wed, 5 Jun 2002 20:49:01 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA29967 for ; Wed, 5 Jun 2002 21:49:00 -0600 (MDT) Received: from kenawang ([192.168.1.51]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id UAA02681; Wed, 5 Jun 2002 20:47:40 -0700 (PDT) Message-Id: <4.2.2.20020605234141.03bd7d40@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 05 Jun 2002 23:48:55 -0400 To: itojun@iijlab.net From: Margaret Wasserman Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols Cc: ipng@sunroof.eng.sun.com In-Reply-To: <21624.1023315730@itojun.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Itojun, > in my opinion, site border routers need to have ability to run > separate entity of RIP/OSPFv3/IS-IS for each site (don't mix them up). > there's no need for protocol modification, since there will be no > interaction between routes in site A and site B. I am not quite sure what you mean... Assume that I have a router with 4 interfaces (A, B, C and D) in two sites (S1 & S2), with interfaces A & B in S1, and interfaces C & D in site 2, all on an OSPF network. How many instances of OSPF would I need to run? Your message seems to indicate that I would need to run two -- one for S1 and one for S2. But, how would those two instance cooperate to calculate the global routing information for all four interfaces? Alternatively, I could run three copies -- one for S1, one for S2 and one for the global routes. But, how would that work? I'd end up with two copies of OSPF running over each interface. Would they have the same, or different peers? > NEC IX router is the only implementation supporting this, as far as > i know (i'm a bit embarrassed, KAME doesn't handle this - yet). Does the NEC implementation use multi-instance routing protocols? Do you know anyone on this team? Could we get them to describe how they handle the site border router case in detail? I am very interested in understanding how this works. Thanks, Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 5 20:49:34 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g563nYk7027009; Wed, 5 Jun 2002 20:49:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g563nYcF027008; Wed, 5 Jun 2002 20:49:34 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g563nUk7027001 for ; Wed, 5 Jun 2002 20:49:30 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA03393 for ; Wed, 5 Jun 2002 20:49:33 -0700 (PDT) From: john.loughney@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA07436 for ; Wed, 5 Jun 2002 21:49:31 -0600 (MDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g563nu605206 for ; Thu, 6 Jun 2002 06:49:56 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 6 Jun 2002 06:49:30 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 6 Jun 2002 06:49:30 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Comments on draft-ietf-ipngwg-ipv6-anycast-analysis Date: Thu, 6 Jun 2002 06:49:29 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC6533D@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-ietf-ipngwg-ipv6-anycast-analysis Thread-Index: AcIMsQU/SWU5F3TNRammHNsOZ860AgAW7ecQ To: , , Cc: X-OriginalArrivalTime: 06 Jun 2002 03:49:30.0138 (UTC) FILETIME=[2979CFA0:01C20D0D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g563nUk7027002 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all, Prior to London, I had suggested to Itujun that I could supply text for this work on the use of anycast with SCTP. SCTP potentially has some very useful features that could mesh well with anycast, and get over some of the difficulties of using anycast. Unfortunately, I ran out of time and was not able to produce the text. If there is interest, I could see about writing something up. thanks, John PS - I agree that this is a useful document and we should get it to move forward. > -----Original Message----- > From: ext Erik Nordmark [mailto:Erik.Nordmark@Sun.COM] > Sent: 05 June, 2002 19:46 > To: itojun@iijlab.net; ettikan.kandasamy.karuppiah@intel.com > Cc: ipng@sunroof.eng.sun.com > Subject: Comments on draft-ietf-ipngwg-ipv6-anycast-analysis > > > The anycast-analysis has been sitting in front of Thomas and > I for quite a long > time while we were trying to figure out if the IETF needs to > do something more > significant in the anycast space (such as an anycast WG; such > as a way to > resolve or at least document the differences between the IPv4 > DNS anycast > usage and the IPv6 architecture). But it is time to finish > this document since > it provides useful information. > > So here are our comments on > draft-ietf-ipgnwg-ipv6-anycast-analysis-00.txt > > In general this is a quite useful document since it attempts to write > things down that haven't been written down before. But it > makes sense to > make the document more clear and succinct, and perhaps also to > add some missing pieces to give a more complete picture. > > Note that there are duplicate comments from Erik and Thomas > here - hopefully > they are consistent and not contradictory :-) > > Comments from Erik > ------------------ > > I completely fail to see what section 1.1 is trying to say > other than "there are different forms of anycast". > > It assigns the tag "BGP" anycast to both the Hardie and > Ohta-san document, > even though only the latter is an interdomain anycast scheme. > And contrasting this against RFC 1546 seems odd, since RFC > 1546 doesn't > say anything whether it limits itself to intradomain anycast or not. > > Section 1.1 doesn't mention (but section 2.1 does) that RFC > 1546 and RFC 2373 > are different with respect to being able to syntactically distinguish > between unicast and anycast, which seems to be an important technical > difference. > What high-level thing is section 1.1 trying to say? > > > RFC2373 IPv6 anycast is very similar to RFC1546 IPv4 anycast. The > > Given RFC 1546's suggestion to use a separate range of addresses > for anycast, this doesn't seem to be true. > > > BGP anycast tries to replicate unicast servers in distant > domains. The > > distribution of servers is worldwide. BGP anycast is being used for > > specific upper-layer protocols only, like DNS and HTTP. There is no > > consideration given for the cases when a client contacts multiple > > servers by chance (transport layer protocol will get > confused), since it > > is unlikely to see BGP route changes during the short > lifetime of the > > transport layer protocols being used. > > While typically http connections might be short, there is nothing in > the http protocol that mandates or assumes that they are short. > > ---- > Section 2.2 says: > After we > have discovered the unicast address of the server, we should use the > server's unicast address for the protocol exchange. > It would be useful to state something about this security implications > (or high-level requirements) when doing something like that in the > security considerations section. > > Section 2.3 should at a minimum have a "not yet" added - the magma WG > is chartered to extend MLD to allow hosts to join anycast groups. > But perhaps it can be written more in the form of > When RFC 2373 was written there was no standard way for > hosts to join anycast groups (short of having the hosts > fully participate in the routing protocol which has trust > issues). Therefore, ... > > If this section talks about the intent to extend MLD to > support anycast, it > would also be useful to add a sentence or two about the > security issues > in this area in the security considerations section. > > Section 2.4 is correct, but doesn't help people understand what > the technical issues are in having a single source address identify > more than one node. Since these implications are not written > down anywhere as far as I know, it would make sense to add > the currently known implications in this document. > > The ones I'm aware of are: > - Incorrect reassembly of fragmented packets due to multiple anycast > members sending packets with the same fragment ID to the > same destination > at about the same time; the same the source IP address, > destination IP > address, nextheader, and fragment ID numbers might be > accidentally used > at the same time by different senders. > > - Errors and other response packets might be delivered to > a different anycast member than sent the packet. This might be > very likely since asymmetric routing is rather prevalent > on the Internet. > > Particular cases of such errors that are known to cause protocol > problems are > - ICMP packet too big making path MTU discovery impossible. > - > The misdelivery of other errors might cause operational > problems - making > the network harder to trouble-shoot when anycast source > addresses are used. > > Section 2.5. > Aren't there also replay protection issues when manual keying is used > for anycast addresses? (Such issues exist for multicast and manual > keying, so I'd be surprised if they didn't exist for anycast.) > > Section 3.1 last paragraph seems to say that anycast can never be > used interdomain due to route scaling issues. This is clearly the > case if there are lots of interdomain anycast addresses being used. > But having lots of global anycast addresses where the anycast members > are in the same topological region, would presumably automatically > be aggregated as part of the prefix for advertised by that topological > region. (Whether one would call this interdomain or intradomain > is an interesting terminology issue; the point is that the anycast > service provided by multiple nodes in a single domain is accessible > from outside the domain.) > > Section 3.4 and 3.5 don't seem to be finished - they just contain > a "TBD". > Is there something which you intended to put in there? > If not, presumably the sections can be dropped. (The document > doesn't *have to* suggest improvement everywhere.) > > Section 4.1 says: > > Note that, however, bad guys can still inject fabricated > results to the > > client, even if the client checks the source address of the > reply. The > > check does not improve security of the exchange at all. > I think that DNS folks would disagree with that. > Having the resolver check the source address of replies > prevents, when ingress filtering is in use, off-path attackers > from spoofing responses. Thus it adds some non-zero amount of > protection to do this. > Same IMHO incorrect statement is repeated in this section: > > The source address check itself has no real protection > > It might make sense, for DNS query/replies over UDP, to instead look > into relaxing the anycast source address restriction under > appropriate constraints (e.g. must not send larger than MIN MTU > since path MTU discovery is unlikely to work). > > Another possibility, which you may or may not want to add to > the document, > is to specify a protocol which can establish a binding between the > anycast address and the unicast address of one of its members > with as much security as the routing system provides for routing > packets to the anycast address in the first place. IMHO such > a protocol > can be built by reusing pieces of MIPv6. > > I think (but I haven't verified) that (many) tftp > implementations verify > the source address. Perhaps I'm confused and it is only the > server that does > this and not the client. But using TFTP as an example of how > secure protocols > should be done is not a very strong argument to say the least. > > NITS: > > > destination node, out of a group of destination nodes. IP > datagram will > s/IP/The IP/ > > > If multiple packets carry an anycast address in IPv6 destionation > Spell check needed - "destionation"? > > > check source address, based on RFC2181 section 4.1. TFTP > The "TFTP" looks like extra characters at the end of the line. > > References: > The Hardie document is now RFC 3258. > > > Comments from Thomas: > -------------------- > > > destination node. The destination node is identified by an unicast > > s/an unicast/a unicast/ > > >destination node, out of a group of destination nodes. IP > datagram will > > s/datagram/datagrams/ ? (or "An IP datagram") > > > based on routing measure of distance. The source node does > not need to > s/on/on the/ > > > Today, there are so-called "anycast" operated mostly for critical > > servers including DNS servers and web servers (like those > for Olympic > > games) [Hardie, 2001; Ohta, 2000] . We call the technique > "BGP anycast" > > Sentence doesn't parse. s/"anycast"/"anycast" services/ > > Also, name "BGP anycast" is not really very > accurate. draft-ietf-dnsop-hardie-shared-root-server-03.txt doesn't > rely on BGP only. The technique works also within a single AS where no > BGP is used. > > > o A provider-independent IPv4 address prefix is allocated > from an RIR. > > Not required that the address be PI. > > > o The address prefix is configured at multiple distant > locations on the > > Internet. > > o BGP routes are advertised from all of the locations. > > Not sure what this means, especially the first bullet. > > > BGP anycast tries to replicate unicast servers in distant > domains. The > > Not sure I agree. The replication is within a single AS. That may or > may not involve services is "distant domains". Maybe you want to say > something like: > > BGP anycast tries to replicate unicast servers in different > topological locations. > > > > distribution of servers is worldwide. BGP anycast is being used for > > specific upper-layer protocols only, like DNS and HTTP. There is no > > Where is it being used for HTTP? The documents you cite talk about DNS > and UDP exclusively. > > > specific upper-layer protocols only, like DNS and HTTP. There is no > > consideration given for the cases when a client contacts multiple > > servers by chance (transport layer protocol will get > confused), since it > > is unlikely to see BGP route changes during the short > lifetime of the > > transport layer protocols being used. > > It is misleading to say this is all a BGP issue. The Hardie document > says that within an AS routes are advertised statically (even if a > particular server becomes unavailable) precisely so that routes stay > pinned and don't change. Note that this is within an AS, so its not > just BGP. > > > RFC2373 anycast is defined in more generic manner, and does > not limit > > the routing infrastructure nor upper-layer protocol, > Therefore, RFC2373 > > The first part of the sentence suggests that 2373 does NOT limit > upper-layer protocols. This would imply that the "BGP" approach > does. Actually, some might argue the opposite. 2373 says a source > address cannot be an anycast address. This implies that higher-layer > protocols that make use of anycast addresses need to be changed to > understand anycast addressing. This is in contrast with the BGP > approach. > > > depending on stability of the routing table. The property > leads to a > > couple of interesting symptoms. > > s/symptoms/observations/ ? > > > protocol exchange. If we use more than 2 packets, 1st and > 2nd packet > > s/exchange/exchanges/ > > Text should make clear that it assumes when server responds, source > address is unicast, not anycast. And point out that this causes > problems for some existing protocols. > > --- > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Jun 5 23:12:43 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g566Cgk7027228; Wed, 5 Jun 2002 23:12:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g566CgOC027227; Wed, 5 Jun 2002 23:12:42 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g566Cck7027220 for ; Wed, 5 Jun 2002 23:12:38 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA09749 for ; Wed, 5 Jun 2002 23:12:41 -0700 (PDT) Received: from starfruit.itojun.org (dialup0.itojun.org [210.160.95.108]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA21730 for ; Thu, 6 Jun 2002 00:12:37 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 6564B7B9; Thu, 6 Jun 2002 15:12:32 +0900 (JST) To: Margaret Wasserman Cc: ipng@sunroof.eng.sun.com In-reply-to: mrw's message of Wed, 05 Jun 2002 23:48:55 -0400. <4.2.2.20020605234141.03bd7d40@mail.windriver.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols From: Jun-ichiro itojun Hagino Date: Thu, 06 Jun 2002 15:12:32 +0900 Message-Id: <20020606061232.6564B7B9@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >I am not quite sure what you mean... > >Assume that I have a router with 4 interfaces (A, B, C and D) in two sites (S1 & S2), with >interfaces A & B in S1, and interfaces C & D in site 2, all on an OSPF network. How many >instances of OSPF would I need to run? > >Your message seems to indicate that I would need to run two -- one for S1 and one for S2. >But, how would those two instance cooperate to calculate the global routing information for >all four interfaces? > >Alternatively, I could run three copies -- one for S1, one for S2 and one for the global routes. >But, how would that work? I'd end up with two copies of OSPF running over each interface. >Would they have the same, or different peers? sorry, let me back up. i guess you need to either: - run 3 instances of OSPF daemons, one for S1, one for S2, and one for global. - run 1 instance of OSPF daemon, which is aware of site border. (still, there's no need for protocol modification) >> NEC IX router is the only implementation supporting this, as far as >> i know (i'm a bit embarrassed, KAME doesn't handle this - yet). >Does the NEC implementation use multi-instance routing protocols? Do you know anyone >on this team? Could we get them to describe how they handle the site border router case >in detail? they should be on the list so they should be able to comment. 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 Jun 5 23:15:40 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g566Fek7027253; Wed, 5 Jun 2002 23:15:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g566FdtL027252; Wed, 5 Jun 2002 23:15: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.12.4/8.12.4) with ESMTP id g566FZk7027241 for ; Wed, 5 Jun 2002 23:15:35 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA18649 for ; Wed, 5 Jun 2002 23:15:38 -0700 (PDT) Received: from starfruit.itojun.org (dialup0.itojun.org [210.160.95.108]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA26153 for ; Thu, 6 Jun 2002 00:15:35 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 04CBE7B9; Thu, 6 Jun 2002 15:15:31 +0900 (JST) To: john.loughney@nokia.com Cc: Erik.Nordmark@Sun.COM, ettikan.kandasamy.karuppiah@intel.com, ipng@sunroof.eng.sun.com In-reply-to: john.loughney's message of Thu, 06 Jun 2002 06:49:29 +0300. <0C1353ABB1DEB74DB067ADFF749C4EEFC6533D@esebe004.NOE.Nokia.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Comments on draft-ietf-ipngwg-ipv6-anycast-analysis From: Jun-ichiro itojun Hagino Date: Thu, 06 Jun 2002 15:15:31 +0900 Message-Id: <20020606061532.04CBE7B9@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Prior to London, I had suggested to Itujun that I could supply text >for this work on the use of anycast with SCTP. SCTP potentially has >some very useful features that could mesh well with anycast, and >get over some of the difficulties of using anycast. > >Unfortunately, I ran out of time and was not able to produce >the text. If there is interest, I could see about writing >something up. yes, i'm interested in having SCTP section. i'll need to update the i-d anyways... 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 Thu Jun 6 04:51:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g56Bpuk7027478; Thu, 6 Jun 2002 04:51:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g56Bpu61027477; Thu, 6 Jun 2002 04:51:56 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g56Bpqk7027470 for ; Thu, 6 Jun 2002 04:51:52 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA16408 for ; Thu, 6 Jun 2002 04:51:54 -0700 (PDT) Received: from TYO202.gate.nec.co.jp (TYO202.gate.nec.co.jp [210.143.35.56]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA14359 for ; Thu, 6 Jun 2002 04:51:53 -0700 (PDT) Received: from mailgate4.nec.co.jp ([10.7.69.195]) by TYO202.gate.nec.co.jp (8.11.6/3.7W01080315) with ESMTP id g56Bpqd20611; Thu, 6 Jun 2002 20:51:52 +0900 (JST) Received: from mailsv4.nec.co.jp (mailgate51.nec.co.jp [10.7.69.196]) by mailgate4.nec.co.jp (8.11.6/3.7W-MAILGATE-NEC) with ESMTP id g56BpqL19328; Thu, 6 Jun 2002 20:51:52 +0900 (JST) Received: from shoin.jp.nec.com (shoin.jp.nec.com [10.26.220.3]) by mailsv4.nec.co.jp (8.11.6/3.7W-MAILSV4-NEC) with ESMTP id g56Bpp809055; Thu, 6 Jun 2002 20:51:51 +0900 (JST) Received: from [10.42.72.128] by mail.jp.nec.com; Thu, 6 Jun 2002 20:51:51 +0900 Date: Thu, 06 Jun 2002 20:51:50 +0900 From: Hiroki Ishibashi Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols To: Margaret Wasserman Cc: ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: TuruKame 1.96 (WinNT,500) Organization: NEC Corporation In-Reply-To: <4.2.2.20020605234141.03bd7d40@mail.windriver.com> References: <4.2.2.20020605234141.03bd7d40@mail.windriver.com> Message-Id: <5CC20D508B73E8bashi@ipv6.nec.co.jp> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Margaret, > >> NEC IX router is the only implementation supporting this, as far as >> i know (i'm a bit embarrassed, KAME doesn't handle this - yet). > >Does the NEC implementation use multi-instance routing protocols? Do you >know anyone >on this team? Could we get them to describe how they handle the site >border router case >in detail? > Yes, I will describe how we handle sites on our IX5000 router shortly. >I am very interested in understanding how this works. > >Thanks, >Margaret > > Hiroki Ishibashi bashi@ipv6.nec.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 6 10:36:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g56HaXk7028007; Thu, 6 Jun 2002 10:36:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g56HaXKL028006; Thu, 6 Jun 2002 10:36:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g56HaSk7027999 for ; Thu, 6 Jun 2002 10:36:29 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA11992 for ; Thu, 6 Jun 2002 10:36:30 -0700 (PDT) Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA28344 for ; Thu, 6 Jun 2002 10:36:29 -0700 (PDT) Received: from postal.research.att.com (postal.research.att.com [135.207.23.30]) by mail-green.research.att.com (Postfix) with ESMTP id 496F81E043 for ; Thu, 6 Jun 2002 13:36:29 -0400 (EDT) Received: from berkshire.research.att.com (postal.research.att.com [135.207.23.30]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id NAA16324 for ; Thu, 6 Jun 2002 13:31:16 -0400 (EDT) Received: from research.att.com (localhost [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id 3E1DE7B4B for ; Thu, 6 Jun 2002 13:36:28 -0400 (EDT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: "Steven M. Bellovin" To: ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 06 Jun 2002 13:36:28 -0400 Message-Id: <20020606173628.3E1DE7B4B@berkshire.research.att.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <4.2.2.20020605134805.0245def0@mail.windriver.com>, Margaret Wasserm an writes: > >I sent the attached message to the routing area discussion list. I thought th >at people on >the IPv6 list might be interested in this discussion, so I will forward a mess >age containing >the responses after this one. I suppose I just should have cc:ed the IPv6 gro >up in the >first place... > My strong preference would be to drop site-local addresses completely. I think they're an administrative and technical nightmare. Margaret has pointed out that our routing protocols don't support site-local addresses. The only alternative suggestion I've seen thus far is to run multiple instances of, say, OSPF on all routers within a site. But how are these distinguished from each other? OSPF runs with an IP protocol number, not a port number, so we can't have multiple instances that way. And RFC 2740's specification of the necessary multicast addresses notes that they're all link-local. Still, there's apparently running code; I look forward to seeing the details. I'm very concerned about DNS entries. When should a DNS server -- or a caching resolver -- return a site-local address? (If the DNS never returns such things, they're useless.) One suggestion I've heard is two-faced DNS servers -- only return site-local information if the querier is within the same site. Apart from the fact that I have no idea how that determination can be made -- surely no one will suggest putting site-local addresses into NS records -- RFC 2182 (aka BCP 0016) specifically warns against putting all secondary servers for a zone within a site: Consequently, placing all servers at the local site, while easy to arrange, and easy to manage, is not a good policy. Should a single link fail, or there be a site, or perhaps even building, or room, power failure, such a configuration can lead to all servers being disconnected from the Internet. Secondary servers must be placed at both topologically and geographically dispersed locations on the Internet, to minimise the likelihood of a single failure disabling all of them. Etc. There will also be a lot of unnecessary pain in DNS maintenance as "sites" are split or merged. v6 is designed to support easy renumbering of global addresses, but those are designed to reflect topology. Site-local addresses do not, which increases the probability of address space collision during a merger. Philosophically, I think that the problem is that a "site" is a new (and deliberately poorly defined) concept. The DNS is designed to work with administrative boundaries, while routing and addressing reflect topology. We now have a new concept that is neither administrative nor topological, but one that must be supported by administrative and topological mechanisms. Finally -- and perhaps least important -- I'm not sure what problem they solve. I can understand site-local multicast, since (most) inter-site traffic traverses links that are not inherently multicast-capable. There is thus considerable extra expense. But why do I need site-local unicast addresses? --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com ("Firewalls" book) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 6 11:11:03 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g56IB3k7028184; Thu, 6 Jun 2002 11:11:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g56IB3kQ028183; Thu, 6 Jun 2002 11:11:03 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g56IB2k7028176 for ; Thu, 6 Jun 2002 11:11:02 -0700 (PDT) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g56IADYd003108 for ; Thu, 6 Jun 2002 11:10:13 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g56IADiu003107 for ipng@sunroof.eng.sun.com; Thu, 6 Jun 2002 11:10:13 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g54CWarP021240 for ; Tue, 4 Jun 2002 05:32:36 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA25980 for ; Tue, 4 Jun 2002 05:32:37 -0700 (PDT) Received: from cisco.com (edinburgh.cisco.com [144.254.112.76]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA15926 for ; Tue, 4 Jun 2002 06:32:36 -0600 (MDT) Received: (from dfawcus@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id NAA05987 for ipng@sunroof.eng.sun.com; Tue, 4 Jun 2002 13:32:35 +0100 (BST) Date: Tue, 4 Jun 2002 13:32:35 +0100 From: Derek Fawcus To: IPng List Subject: Re: Mandating Route Optimization Message-ID: <20020604133235.B2922@edinburgh.cisco.com> Mail-Followup-To: IPng List References: <4.3.2.7.2.20020530153959.02e04570@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from jinmei@isl.rdc.toshiba.co.jp on Mon, Jun 03, 2002 at 02:37:28PM +0900 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, Jun 03, 2002 at 02:37:28PM +0900, JINMEI Tatuya / ?$B?@L@C#:H?(B wrote: > > In summary: > > - if we're going to make something mandatory for all IPv6 nodes, it > must be discussed in the ipv6 wg. > - (IMO) we cannot go with the MUST, considering the current situation > and some possible scenarios in the future. We should delay the > decision, or should go with a SHOULD or a MAY. > - it does not make sense just to say "the route optimization is > mandatory." we should be more specific. My take is that this should be a SHOULD. I actually think that it depends upon the type of device, and how it is expected to be used. So I'd say in general, RO is not generally needed when a router (non mobile router) is the CN, for some really minimal implementation (i.e. IP stack in a fridge, light switch etc) there's no need whatsoever, but for other general nodes - my computers, mobile phone etc, then RO should be implemented. Given that and a differentiation on device basis, I say: for routers => SHOULD for minimal nodes => MAY for other nodes => MUST As to what's being done; as others have pointed out there is already shipping code which doesn't implement RO (as defined in draft-17) thus we already effectivly have a MAY situation. After glancing through draft-17 recently I decided that (for a router) one didn't need to bother with implementing RO initially (if ever). That was based upon the assumption that traffic directed to/from the router itself would generally (or almost always) be from within the organisation owning the router, and as such dog leg forwarding would be uncommon. Obviously ICMPs generated by the router are a possible exception. Hence the view that we could leave implementing RO for CN functionality within a router until some later stage, i.e. ship product without it (as happens now) and then implement the functionality within some later release of software. Now if this was a router that was also acting as a HA, the analysis would be somewhat different. DF -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 6 11:17:57 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g56IHvk7028235; Thu, 6 Jun 2002 11:17:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g56IHvGM028234; Thu, 6 Jun 2002 11:17:57 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g56IHsk7028227 for ; Thu, 6 Jun 2002 11:17:54 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA28434 for ; Thu, 6 Jun 2002 11:17:55 -0700 (PDT) Received: from caduceus.fm.intel.com (fmr02.intel.com [192.55.52.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA21913 for ; Thu, 6 Jun 2002 11:17:55 -0700 (PDT) Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by caduceus.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.48 2002/05/24 00:39:04 root Exp $) with ESMTP id g56IGH724738 for ; Thu, 6 Jun 2002 18:16:17 GMT Received: from fmsmsxvs040.fm.intel.com (fmsmsxv040-1.fm.intel.com [132.233.48.108]) by petasus.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.22 2002/05/24 00:38:22 root Exp $) with SMTP id g56IFiG23142 for ; Thu, 6 Jun 2002 18:15:44 GMT Received: from fmsmsx26.fm.intel.com ([132.233.42.26]) by fmsmsxvs040.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002060611171010255 for ; Thu, 06 Jun 2002 11:17:10 -0700 Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Jun 2002 11:17:49 -0700 Message-ID: <8A9A5F4E6576D511B98F00508B68C20A0D56E4A3@orsmsx106.jf.intel.com> From: "Das, Kaustubh" To: ipng@sunroof.eng.sun.com Cc: "Das, Kaustubh" Subject: Comments on Date: Thu, 6 Jun 2002 11:17:47 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Francis/All, In titled "RFC 3041 considered harmful" Francis argues that rfc 3041 gives no privacy benefit whilst increasing complexity and making DDoS attacks easier. IMO section 2 which states that privacy extensions "... give only complexity with no benefit" is logically flawed. I quote the relevant sentences from section 2 below ______________________________ "Note the interface identifier is only the half of the whole address, and to change the interface identifier when the prefix remains the same shall not improve the privacy... There are only two cases where privacy extensions can be justified: where the link has a very high number of nodes or ......" ______________________________ I argue that the number of nodes on the link has little to do with existence of privacy for the following reasons:- Defn: Privacy is achieved if when a node X corresponds with a server S, the server S cannot 'unambiguously' associate the IP addr for Node X with the physical machine. If you agree with the defn..... Consider a link with 2 nodes (low number of nodes) X and Y each changing its suffix as prescribed in 3041. When one of these nodes, Node X contacts a server with addr A1, can the server later unambiguously associate that IP with this node? The answer is No; since the other node, node Y could have had the address A1. The key to the argument is that it is not enough to have a high probability of association of an address with a physical machine to say that privacy is broken. The proof of the pudding is to check whether correspondences of the Node whose privacy is in question can be tracked. For instance in our 2 node example, multiple servers could not correlate based on addr A1 to track traffic patterns for the machine associated with node X. Best Regards, Kaustubh -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 6 11:46:26 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g56IkQk7028314; Thu, 6 Jun 2002 11:46:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g56IkQ68028313; Thu, 6 Jun 2002 11:46:26 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g56IkNk7028306 for ; Thu, 6 Jun 2002 11:46:23 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA14912 for ; Thu, 6 Jun 2002 11:46:24 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA20099 for ; Thu, 6 Jun 2002 12:46:24 -0600 (MDT) Received: from mira-sjc5-2.cisco.com (IDENT:mirapoint@mira-sjc5-2.cisco.com [171.71.163.16]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g56IkNHs017743; Thu, 6 Jun 2002 11:46:23 -0700 (PDT) Received: from stewart.chicago.il.us (dhcp-171-69-54-231.cisco.com [171.69.54.231]) by mira-sjc5-2.cisco.com (Mirapoint) with ESMTP id ACP11165; Thu, 6 Jun 2002 11:46:18 -0700 (PDT) Message-ID: <3CFFADF6.8B58A3DE@stewart.chicago.il.us> Date: Thu, 06 Jun 2002 13:46:14 -0500 From: Randall Stewart X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: "Steven M. Bellovin" CC: ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols References: <20020606173628.3E1DE7B4B@berkshire.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve: Having implemented SCTP and IPv6 together I could not agree with you more. I know in our work on scoping of addresses it got very very tricky on attempting to figure out which set of addresses to tell the other SCTP endpoint about to avoid black hole conditions. So in the end the only way you could handle it is if the destination address of your INIT packet (consider it a SYN) was TO a site-local then you could include your site-locals... This means that if the user sent the INIT to the global address then the peer NEVER gets informed of site locals.... maybe something not desired but unavoidable... Now with the new addition of site-scoping even this will break since one must all of a sudden be cognizant of what site the peer is on and only send a sub-set of the site-local addresses (gak!!). In all of this I have tried to figure out what use these site locals are? If I have a global address why would I ever want to use a site-local? If no global-addresses are available and I am not attached to the public inter-net I could possibly see using a site-local.. maybe but I would think this is more the 'dentists' office scenario where in link-local will suffice... If the 'dentist' wants to talk to the insurance company I doubt that it would be in the 'dentist's' site... so he would need a connection to the global address space... and the problem goes away.... Only in a large company would I see a site-local being applied.. but in such a company why not just use a global address? What does it buy me to have this extra address? I already know my assigned address space... I can have my company border routers prevent spoofing of my address into my network... so I can use the source being the global address that is assigned to me to "know" that I am in the same company...if thats what I want... I may be able to see (maybe) that a large company wants to NOT connect to the global address space... so here site-local MIGHT be something I could use... but adding in scoped site-locals I just can't see a use for... It just causes all sorts of fun problems. I would much rather see the company that is NOT going to want to connect to the global address space just have a way to get some global address space.... I realize with the current number scheme this is not possible so maybe a site-local does make sense in this one strange instance... but in this case the company does not need to worry about global mixed with site-local :> So maybe site-local (if allowed) should only be valid if NO global address is defined :> R "Steven M. Bellovin" wrote: > > In message <4.2.2.20020605134805.0245def0@mail.windriver.com>, Margaret Wasserm > an writes: > > > >I sent the attached message to the routing area discussion list. I thought th > >at people on > >the IPv6 list might be interested in this discussion, so I will forward a mess > >age containing > >the responses after this one. I suppose I just should have cc:ed the IPv6 gro > >up in the > >first place... > > > > My strong preference would be to drop site-local addresses completely. > I think they're an administrative and technical nightmare. > > Margaret has pointed out that our routing protocols don't support > site-local addresses. The only alternative suggestion I've seen thus > far is to run multiple instances of, say, OSPF on all routers within a > site. But how are these distinguished from each other? OSPF runs with > an IP protocol number, not a port number, so we can't have multiple > instances that way. And RFC 2740's specification of the necessary > multicast addresses notes that they're all link-local. Still, there's > apparently running code; I look forward to seeing the details. > > I'm very concerned about DNS entries. When should a DNS server -- or a > caching resolver -- return a site-local address? (If the DNS never > returns such things, they're useless.) One suggestion I've heard is > two-faced DNS servers -- only return site-local information if the > querier is within the same site. Apart from the fact that I have no > idea how that determination can be made -- surely no one will suggest > putting site-local addresses into NS records -- RFC 2182 (aka BCP 0016) > specifically warns against putting all secondary servers for a zone > within a site: > > Consequently, placing all servers at the local site, while easy to > arrange, and easy to manage, is not a good policy. Should a single > link fail, or there be a site, or perhaps even building, or room, > power failure, such a configuration can lead to all servers being > disconnected from the Internet. > > Secondary servers must be placed at both topologically and > geographically dispersed locations on the Internet, to minimise the > likelihood of a single failure disabling all of them. > > Etc. > > There will also be a lot of unnecessary pain in DNS maintenance as > "sites" are split or merged. v6 is designed to support easy renumbering > of global addresses, but those are designed to reflect topology. > Site-local addresses do not, which increases the probability of > address space collision during a merger. > > Philosophically, I think that the problem is that a "site" is a new > (and deliberately poorly defined) concept. The DNS is designed to work > with administrative boundaries, while routing and addressing reflect > topology. We now have a new concept that is neither administrative nor > topological, but one that must be supported by administrative and > topological mechanisms. > > Finally -- and perhaps least important -- I'm not sure what problem > they solve. I can understand site-local multicast, since (most) > inter-site traffic traverses links that are not inherently > multicast-capable. There is thus considerable extra expense. But why > do I need site-local unicast addresses? > > --Steve Bellovin, http://www.research.att.com/~smb (me) > http://www.wilyhacker.com ("Firewalls" book) > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 6 12:51:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g56Jpjk7028405; Thu, 6 Jun 2002 12:51:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g56Jpj3V028404; Thu, 6 Jun 2002 12:51:45 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g56Jpbk7028397 for ; Thu, 6 Jun 2002 12:51:37 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA09258 for ; Thu, 6 Jun 2002 12:51:39 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA10454 for ; Thu, 6 Jun 2002 12:51:30 -0700 (PDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g56JpPM22036; Thu, 6 Jun 2002 15:51:26 -0400 (EDT) Message-Id: <200206061951.g56JpPM22036@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Steven M. Bellovin" cc: ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-reply-to: (Your message of "Thu, 06 Jun 2002 13:36:28 EDT.") <20020606173628.3E1DE7B4B@berkshire.research.att.com> Date: Thu, 06 Jun 2002 15:51:25 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > My strong preference would be to drop site-local addresses completely. > I think they're an administrative and technical nightmare. for that matter, so are link-local addresses. they do have some legitimate uses, but they need to be kept to a minimum (in both ipv6 and ipv4) Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 6 14:22:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g56LMnk7028498; Thu, 6 Jun 2002 14:22:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g56LMn79028497; Thu, 6 Jun 2002 14:22:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g56LMjk7028490 for ; Thu, 6 Jun 2002 14:22:46 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA16135 for ; Thu, 6 Jun 2002 14:22:47 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA26592 for ; Thu, 6 Jun 2002 14:22:46 -0700 (PDT) Received: by p2.piuha.net (Postfix, from userid 962) id 806DF6A909; Fri, 7 Jun 2002 00:22:45 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id A7B1E6A907 for ; Fri, 7 Jun 2002 00:22:43 +0300 (EEST) Message-ID: <3CFFD2EC.101@kolumbus.fi> Date: Fri, 07 Jun 2002 00:23:56 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: finalizing cellular hosts document Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=7.0 tests= version=2.20 X-Spam-Level: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, We are trying to finish the cellular hosts document by Friday. In the following I list the issues that have been brought up, and briefly mention what has been done. A preliminary version of the next version can also be found in the following URLs: http://www.piuha.net/~jarkko/publications/ipv6/draft-ietf-ipv6-cellular-host-03-pa8.doc (with changes) http://www.piuha.net/~jarkko/publications/ipv6/draft-ietf-ipv6-cellular-host-03-pa8.txt Hopefully the issues have satisfactory solutions from your point of view. If not, let us know as soon as possible -- thanks! In particular, take a look at the bottom of the issue list where there are three issues that we are not sure if everyone has had a chance to comment yet. Here are the issues that we think are resolved: - Document type to be described clearly (Margaret). Agreed. New text in 1.1. - Transition mechanism discussions (Margaret and others). Agreed. Removed, and left for ngtrans to work on. - Unclear whether ND needs to be supported or not (many). Agreed. Clarified that it needs to be, and added text to describe how typical upper layers can give advice to NUD. See section 2.4. - Address resolution, needs to be supported or not (many). Agreed. Clarified that no link layer addresses are used, hence no support needed (but of course ND and its messages must be supported). See section 2.4.1. - AH fate note (Margaret). Agreed. Removed, see Section 3.3. - Address selection normative, draft schedule (Thomas). Agreed, apparently the draft can have the same schedule? - ADDRARCHv3 is normative, not ready yet (Thomas). Agreed. Made non- normative, see section 2.2. and 6.2. - Router alert implementation situations (IESG). Clarified the text in 2.10. - Editorial modifications (many). Agreed, and taken in account, hopefully. - DNS recursive query mandate (many). Agreed, new text in 2.10. - MIPv6 CN functionality (Margaret). After discussion, agreed to keep it the way it is described in the draft. See Section 4. - Interface ID being trackable (someone). It isn't, and this is now stated in Appendix B. - Unique within-its-scope text in Appendix B (Pekka Savola). It seems that Pekka's comment didn't really indicate he wanted something changed. - Fragment headers, why are they needed (Pekka Savola). Agreed, a reference to a Section 5 of RFC 2460 has been added to 2.3. - Author list (IESG). We are shortening the author list. Not visible in the URL version yet. - Router has only a link-local address-comment (IESG). Agreed. Section 2.5.1 contains clarifying new text. - Non-ascii chars in the document (Thomas). Fixed. - AES (IESG). Agreed and added some text in 3.6. But: can't add a reference, draft expired. Here are the issues that we think are resolved as well, but on which there might still be some discussion: - Key management mandate (IESG). We noted on the list that IPv6 doesn't make a stronger statement either. Not sure what we can do here. - MLD (many). This has been discussed on the list. After some comments from the list and from the ADs/IESG, the new text in 2.9. says that MLD must be supported, but that there should be a configuration switch that allows it to be turned off for link-local addresses, and a justification why this does not cause problems. - RFC 3041 stronger statement (IESG). We noted on the list that privacy is not as bad as in regular e.g. DSL usage. Empirical data does not exist to quantify exactly how much, however. In any case, the draft now requires (section 2.11) that hosts should support RFC 3041, though the use is a may. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 6 16:47:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g56Nlkk7028684; Thu, 6 Jun 2002 16:47:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g56NlkP7028683; Thu, 6 Jun 2002 16:47:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g56Nljk7028676 for ; Thu, 6 Jun 2002 16:47:45 -0700 (PDT) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g56NlloR001660 for ; Thu, 6 Jun 2002 16:47:47 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g56Nlk20001659 for ipng@sunroof.eng.sun.com; Thu, 6 Jun 2002 16:47:46 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g56IOxk7028271 for ; Thu, 6 Jun 2002 11:25:00 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA04859 for ; Thu, 6 Jun 2002 11:25:01 -0700 (PDT) Received: from roam.psg.com (firewall.isoc.org [198.6.250.5]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA25782 for ; Thu, 6 Jun 2002 11:25:00 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.04) id 17G1wP-000487-00; Thu, 06 Jun 2002 11:24:57 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: "Steven M. Bellovin" Cc: ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols References: <20020606173628.3E1DE7B4B@berkshire.research.att.com> Message-Id: Date: Thu, 06 Jun 2002 11:24:57 -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > My strong preference would be to drop site-local addresses completely. > I think they're an administrative and technical nightmare. trying to solve a routing problem by an ill-understood addressing hack. randy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 6 16:48:14 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g56NmDk7028697; Thu, 6 Jun 2002 16:48:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g56NmDYl028696; Thu, 6 Jun 2002 16:48:13 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g56NmBk7028689 for ; Thu, 6 Jun 2002 16:48:11 -0700 (PDT) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g56NmDoR001668 for ; Thu, 6 Jun 2002 16:48:13 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g56NmDu0001667 for ipng@sunroof.eng.sun.com; Thu, 6 Jun 2002 16:48:13 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g56KTkk7028443 for ; Thu, 6 Jun 2002 13:29:46 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA17731 for ; Thu, 6 Jun 2002 13:29:48 -0700 (PDT) Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA29214 for ; Thu, 6 Jun 2002 13:29:47 -0700 (PDT) Received: from root by main.gmane.org with local (Exim 3.33 #1 (Debian)) id 17G3tS-00042M-00 for ; Thu, 06 Jun 2002 22:30:02 +0200 To: ipng@sunroof.eng.sun.com X-Injected-Via-Gmane: http://gmane.org/ Received: from news by main.gmane.org with local (Exim 3.33 #1 (Debian)) id 17G3ra-0003xb-00 for ; Thu, 06 Jun 2002 22:28:06 +0200 Path: not-for-mail From: aditya@grot.org (R.P. Aditya) Newsgroups: gmane.ietf.ipv6 Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols Date: 06 Jun 2002 13:27:47 -0700 Organization: Grot Free Lines: 16 Message-ID: References: <20020606173628.3E1DE7B4B@berkshire.research.att.com> <200206061951.g56JpPM22036@astro.cs.utk.edu> NNTP-Posting-Host: mighty.grot.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1023395286 14608 204.182.56.120 (6 Jun 2002 20:28:06 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 6 Jun 2002 20:28:06 +0000 (UTC) User-Agent: Gnus/5.090003 (Oort Gnus v0.03) XEmacs/21.1 (Cuyahoga Valley) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> "Keith" == Keith Moore writes: >> My strong preference would be to drop site-local addresses >> completely. I think they're an administrative and technical >> nightmare. Keith> for that matter, so are link-local addresses. they do have Keith> some legitimate uses, but they need to be kept to a minimum Keith> (in both ipv6 and ipv4) The problem with site-local addresses is that the "site" scope is ill-defined. For link-local addresses, as long as the scope is well-defined, what are your objections? thanks, Adi -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 6 20:00:21 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5730Lk7029184; Thu, 6 Jun 2002 20:00:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5730KVf029183; Thu, 6 Jun 2002 20:00:20 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5730Hk7029176 for ; Thu, 6 Jun 2002 20:00:17 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA05067 for ; Thu, 6 Jun 2002 20:00:20 -0700 (PDT) Received: from TYO201.gate.nec.co.jp (TYO201.gate.nec.co.jp [202.32.8.214]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA15317 for ; Thu, 6 Jun 2002 21:00:17 -0600 (MDT) Received: from mailgate4.nec.co.jp ([10.7.69.195]) by TYO201.gate.nec.co.jp (8.11.6/3.7W01080315) with ESMTP id g5730CC29958; Fri, 7 Jun 2002 12:00:12 +0900 (JST) Received: from mailsv4.nec.co.jp (mailgate51.nec.co.jp [10.7.69.196]) by mailgate4.nec.co.jp (8.11.6/3.7W-MAILGATE-NEC) with ESMTP id g5730BL19103; Fri, 7 Jun 2002 12:00:11 +0900 (JST) Received: from shoin.jp.nec.com (shoin.jp.nec.com [10.26.220.3]) by mailsv4.nec.co.jp (8.11.6/3.7W-MAILSV4-NEC) with ESMTP id g572wS814675; Fri, 7 Jun 2002 11:59:37 +0900 (JST) Received: from [10.42.72.128] by mail.jp.nec.com; Fri, 7 Jun 2002 11:58:28 +0900 Date: Fri, 07 Jun 2002 11:58:26 +0900 From: Hiroki Ishibashi Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols To: Margaret Wasserman Cc: ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit X-Mailer: TuruKame 1.96 (WinNT,500) Organization: NEC Corporation In-Reply-To: <4.2.2.20020605234141.03bd7d40@mail.windriver.com> References: <4.2.2.20020605234141.03bd7d40@mail.windriver.com> Message-Id: <63C20DCF3205EFbashi@ipv6.nec.co.jp> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Margaret, Here is the description of NEC IX router. >> NEC IX router is the only implementation supporting this, as far as >> i know (i'm a bit embarrassed, KAME doesn't handle this - yet). > >Does the NEC implementation use multi-instance routing protocols? Do you >know anyone >on this team? Could we get them to describe how they handle the site >border router case >in detail? > >I am very interested in understanding how this works. Let me describe how sites are defined in IX router using diagram below, first. This router has 8 logical interfaces. By default, all logical interfaces belong to a site called "default_site". Therefore, with this default site configuration, the router will not work as SBR. All site-local address will be routed to any other logical interfaces based on a routing table. With this configuration, RIPng, OSPFv3 will propagate routing entries for site-local prefixes. Currently, our implementation of BGP4+ does not handle site-local prefixes. Also, we don't have IS-IS on IX routers, yet. | | +--------+--------+ | if1 | | | -------|if4 if2|------- | | | if3 | +---+----+--------+ | | Default Site Configuration (NOT SBR) ------------------------------------ To create sites (to configure a router as SBR), * 1st, define site-name. eg. my_site. * add logical interfaces to "my_site". eg. add if1 and if2 to "my_site. At this point, the router has 2 sites and acts as ABR. "default_site" has if3 and if4. "my_site" has if1 and if2. So any packets destined to site-local addresses will never forwarded across sites. Site Boundary | / (my_site) | / +--------+--------+ | if4 / | | / | -------|if3 / if1|------- | / | | / if2 | +-/-+----+--------+ (default_site) / | / | SBR Configuration w/ 2 Sites ---------------------------- Now, to run RIPng on this router, simply enable RIPng on each interfaces. Single RIPng process is running on this router. Global prefixes will be propagated to all interfaces; however, site-local prefix will be propagated only to interfaces belongs to the same site. eg. fec0:0:0:100::/64 from if1 will be propagated to if2, but not to neither if3 nor if4. Now, OSPFv3. Since it is much complicated than any RIPng, of course, and it has capability to run multiple processes by nature, we decided to run an OSPFv3 process per site. Still, we could have handle site routing with single OSPFv3 process. Complication is the most dominant factor in our decision. For example, what if someone is sending an Intra-Area-Prefix-LSA which contains both global and site-local prefixes. Receiving OSPFv3 router might need to decompose LSA into two LSAs which contain global and site-local separately. BUT, this is not allowed. I believe that we need to make agreements on this point. One of our concerns on multi-process implementation is that global prefixes need to be redistributed among OSPFv3 process once sites are defined. Also, IX router's PIM-SM for IPv6 is capable of sites. Would this be of help? ---- Hiroki Ishibashi bashi@ipv6.nec.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 7 01:34:44 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g578Yik7029608; Fri, 7 Jun 2002 01:34:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g578Yh4l029607; Fri, 7 Jun 2002 01:34:43 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g578Yek7029600 for ; Fri, 7 Jun 2002 01:34:40 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA22809 for ; Fri, 7 Jun 2002 01:34:42 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA05433 for ; Fri, 7 Jun 2002 02:34:41 -0600 (MDT) Message-ID: <025001c20dfd$ee938f10$446015ac@T23KEMPF> From: "James Kempf" To: Subject: Securing Neighbor Discovery BOF Date: Fri, 7 Jun 2002 01:32:56 -0700 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 On Tues. afternoon of IETF 54 13:00-14:00, there will be a BOF held to discuss securing Neighbor Discovery. The BOF description, along with a suggested reading list, will appear when the agenda is posted on the IETF 54 Web page. If you are interested in this problem, please attend. If you would like to speak, please send email to me or Pekka Nikkander (Pekka.Nikander@nomadiclab.com). jak -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 7 01:52:16 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g578qFk7029716; Fri, 7 Jun 2002 01:52:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g578qFmp029715; Fri, 7 Jun 2002 01:52:15 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g578qCk7029708 for ; Fri, 7 Jun 2002 01:52:12 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA22142 for ; Fri, 7 Jun 2002 01:52:13 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA12443 for ; Fri, 7 Jun 2002 02:52:12 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g578pqB01600; Fri, 7 Jun 2002 11:51:52 +0300 Date: Fri, 7 Jun 2002 11:51:52 +0300 (EEST) From: Pekka Savola To: James Kempf cc: ipng@sunroof.eng.sun.com Subject: Re: Securing Neighbor Discovery BOF In-Reply-To: <025001c20dfd$ee938f10$446015ac@T23KEMPF> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 7 Jun 2002, James Kempf wrote: > On Tues. afternoon of IETF 54 13:00-14:00, there will be a BOF held to > discuss securing Neighbor Discovery. The BOF description, along with a > suggested reading list, will appear when the agenda is posted on the > IETF 54 Web page. If you are interested in this problem, please attend. > If you would like to speak, please send email to me or Pekka Nikkander > (Pekka.Nikander@nomadiclab.com). Are there any non-encumbered technologies to Secure ND? Thought so... -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 7 02:25:28 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g579PRk7029879; Fri, 7 Jun 2002 02:25:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g579PR4s029878; Fri, 7 Jun 2002 02:25:27 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g579POk7029871 for ; Fri, 7 Jun 2002 02:25:24 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA01132 for ; Fri, 7 Jun 2002 02:25:26 -0700 (PDT) From: john.loughney@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA02492 for ; Fri, 7 Jun 2002 03:26:46 -0600 (MDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g579Pn620736 for ; Fri, 7 Jun 2002 12:25:49 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 7 Jun 2002 12:25:23 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 7 Jun 2002 12:25:23 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: finalizing cellular hosts document Date: Fri, 7 Jun 2002 12:25:23 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38E44@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: finalizing cellular hosts document Thread-Index: AcINoMd4xQ4/iAh6QmaW5MjTo+ocLwAYvAWw To: , X-OriginalArrivalTime: 07 Jun 2002 09:25:23.0647 (UTC) FILETIME=[4050FCF0:01C20E05] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g579POk7029872 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Jari, Just a little more information on the open issues: > Here are the issues that we think are resolved as well, but on which > there might still be some discussion: > > - Key management mandate (IESG). We noted on the list that IPv6 > doesn't make a stronger statement either. Not sure what we can do > here. Cellular hosts will connect to the Internet, as well as to 3G nets. Our draft cannot solve key management for the Internet, so perhaps it is better not to prescribe too much. > - MLD (many). This has been discussed on the list. After some comments > from the list and from the ADs/IESG, the new text in 2.9. says that > MLD must be supported, but that there should be a configuration > switch that allows it to be turned off for link-local addresses, and > a justification why this does not cause problems. The idea is the MLD must be supported. MLD is needed for multicast services. MLD usage on link-local addresses, however, may not be useful. > - RFC 3041 stronger statement (IESG). We noted on the list that > privacy is not as bad as in regular e.g. DSL usage. Empirical data > does not exist to quantify exactly how much, however. In any case, > the draft now requires (section 2.11) that hosts should support > RFC 3041, though the use is a may. More correctly, cellular hosts can have two kinds of radio attachments to the 3GPP network - primary and secondary. Secondary most likely will be short lived. The primary may be longer lived, but depends upon radio coverage (radio coverage is usually lost when going through a tunnel), user behavior (if the user turns their phone off during a meeting, or at night), etc. These attachements to the network will deterimine the lifetime of these addresses. In summary, cellular hosts should support temporary addresses as outlined in 3041. However, I don't feel confident enough to detail how they are used. I think we need usage / deployment experience. John -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 7 03:53:11 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g57ArAk7029955; Fri, 7 Jun 2002 03:53:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g57ArAk0029954; Fri, 7 Jun 2002 03:53:10 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g57Ar7k7029947 for ; Fri, 7 Jun 2002 03:53:07 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA22749 for ; Fri, 7 Jun 2002 03:53:08 -0700 (PDT) From: john.loughney@nokia.com Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA06175 for ; Fri, 7 Jun 2002 04:53:07 -0600 (MDT) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g57Asha27711 for ; Fri, 7 Jun 2002 13:54:43 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 7 Jun 2002 13:53:05 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 7 Jun 2002 13:53:05 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Mandating Route Optimization Date: Fri, 7 Jun 2002 13:53:04 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC653A1@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Mandating Route Optimization Thread-Index: AcINheaiX9tw0vSgQRe18c5z1oXkoQAi0vOg To: , X-OriginalArrivalTime: 07 Jun 2002 10:53:05.0314 (UTC) FILETIME=[8083A820:01C20E11] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g57Ar7k7029948 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Derek, > for routers => SHOULD > for minimal nodes => MAY > for other nodes => MUST >From the entire 'Cellular Hosts' discussion, I have learned that the concept of 'minimal nodes' is in the eye of the beholder and quite temporal at that. I think we can clearly diffentiate between routers and hosts, beyond that I am not sure it is a good idea to differentiate further. John -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 7 05:10:54 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g57CAsk7000055; Fri, 7 Jun 2002 05:10:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g57CAsqc000054; Fri, 7 Jun 2002 05:10:54 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g57CApk7000045 for ; Fri, 7 Jun 2002 05:10:51 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA08090 for ; Fri, 7 Jun 2002 05:10:52 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA27764 for ; Fri, 7 Jun 2002 06:12:13 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id 0B3106A909; Fri, 7 Jun 2002 15:10:51 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id A798D6A907; Fri, 7 Jun 2002 15:10:48 +0300 (EEST) Message-ID: <3D00A311.6070000@kolumbus.fi> Date: Fri, 07 Jun 2002 15:12:01 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Pekka Savola Cc: James Kempf , ipng@sunroof.eng.sun.com Subject: Re: Securing Neighbor Discovery BOF References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka Savola wrote: > Are there any non-encumbered technologies to Secure ND? IP Security, for one. The current IPsec can be used, though it's pretty cumbersome due to (a) large number of similar SAs needed for manual keying due to destination address being a part of SA lookup and (b) chicken-and-egg problem for IKE. The problem (a) could be solved, and the result would be a more easily usable IPsec for securing large private networks. For public networks manual keying does not scale, however. Perhaps something can be done for (b). For instance, one possible, even if ugly, solution is to provide an ND-level message to carry IKE-like traffic between the ND peers until an IPsec SA can be established. Contributions on this space are sought -- feel free to jump in here ;-) Then there are ABK and CGA-based techniques. Anyway, I'm not sure we at this point have all the solutions. If we agree the issue is a problem, the group will figure out the possible solutions and their pros and cons. (IPRs are likely to be taken in account.) Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 7 08:35:51 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g57FZpk7000373; Fri, 7 Jun 2002 08:35:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g57FZpIL000372; Fri, 7 Jun 2002 08:35:51 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g57FZkk7000365 for ; Fri, 7 Jun 2002 08:35:47 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA18582 for ; Fri, 7 Jun 2002 08:35:48 -0700 (PDT) Received: from mail-green.research.att.com (mail-green.research.att.com [135.207.30.103]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA26592 for ; Fri, 7 Jun 2002 09:35:47 -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 B03DD1E0A8; Fri, 7 Jun 2002 11:35:47 -0400 (EDT) Received: from berkshire.research.att.com (postal.research.att.com [135.207.23.30]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id LAA06054; Fri, 7 Jun 2002 11:30:33 -0400 (EDT) Received: from research.att.com (localhost [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id 37F897B4B; Fri, 7 Jun 2002 11:35:44 -0400 (EDT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: "Steven M. Bellovin" To: Hiroki Ishibashi Cc: Margaret Wasserman , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 07 Jun 2002 11:35:44 -0400 Message-Id: <20020607153544.37F897B4B@berkshire.research.att.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <63C20DCF3205EFbashi@ipv6.nec.co.jp>, Hiroki Ishibashi writes: >Now, OSPFv3. Since it is much complicated than any RIPng, of course, >and it has capability to run multiple processes by nature, we decided to >run an OSPFv3 process per site. Still, we could have handle site routing >with single OSPFv3 process. Complication is the most dominant factor in our >decision. For example, what if someone is sending an Intra-Area-Prefix-LSA >which contains both global and site-local prefixes. Receiving OSPFv3 router >might need to decompose LSA into two LSAs which contain global and site-local >separately. BUT, this is not allowed. I believe that we need to make >agreements on this point. >One of our concerns on multi-process implementation is that >global prefixes need to be redistributed among OSPFv3 process once >sites are defined. > I'm still confused. If a packet arrives on a site-enabled interface, addressed to multicast address AllSPFRouters, and with protocol number 89 (OSPF), to which process is it delivered? Does something actually peek inside the packet to see if it's advertising global or site-local addresses when making the dispatching decision? --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com ("Firewalls" book) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 7 09:23:11 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g57GNBk7000578; Fri, 7 Jun 2002 09:23:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g57GNBnJ000577; Fri, 7 Jun 2002 09:23:11 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g57GN7k7000570 for ; Fri, 7 Jun 2002 09:23:07 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA21690 for ; Fri, 7 Jun 2002 09:23:09 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA09091 for ; Fri, 7 Jun 2002 10:24:31 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g57GMxn20948; Fri, 7 Jun 2002 12:23:00 -0400 (EDT) Message-Id: <200206071623.g57GMxn20948@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: aditya@grot.org (R.P. Aditya) cc: ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-reply-to: (Your message of "06 Jun 2002 13:27:47 PDT.") Date: Fri, 07 Jun 2002 12:22:59 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > For link-local addresses, as long as the scope is > well-defined, what are your objections? for the most part, they're only a problem if you try to use them in applications (where zero-configuration appliances are an important subset of applications) part of the problem is that the scope of link-local addresses is *not* well-defined from an application's point of view, since applications in general don't know, and shouldn't have to know, about network topology. (scoped addresses in general are a nightmare for apps) so LL is fine for RD/ND etc. but the vast majority of apps should never see them. unfortunately the zeroconf WG is trying to make LL addresses be a general-purpose mechanism for internet appliances to obtain an address - perhaps without supporting any mechanism to get a global address, assuming (incorrectly IMHO) that the hosts that need to access that appliance will be on the same link anyway. the problem is not the fact that LL addresses exist, it's that there are no well-defined constraints on their use. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 7 10:09:42 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g57H9gk7000670; Fri, 7 Jun 2002 10:09:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g57H9gS6000669; Fri, 7 Jun 2002 10:09:42 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g57H9bk7000656 for ; Fri, 7 Jun 2002 10:09:37 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA15460 for ; Fri, 7 Jun 2002 10:09:39 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA06001 for ; Fri, 7 Jun 2002 11:11:01 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id C3DBC4B24; Sat, 8 Jun 2002 02:09:33 +0900 (JST) To: Keith Moore Cc: aditya@grot.org (R.P. Aditya), ipng@sunroof.eng.sun.com In-reply-to: moore's message of Fri, 07 Jun 2002 12:22:59 -0400. <200206071623.g57GMxn20948@astro.cs.utk.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: Fwd: IPv6 Scoped Addresses and Routing Protocols From: itojun@iijlab.net Date: Sat, 08 Jun 2002 02:09:33 +0900 Message-ID: <9155.1023469773@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> For link-local addresses, as long as the scope is >> well-defined, what are your objections? >for the most part, they're only a problem if you try to use >them in applications (where zero-configuration appliances >are an important subset of applications) >part of the problem is that the scope of link-local addresses >is *not* well-defined from an application's point of view, >since applications in general don't know, and shouldn't have >to know, about network topology. as long as the applications are properly implemented with sockaddrs, they are okay. the problem reside in protocols that pass IPv6 addresses in payloads (since view of the scope is different by nodes), including: - FTP (EPSV/EPRT does not help - for instance, how do you decide the scope zone for data connection?) - DNS (AAAA/PTR does not represent scope correctly) - and all NAT-unfriendly protocols I'm okay to see site-local IPv6 address to go away, however, I'm worried because there are more than a couple of protocols designed with site-local IPv6 address in mind (DHCPv6, router renumbering, ...). we need to keep link-local IPv6 address at least for ND. use of link-locals within zeroconf environment needs further study. 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 Jun 7 10:15:54 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g57HFrk7000756; Fri, 7 Jun 2002 10:15:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g57HFrco000755; Fri, 7 Jun 2002 10:15:53 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g57HFok7000748 for ; Fri, 7 Jun 2002 10:15:50 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA14491 for ; Fri, 7 Jun 2002 10:15:40 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA14630 for ; Fri, 7 Jun 2002 11:15:40 -0600 (MDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g57HFMHt012651; Fri, 7 Jun 2002 10:15:22 -0700 (PDT) Date: Fri, 7 Jun 2002 13:15:22 -0400 (EDT) From: Ralph Droms To: itojun@iijlab.net cc: Keith Moore , "R.P. Aditya" , Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-Reply-To: <9155.1023469773@itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk DHCPv6 currently uses a site-scoped multicast address as the default for forwarding messages from a relay agent to servers. The relay agent can be configured with a list of unicast addresses for servers instead of using the site-scoped multicast address. DHCPv6 also depends on link-local addresses for communication between the client and the on-link relay agent. - Ralph On Sat, 8 Jun 2002 itojun@iijlab.net wrote: > >> For link-local addresses, as long as the scope is > >> well-defined, what are your objections? > >for the most part, they're only a problem if you try to use > >them in applications (where zero-configuration appliances > >are an important subset of applications) > >part of the problem is that the scope of link-local addresses > >is *not* well-defined from an application's point of view, > >since applications in general don't know, and shouldn't have > >to know, about network topology. > > as long as the applications are properly implemented with sockaddrs, > they are okay. the problem reside in protocols that pass IPv6 > addresses in payloads (since view of the scope is different by nodes), > including: > - FTP (EPSV/EPRT does not help - for instance, how do you decide > the scope zone for data connection?) > - DNS (AAAA/PTR does not represent scope correctly) > - and all NAT-unfriendly protocols > > I'm okay to see site-local IPv6 address to go away, however, I'm > worried because there are more than a couple of protocols designed with > site-local IPv6 address in mind (DHCPv6, router renumbering, ...). > > we need to keep link-local IPv6 address at least for ND. use of > link-locals within zeroconf environment needs further study. > > 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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 7 10:19:54 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g57HJsk7000803; Fri, 7 Jun 2002 10:19:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g57HJs9H000802; Fri, 7 Jun 2002 10:19:54 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g57HJok7000795 for ; Fri, 7 Jun 2002 10:19:50 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA16162 for ; Fri, 7 Jun 2002 10:19:50 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA21936 for ; Fri, 7 Jun 2002 11:19:49 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g57HHCn28727; Fri, 7 Jun 2002 13:17:12 -0400 (EDT) Message-Id: <200206071717.g57HHCn28727@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: itojun@iijlab.net cc: Keith Moore , aditya@grot.org (R.P. Aditya), ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-reply-to: (Your message of "Sat, 08 Jun 2002 02:09:33 +0900.") <9155.1023469773@itojun.org> Date: Fri, 07 Jun 2002 13:17:12 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >for the most part, they're only a problem if you try to use > >them in applications (where zero-configuration appliances > >are an important subset of applications) > >part of the problem is that the scope of link-local addresses > >is *not* well-defined from an application's point of view, > >since applications in general don't know, and shouldn't have > >to know, about network topology. > > as long as the applications are properly implemented with sockaddrs, > they are okay. sockaddrs do not solve the problem of applications having to figure out how to reach a peer application in the absence of any knowledge about network topology. the source-selection rule isn't sufficient either. > the problem reside in protocols that pass IPv6 > addresses in payloads (since view of the scope is different by nodes), > including: it's entirely appropriate for applications to pass addresses in payloads, and it's essential functionality for many kinds of applications (distributed apps in particluar). for better or worse, the internet does not have a location-independent namespace that is reliable and useful for doing referrals to peer processes. and nobody has demonstrated an effective way to retrofit one into the current architecture. > we need to keep link-local IPv6 address at least for ND. use of > link-locals within zeroconf environment needs further study. we agree about that much. but they think they're ready for standards-track. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 7 10:21:43 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g57HLgk7000874; Fri, 7 Jun 2002 10:21:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g57HLgIJ000873; Fri, 7 Jun 2002 10:21:42 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g57HLck7000866 for ; Fri, 7 Jun 2002 10:21:38 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA16941 for ; Fri, 7 Jun 2002 10:21:39 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA21723 for ; Fri, 7 Jun 2002 10:21:38 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 155B14B24; Sat, 8 Jun 2002 02:21:34 +0900 (JST) Cc: Keith Moore , aditya@grot.org (R.P. Aditya), ipng@sunroof.eng.sun.com In-reply-to: itojun's message of Sat, 08 Jun 2002 02:09:33 +0900. <9155.1023469773@itojun.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: Fwd: IPv6 Scoped Addresses and Routing Protocols From: itojun@iijlab.net Date: Sat, 08 Jun 2002 02:21:34 +0900 Message-ID: <9347.1023470494@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > they are okay. the problem reside in protocols that pass IPv6 > addresses in payloads (since view of the scope is different by nodes), > including: i'm not saying that these protocols are bad. s/problem reside in/site-local address does not play nicely with/ 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 Jun 7 15:57:27 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g57MvQk7001816; Fri, 7 Jun 2002 15:57:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g57MvQoj001815; Fri, 7 Jun 2002 15:57:26 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g57MvNk7001808 for ; Fri, 7 Jun 2002 15:57:23 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA19627 for ; Fri, 7 Jun 2002 15:57:25 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA06806 for ; Fri, 7 Jun 2002 16:57:24 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id PAA21756; Fri, 7 Jun 2002 15:57:24 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g57MvM804650; Fri, 7 Jun 2002 15:57:22 -0700 X-mProtect: <200206072257> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (4.22.78.78, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdNw3EMa; Fri, 07 Jun 2002 15:57:18 PDT Message-Id: <4.3.2.7.2.20020607110536.02f48db0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 07 Jun 2002 15:56:42 -0700 To: "Steven M. Bellovin" From: Bob Hinden Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols Cc: ipng@sunroof.eng.sun.com In-Reply-To: <20020606173628.3E1DE7B4B@berkshire.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve, Thanks for raising this issue on the list. I think it has been lurking for a while. (with no hat on) Here is my personal explanation about why site-local addresses exist. My intent of the email is to not take a strong position on either side. I think the important question is the one at the end of your email: >Finally -- and perhaps least important -- I'm not sure what problem >they solve. I can understand site-local multicast, since (most) >inter-site traffic traverses links that are not inherently >multicast-capable. There is thus considerable extra expense. But why >do I need site-local unicast addresses? It may be the most important question, not the least important :-) One of the original reasons for site-local unicast addresses was for sites that were not connected to the Internet (and didn't have any global addresses). They would allow IPv6 be used inside the site initially. Later when the site become connected to the Internet it would be easy to renumber to a global prefix because the subnet part of the addresses (/48 in current assignment practice) could be reused without any site subnet renumbering. This usage of site-local unicast may still have some value and avoids some of the complexity of using a mixture of global and site-local addresses. Later as many people came to belive that private addresses (and NAT) in IPv4 provide a security mechanism, Site-local addresses were looked on as filling that role in IPv6. I understand that the belief that private addresses provide security is faulty and has many nasty consequences, but many people do believe it. I think this has evolved to where there is a view that using site-local unicast addresses for services that need to be restricted to the site is a good thing. I think there is some value here, but am not sure if it's benefits justify it's costs. I think there are a range of opinions here. All of the issues you point out about site-local regarding DNS and routers are real. However with the widespread use of IPv4 private addresses in the internet, that vendors have leaned how to deal with addressing domain issues. I don't think the IETF has done very much to "standardize" this usage (probably a good thing). I think most vendors building these products know how to deal with the issues and users have learned how to configure the products to solve their problem. The vendors built it because their customers wanted it. It is all very ugly and nasty. It is hard to set up and even harder to debug problems. Perhaps even as you say "an administrative and technical nightmare". But as far as I can tell it does exist. If vendors are going to build products that want to use site-local, then it might be best for the IETF to at least document it's usage to allow for interoperability. (with my IPv6 co-chair hat on) I think the w.g. has some choices to make regarding site-local addresses. 1) Remove site-local from the IPv6. This would involve remove it from the IPv6 addressing documents and find all other documents that mention them and update these. Some of these may require significant modification if use site-local as a basic part of their mechanisms. There will also be an impact to shipping IPv6 implementations. This would have to be sorted out. A good understanding of what different vendors plan here would be useful. 2) Keep site-local but limit it's scope of usage. This would be something like writing an applicability document that defines it usage and for example restricts it use to sites not connected to the Internet. Other usage would be for future study. This would be consistent with most of the current specifications. It would make completing the scoped address architecture document simpler. There might be other specifications to update if they were using site-local and didn't have any provision to move to global addresses. 3) Keep site-local and allow full usage This would mean fully specifying how to use site-local, documenting the router and DNS issues, completing the scoped addressing architecture document, perhaps enhancing IPv6 routing protocols to have more knowledge of site-local addresses, etc. The working group has been going down 3) for some time now. I think your email is a good start at seeing if should continue in this direction or change course. Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 7 16:02:44 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g57N2hk7001841; Fri, 7 Jun 2002 16:02:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g57N2hoO001840; Fri, 7 Jun 2002 16:02:43 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g57N2ek7001833 for ; Fri, 7 Jun 2002 16:02:40 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA21218 for ; Fri, 7 Jun 2002 16:02: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 RAA17976 for ; Fri, 7 Jun 2002 17:02:42 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA22019; Fri, 7 Jun 2002 16:02:40 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g57N2d312952; Fri, 7 Jun 2002 16:02:39 -0700 X-mProtect: <200206072302> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (4.22.78.78, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpd0k01g5; Fri, 07 Jun 2002 16:02:36 PDT Message-Id: <4.3.2.7.2.20020607155724.0259f200@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 07 Jun 2002 16:01:59 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: Review of "Use of /127 Prefix Length Between Routers Considered Harmful" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk A request has been made by the author to the RFC editor to publish the following draft as an Informational RFC: Title : Use of /127 Prefix Length Between Routers Considered Harmful Author(s) : P. Savola Filename : draft-savola-ipv6-127-prefixlen-03.txt Pages : 5 Date : 20-May-02 Earlier versions of this draft have been discussed on the mailing list, but it is not a working group draft. The IESG has requested that the IPv6 working group review the draft. Possible outcomes of the review are: - OK to publish as is - Needs to have a few issues fixed before publication - Should become a working group draft and receive formal review by the w.g. - Incorporate into another IPv6 w.g. document with broader scope. - Harmful, should not be published. Please send comments to the list. Thanks, Bob Hinden, Steve Deering, Margaret Wasserman IPv6 w.g. Co-Chairs -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 7 16:27:15 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g57NREk7001897; Fri, 7 Jun 2002 16:27:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g57NRE3o001896; Fri, 7 Jun 2002 16:27:14 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g57NRBk7001889 for ; Fri, 7 Jun 2002 16:27:11 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA12733 for ; Fri, 7 Jun 2002 16:27:13 -0700 (PDT) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA26358 for ; Fri, 7 Jun 2002 17:27:12 -0600 (MDT) content-class: urn:content-classes:message Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols Date: Fri, 7 Jun 2002 16:27:06 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046405E0DE@server2000.arneill-py.sacramento.ca.us> X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 X-MS-TNEF-Correlator: Thread-Topic: Fwd: IPv6 Scoped Addresses and Routing Protocols Thread-Index: AcIOdyo5WtP5QcGaQF6Lg3tIxIa6ewAAK4yg From: "Michel Py" To: "Bob Hinden" , "Steven M. Bellovin" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g57NRBk7001890 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Bob Hinden wrote: > 3) Keep site-local and allow full usage Personally, I do not see a reason not to continue in this direction (3). There is something that bugs me, though. Last time I read it, the allocation was as follows: Link-local unicast 1111111010 FE80::/10 Site-local unicast 1111111011 FEC0::/10 I wonder if it would be wise to change it to: Link-local unicast FE80::/64 Site-local unicast FEC0::/48 Not so much to save space, but to prevent people from doing terrible hacks with these unused bits between 10 and 47. > Steve Bellovin wrote: >Finally -- and perhaps least important -- I'm not sure what problem >they solve. I can understand site-local multicast, since (most) >inter-site traffic traverses links that are not inherently >multicast-capable. There is thus considerable extra expense. But why >do I need site-local unicast addresses? I think there still are some situations where they can improve security. There is a main difference between an IPv4 RFC1918 address and an IPv6 site-local address: IPv6 NAT does not exist. And even if it does, it is not mainstream setup. The false sensation of security provided by RFC1918 is false because it is extremely likely (today) that an RFC1918 host can reach the outside Internet through NAT. The outbound-only firewall is a false idea of security as well since 2nd generation peer-to-peer software such as Morpheus can easily bypass firewalls and allow ingress connections to RFC1918 hosts. NAT does make RFC1918 hosts reachable from the Internet. On the other hand, considering that a typical IPv6 will _not_ feature IPv6 NAT, an IPv6 host that has _only_ a site-local address would have an extra layer of protection against external attacks as it would not be reachable at all from the outside. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 7 16:40:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g57Nemk7001945; Fri, 7 Jun 2002 16:40:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g57NelfP001944; Fri, 7 Jun 2002 16:40:47 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g57Neik7001935 for ; Fri, 7 Jun 2002 16:40:44 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA19381; Fri, 7 Jun 2002 19:40:46 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g57NekZs025905; Fri, 7 Jun 2002 19:40:46 -0400 (EDT) Message-Id: <200206072340.g57NekZs025905@thunk.east.sun.com> From: Bill Sommerfeld To: "Michel Py" cc: "Bob Hinden" , "Steven M. Bellovin" , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-Reply-To: Your message of "Fri, 07 Jun 2002 16:27:06 PDT." <2B81403386729140A3A899A8B39B046405E0DE@server2000.arneill-py.sacramento.ca.us> Reply-to: sommerfeld@east.sun.com Date: Fri, 07 Jun 2002 19:40:45 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The outbound-only firewall is a false idea of security as well since > 2nd generation peer-to-peer software such as Morpheus can easily > bypass firewalls and allow ingress connections to RFC1918 hosts. > > On the other hand, considering that a typical IPv6 will _not_ feature > IPv6 NAT, an IPv6 host that has _only_ a site-local address would have > an extra layer of protection against external attacks as it would not be > reachable at all from the outside. I see this as a distinction without a difference -- if the site has some systems running a global p2p network's software with external connectivity, and that p2p network is cracked, the site will be vulnerable to attacks relayed through the p2p network. if one system within the site has external connectivity and is part of the compromised p2p network, any system at the site will now be open to attacks from the compromised system. If there is widespread deployment of systems with site-local only addresses, this will in turn drive the creation of ipv6 NAT specifically to give them external connectivity.. - 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 Jun 7 19:32:34 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g582WXk7002226; Fri, 7 Jun 2002 19:32:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g582WXAj002225; Fri, 7 Jun 2002 19:32: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.12.4/8.12.4) with ESMTP id g582WTk7002218 for ; Fri, 7 Jun 2002 19:32:30 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA03543 for ; Fri, 7 Jun 2002 19:32:31 -0700 (PDT) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA01289 for ; Fri, 7 Jun 2002 20:33:55 -0600 (MDT) content-class: urn:content-classes:message Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols Date: Fri, 7 Jun 2002 19:32:28 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046405E0DF@server2000.arneill-py.sacramento.ca.us> X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 X-MS-TNEF-Correlator: Thread-Topic: Fwd: IPv6 Scoped Addresses and Routing Protocols Thread-Index: AcIOfNNyO4kB2pxQT3SUtDj3Ej1M7AAFzbMA From: "Michel Py" To: Cc: "Bob Hinden" , "Steven M. Bellovin" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g582WUk7002219 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> Michel Py wrote: >> On the other hand, considering that a typical IPv6 will _not_ feature >> IPv6 NAT, an IPv6 host that has _only_ a site-local address would have >> an extra layer of protection against external attacks as it would not be >> reachable at all from the outside. > Bill Sommerfeld wrote: > I see this as a distinction without a difference -- if the site has > some systems running a global p2p network's software with external > connectivity, and that p2p network is cracked, the site will be > vulnerable to attacks relayed through the p2p network. > if one system within the site has external connectivity and is part > of the compromised p2p network, any system at the site will now be > open to attacks from the compromised system. I don't know on which planet you are living, but on earth a system that has no direct access to the outside is more secure than a system that does; this is called a fact, not a distinction. Security is the sum of different things, including passwords, firewalls _and_ preventing direct access from the Internet. > If there is widespread deployment of systems with site-local only > addresses, this will in turn drive the creation of ipv6 NAT > specifically to give them external connectivity.. That looks like a solution without a problem. To give these hosts connectivity you just have both the site-local and the global address. Since NAT would not bring anything to the table why implement it in the first place? Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 8 03:19:57 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g58AJvk7002788; Sat, 8 Jun 2002 03:19:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g58AJuD6002787; Sat, 8 Jun 2002 03:19:56 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g58AJrk7002780 for ; Sat, 8 Jun 2002 03:19:53 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA28689 for ; Sat, 8 Jun 2002 03:19:56 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA06702; Sat, 8 Jun 2002 04:19:54 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g58AJog12851; Sat, 8 Jun 2002 13:19:50 +0300 Date: Sat, 8 Jun 2002 13:19:50 +0300 (EEST) From: Pekka Savola To: Michel Py cc: sommerfeld@east.sun.com, Bob Hinden , "Steven M. Bellovin" , Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols In-Reply-To: <2B81403386729140A3A899A8B39B046405E0DF@server2000.arneill-py.sacramento.ca.us> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 7 Jun 2002, Michel Py wrote: > > If there is widespread deployment of systems with site-local only > > addresses, this will in turn drive the creation of ipv6 NAT > > specifically to give them external connectivity.. > > That looks like a solution without a problem. To give these hosts > connectivity you just have both the site-local and the global address. > Since NAT would not bring anything to the table why implement it in the > first place? To give folks that think IPv4 private addresses provide security (especially wrt. incoming connections) a smooth transition path to IPv6 and "warm fuzzy feeling". -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jun 8 11:12:13 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g58ICCk7003206; Sat, 8 Jun 2002 11:12:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g58ICC41003205; Sat, 8 Jun 2002 11:12:12 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g58IC8k7003198 for ; Sat, 8 Jun 2002 11:12:09 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA15933; Sat, 8 Jun 2002 14:12:10 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g58ICAZs003422; Sat, 8 Jun 2002 14:12:10 -0400 (EDT) Message-Id: <200206081812.g58ICAZs003422@thunk.east.sun.com> From: Bill Sommerfeld To: "Michel Py" cc: sommerfeld@east.sun.com, "Bob Hinden" , "Steven M. Bellovin" , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-Reply-To: Your message of "Fri, 07 Jun 2002 19:32:28 PDT." <2B81403386729140A3A899A8B39B046405E0DF@server2000.arneill-py.sacramento.ca.us> Reply-to: sommerfeld@east.sun.com Date: Sat, 08 Jun 2002 14:12:10 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I think i was a little too subtle in my original post. Denying external connectivity on a host-by-host basis is harder than it looks, because if any system with external connectivity at any layer is compromised, it can be used as a springboard to attack "internal" systems which the firewall allegedly protects. Site-local addresses add complication and do nothing that a site couldn't do already by setting aside part of its address space to be blocked at a firewall. The belief that site boundaries will be configured correctly is equivalent to the belief that site boundary firewalls will be configured correctly. - 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 Jun 8 18:38:29 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g591cTk7003530; Sat, 8 Jun 2002 18:38:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g591cTMe003529; Sat, 8 Jun 2002 18:38:29 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g591cPk7003522 for ; Sat, 8 Jun 2002 18:38:26 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA27526 for ; Sat, 8 Jun 2002 18:38:29 -0700 (PDT) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA15075 for ; Sat, 8 Jun 2002 19:38:28 -0600 (MDT) content-class: urn:content-classes:message Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols MIME-Version: 1.0 Date: Sat, 8 Jun 2002 18:38:22 -0700 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046405E0E1@server2000.arneill-py.sacramento.ca.us> X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 X-MS-TNEF-Correlator: Thread-Topic: Fwd: IPv6 Scoped Addresses and Routing Protocols Thread-Index: AcIPGNzTfPk5W2tgQ+aUckmnZZXanAAOmkug From: "Michel Py" To: Cc: "Bob Hinden" , "Steven M. Bellovin" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g591cQk7003523 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Bill Sommerfeld wrote: > Denying external connectivity on a host-by-host basis is harder > than it looks, because if any system with external connectivity > at any layer is compromised, it can be used as a springboard to > attack "internal" systems which the firewall allegedly protects. This is a lot more complicated than being able to attack the system directly, and requires to develop software that acts as a proxy to the internal system. > Site-local addresses add complication and do nothing that a site > couldn't do already by setting aside part of its address space to > be blocked at a firewall. This is untrue. - With an RFC 1918 host behind a firewall, compromising the firewall is enough to grant that host outside access. Single point of failure. - With a site-local only host behind a firewall, this become a double hack thing: you need to reconfigure the firewall _and_ reconfigure the host to give it a public IP. Let's look at the following situation: The hacker can reconfigure the firewall and is using an OS vulnerability that allows him to read data from the hosts but not to reconfigure it. RFC 1918 host: The hacker can freely copy the data. Site-local only host: The hacker can _not_ copy the data (has to take extra steps). > The belief that site boundaries will be configured correctly > is equivalent to the belief that site boundary firewalls will > be configured correctly. What is the message here? Don't configure a firewall because it can eventually be configured incorrectly? Why don't you post password lists and network diagrams while you're at it? Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 8 22:32:10 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g595W9k7003779; Sat, 8 Jun 2002 22:32:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g595W9JE003778; Sat, 8 Jun 2002 22:32:09 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g595W6k7003771 for ; Sat, 8 Jun 2002 22:32:06 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA19371; Sun, 9 Jun 2002 01:32:09 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g595W9Zs008059; Sun, 9 Jun 2002 01:32:09 -0400 (EDT) Message-Id: <200206090532.g595W9Zs008059@thunk.east.sun.com> From: Bill Sommerfeld To: "Michel Py" cc: sommerfeld@east.sun.com, "Bob Hinden" , "Steven M. Bellovin" , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-Reply-To: Your message of "Sat, 08 Jun 2002 18:38:22 PDT." <2B81403386729140A3A899A8B39B046405E0E1@server2000.arneill-py.sacramento.ca.us> Reply-to: sommerfeld@east.sun.com Date: Sun, 09 Jun 2002 01:32:09 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > - With an RFC 1918 host behind a firewall, compromising the firewall is > enough to grant that host outside access. Single point of failure. > > - With a site-local only host behind a firewall, this become a double > hack thing: you need to reconfigure the firewall _and_ reconfigure the > host to give it a public IP. Why do you believe this makes a difference? Wouldn't site-local traffic be just as likely to leak into an ISP as RFC1918 traffic? Better isp's will filter it out in their border routers; others won't bother. - 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 Jun 8 23:05:03 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g59653k7003815; Sat, 8 Jun 2002 23:05:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g59653QR003814; Sat, 8 Jun 2002 23:05:03 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5964xk7003807 for ; Sat, 8 Jun 2002 23:05:00 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA24929 for ; Sat, 8 Jun 2002 23:05:04 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA01091 for ; Sat, 8 Jun 2002 23:05:03 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g5964qE27777; Sun, 9 Jun 2002 09:04:52 +0300 Date: Sun, 9 Jun 2002 09:04:52 +0300 (EEST) From: Pekka Savola To: Bill Sommerfeld cc: Michel Py , Bob Hinden , "Steven M. Bellovin" , Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-Reply-To: <200206090532.g595W9Zs008059@thunk.east.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sun, 9 Jun 2002, Bill Sommerfeld wrote: > > - With an RFC 1918 host behind a firewall, compromising the firewall is > > enough to grant that host outside access. Single point of failure. > > > > - With a site-local only host behind a firewall, this become a double > > hack thing: you need to reconfigure the firewall _and_ reconfigure the > > host to give it a public IP. > > Why do you believe this makes a difference? Wouldn't site-local > traffic be just as likely to leak into an ISP as RFC1918 traffic? > Better isp's will filter it out in their border routers; others won't > bother. Well, addr-arch states that routers MUST drop traffic with site-local source address at the edge of a site. But as site is rather vaguely defined, I think many vendors just skip this little detail.. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jun 8 23:46:36 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g596kZk7003855; Sat, 8 Jun 2002 23:46:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g596kZUn003854; Sat, 8 Jun 2002 23:46:35 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g596kWk7003847 for ; Sat, 8 Jun 2002 23:46:32 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA19404 for ; Sat, 8 Jun 2002 23:46:34 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA16953 for ; Sun, 9 Jun 2002 00:48:02 -0600 (MDT) Message-ID: <003401c20f81$27268970$1e6015ac@T23KEMPF> From: "James Kempf" To: "Pekka Savola" Cc: References: Subject: Re: Securing Neighbor Discovery BOF Date: Sat, 8 Jun 2002 23:40:39 -0700 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 Pekka, We will shortly be releasing the ABK draft with a statement like the Photuris statement, which was included in IKE. Also, some people believe that IPsec will work. If some way can be found around the keying problem, it could be a viable alternative. jak ----- Original Message ----- From: "Pekka Savola" To: "James Kempf" Cc: Sent: Friday, June 07, 2002 1:51 AM Subject: Re: Securing Neighbor Discovery BOF > On Fri, 7 Jun 2002, James Kempf wrote: > > On Tues. afternoon of IETF 54 13:00-14:00, there will be a BOF held to > > discuss securing Neighbor Discovery. The BOF description, along with a > > suggested reading list, will appear when the agenda is posted on the > > IETF 54 Web page. If you are interested in this problem, please attend. > > If you would like to speak, please send email to me or Pekka Nikkander > > (Pekka.Nikander@nomadiclab.com). > > Are there any non-encumbered technologies to Secure ND? > > Thought so... > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jun 8 23:46:57 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g596kuk7003865; Sat, 8 Jun 2002 23:46:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g596kup3003864; Sat, 8 Jun 2002 23:46:56 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g596kqk7003857 for ; Sat, 8 Jun 2002 23:46:52 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA29462 for ; Sat, 8 Jun 2002 23:46:54 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA19814 for ; Sun, 9 Jun 2002 00:46:53 -0600 (MDT) Message-ID: <003601c20f81$2be0b620$1e6015ac@T23KEMPF> From: "James Kempf" To: "Jari Arkko" , "Pekka Savola" Cc: References: <3D00A311.6070000@kolumbus.fi> Subject: Re: Securing Neighbor Discovery BOF Date: Sat, 8 Jun 2002 23:44:17 -0700 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 > IP Security, for one. The current IPsec can be used, though > it's pretty cumbersome due to (a) large number of similar SAs > needed for manual keying due to destination address being a > part of SA lookup and (b) chicken-and-egg problem for IKE. > The problem (a) could be solved, and the result would be a > more easily usable IPsec for securing large private networks. > For public networks manual keying does not scale, however. > Perhaps something can be done for (b). For instance, one > possible, even if ugly, solution is to provide an ND-level > message to carry IKE-like traffic between the ND > peers until an IPsec SA can be established. Contributions > on this space are sought -- feel free to jump in here ;-) > Key distribution could be done via Layer 2 AAA or using the roaming consortia idea we had in the ABK draft. However, I think that might require some change in IPsec policy, because I believe the policy only allows IKE or manual keying for key distribution. jak -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 9 04:12:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g59BCdk7004212; Sun, 9 Jun 2002 04:12:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g59BCd6l004211; Sun, 9 Jun 2002 04:12: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.12.4/8.12.4) with ESMTP id g59BCak7004204 for ; Sun, 9 Jun 2002 04:12:36 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA06078 for ; Sun, 9 Jun 2002 04:12:39 -0700 (PDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA16454 for ; Sun, 9 Jun 2002 05:12:37 -0600 (MDT) Received: from rdroms-w2k.cisco.com (rtp-vpn1-141.cisco.com [10.82.224.141]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id HAA00259 for ; Sun, 9 Jun 2002 07:12:36 -0400 (EDT) Message-Id: <4.3.2.7.2.20020609064608.00b75948@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 09 Jun 2002 07:12:31 -0400 To: From: Ralph Droms Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-Reply-To: References: <200206090532.g595W9Zs008059@thunk.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Regarding "Routers must not forward any packets with site-local source or destination addresses outside of the site." [RFC 2373] (note lower case for "must not"): the problem is not so much a vendor problem as a deployment problem. A router can't know when it's forwarding a packet outside of a site unless it's been configured with information about site borders. So network architects and admins have to define what makes up sites and configure the routers at the borders to know about those site borders. And, I don't think there's a good way to define default behavior or auto-discovery for site-local addressing... I don't see much difference between RFC 1918 addresses and site-local addresses in the areas of network design and deployment... - Ralph At 09:04 AM 6/9/2002 +0300, Pekka Savola wrote: >On Sun, 9 Jun 2002, Bill Sommerfeld wrote: > > > - With an RFC 1918 host behind a firewall, compromising the firewall is > > > enough to grant that host outside access. Single point of failure. > > > > > > - With a site-local only host behind a firewall, this become a double > > > hack thing: you need to reconfigure the firewall _and_ reconfigure the > > > host to give it a public IP. > > > > Why do you believe this makes a difference? Wouldn't site-local > > traffic be just as likely to leak into an ISP as RFC1918 traffic? > > Better isp's will filter it out in their border routers; others won't > > bother. > >Well, addr-arch states that routers MUST drop traffic with site-local >source address at the edge of a site. > >But as site is rather vaguely defined, I think many vendors just skip this >little detail.. > >-- >Pekka Savola "Tell me of difficulties surmounted, >Netcore Oy not those you stumble over and fall" >Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home Page: http://playground.sun.com/ipng >FTP archive: ftp://playground.sun.com/pub/ipng >Direct all administrative requests to majordomo@sunroof.eng.sun.com >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 9 04:54:44 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g59Bshk7004258; Sun, 9 Jun 2002 04:54:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g59BshpP004257; Sun, 9 Jun 2002 04:54:43 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g59Bsek7004250 for ; Sun, 9 Jun 2002 04:54:40 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA14356 for ; Sun, 9 Jun 2002 04:54:44 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA04148 for ; Sun, 9 Jun 2002 04:54:43 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g59BsYp31120; Sun, 9 Jun 2002 14:54:34 +0300 Date: Sun, 9 Jun 2002 14:54:33 +0300 (EEST) From: Pekka Savola To: Ralph Droms cc: ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-Reply-To: <4.3.2.7.2.20020609064608.00b75948@funnel.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sun, 9 Jun 2002, Ralph Droms wrote: > problem. A router can't know when it's forwarding a packet outside of a > site unless it's been configured with information about site borders. So > network architects and admins have to define what makes up sites and > configure the routers at the borders to know about those site > borders. And, I don't think there's a good way to define default behavior > or auto-discovery for site-local addressing... Precisely. > I don't see much difference between RFC 1918 addresses and site-local > addresses in the areas of network design and deployment... Me neither. More probable outcome is that someone starts to request that people implement NATv6, because 1) they're already used to it (and like its "security") in v4 world, and 2) they think it's easier for them to do NAT than to renumber. Site-locals were born in the era that not all sites had internet connectivity. Now that assumption is not all that valid anymore. It's just easier for people to use a global address block (even if we define that address block to be 3ffe:eff3::/32 or whatever) even with these "internal needs" (note: I believe there should be _something_ that does not require you to fill any kind of paperwork). > At 09:04 AM 6/9/2002 +0300, Pekka Savola wrote: > >On Sun, 9 Jun 2002, Bill Sommerfeld wrote: > > > > - With an RFC 1918 host behind a firewall, compromising the firewall is > > > > enough to grant that host outside access. Single point of failure. > > > > > > > > - With a site-local only host behind a firewall, this become a double > > > > hack thing: you need to reconfigure the firewall _and_ reconfigure the > > > > host to give it a public IP. > > > > > > Why do you believe this makes a difference? Wouldn't site-local > > > traffic be just as likely to leak into an ISP as RFC1918 traffic? > > > Better isp's will filter it out in their border routers; others won't > > > bother. > > > >Well, addr-arch states that routers MUST drop traffic with site-local > >source address at the edge of a site. > > > >But as site is rather vaguely defined, I think many vendors just skip this > >little detail.. > > > >-- > >Pekka Savola "Tell me of difficulties surmounted, > >Netcore Oy not those you stumble over and fall" > >Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > > >-------------------------------------------------------------------- > >IETF IPng Working Group Mailing List > >IPng Home Page: http://playground.sun.com/ipng > >FTP archive: ftp://playground.sun.com/pub/ipng > >Direct all administrative requests to majordomo@sunroof.eng.sun.com > >-------------------------------------------------------------------- > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jun 9 07:11:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g59EBWk7004383; Sun, 9 Jun 2002 07:11:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g59EBWIJ004382; Sun, 9 Jun 2002 07:11:32 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g59EBSk7004375 for ; Sun, 9 Jun 2002 07:11:28 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA04229 for ; Sun, 9 Jun 2002 07:11:31 -0700 (PDT) Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA26196 for ; Sun, 9 Jun 2002 07:11:30 -0700 (PDT) Received: from postal.research.att.com (postal.research.att.com [135.207.23.30]) by mail-green.research.att.com (Postfix) with ESMTP id CFD781E0B6; Sun, 9 Jun 2002 10:11:29 -0400 (EDT) Received: from berkshire.research.att.com (postal.research.att.com [135.207.23.30]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id KAA05531; Sun, 9 Jun 2002 10:06:13 -0400 (EDT) Received: from research.att.com (localhost [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id 0B9717B4B; Sun, 9 Jun 2002 10:11:17 -0400 (EDT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: "Steven M. Bellovin" To: "James Kempf" Cc: "Jari Arkko" , "Pekka Savola" , ipng@sunroof.eng.sun.com Subject: Re: Securing Neighbor Discovery BOF Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 09 Jun 2002 10:11:17 -0400 Message-Id: <20020609141117.0B9717B4B@berkshire.research.att.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <003601c20f81$2be0b620$1e6015ac@T23KEMPF>, "James Kempf" writes: >> IP Security, for one. The current IPsec can be used, though >> it's pretty cumbersome due to (a) large number of similar SAs >> needed for manual keying due to destination address being a >> part of SA lookup and (b) chicken-and-egg problem for IKE. >> The problem (a) could be solved, and the result would be a >> more easily usable IPsec for securing large private networks. >> For public networks manual keying does not scale, however. >> Perhaps something can be done for (b). For instance, one >> possible, even if ugly, solution is to provide an ND-level >> message to carry IKE-like traffic between the ND >> peers until an IPsec SA can be established. Contributions >> on this space are sought -- feel free to jump in here ;-) >> > >Key distribution could be done via Layer 2 AAA or using the roaming >consortia idea we had in the ABK draft. However, I think that might >require some change in IPsec policy, because I believe the policy only >allows IKE or manual keying for key distribution. That's not correct. In fact, there's another working group, KINK, whose goal is Kerberos key management for IPsec. --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com ("Firewalls" book) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 9 07:16:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g59EGjk7004417; Sun, 9 Jun 2002 07:16:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g59EGjtO004416; Sun, 9 Jun 2002 07:16:45 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g59EGfk7004409 for ; Sun, 9 Jun 2002 07:16:41 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA05098 for ; Sun, 9 Jun 2002 07:16:43 -0700 (PDT) Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA27130 for ; Sun, 9 Jun 2002 07:16:43 -0700 (PDT) Received: from postal.research.att.com (postal.research.att.com [135.207.23.30]) by mail-green.research.att.com (Postfix) with ESMTP id 05D6C1E0B2; Sun, 9 Jun 2002 10:16:43 -0400 (EDT) Received: from berkshire.research.att.com (postal.research.att.com [135.207.23.30]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id KAA05554; Sun, 9 Jun 2002 10:11:27 -0400 (EDT) Received: from research.att.com (localhost [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id 1896C7B4B; Sun, 9 Jun 2002 10:16:41 -0400 (EDT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: "Steven M. Bellovin" To: Pekka Savola Cc: Ralph Droms , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 09 Jun 2002 10:16:41 -0400 Message-Id: <20020609141641.1896C7B4B@berkshire.research.att.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message , Pekka Savola writes: >On Sun, 9 Jun 2002, Ralph Droms wrote: >> problem. A router can't know when it's forwarding a packet outside of a >> site unless it's been configured with information about site borders. So >> network architects and admins have to define what makes up sites and >> configure the routers at the borders to know about those site >> borders. And, I don't think there's a good way to define default behavior >> or auto-discovery for site-local addressing... > >Precisely. Yup -- and now we're elevating it to an architectural principle. > >> I don't see much difference between RFC 1918 addresses and site-local >> addresses in the areas of network design and deployment... > >Me neither. More probable outcome is that someone starts to request that >people implement NATv6, because 1) they're already used to it (and like >its "security") in v4 world, and 2) they think it's easier for them to do >NAT than to renumber. > >Site-locals were born in the era that not all sites had internet >connectivity. Now that assumption is not all that valid anymore. It's >just easier for people to use a global address block (even if we define >that address block to be 3ffe:eff3::/32 or whatever) even with these >"internal needs" (note: I believe there should be _something_ that does >not require you to fill any kind of paperwork). > Yah. Let's pick a prefix, and tell folks to pick a random number (more precisely, use an RFC 1750-compatible RNG) to fill out the rest of the high-order bits to a /48 or a /64. We encourage ISPs to provide real prefixes to companies that are using application-layer gateways, and hence don't "need" a routable prefix. We promise two months of connectivity to folks using non-conflicting random prefixes when they connect, while they renumber. We think of other, creative solutions that exploit the fact that we have a really large address space that we're not going to exhaust. In short, that we do *something* that isn't going to cause long-term architectural and operational pain. --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com ("Firewalls" book) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 9 07:36:02 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g59Ea2k7004446; Sun, 9 Jun 2002 07:36:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g59Ea1Ln004445; Sun, 9 Jun 2002 07:36:01 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g59EZwk7004438 for ; Sun, 9 Jun 2002 07:35:58 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA24673 for ; Sun, 9 Jun 2002 07:36:01 -0700 (PDT) Received: from mail6.nc.rr.com (fe6.southeast.rr.com [24.93.67.53]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA10007 for ; Sun, 9 Jun 2002 08:37:31 -0600 (MDT) Received: from nc.rr.com ([24.162.252.183]) by mail6.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Sun, 9 Jun 2002 10:36:00 -0400 Message-ID: <3D036720.7B02E8E8@nc.rr.com> Date: Sun, 09 Jun 2002 10:33:05 -0400 From: Brian Haberman X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Margaret Wasserman CC: ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols References: <4.2.2.20020605134805.0245def0@mail.windriver.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Margaret, I suppose that I should admit to being remiss in this area. I have done a fair amount of work in this area and just haven't had the time to document routing protocol behavior changes to support site local prefixes (even though I recall telling you I was going to do it). Anyway, I will start by saying that I have modified RIPng to correctly handle the advertisement of site-locals. In order to make this efficient, I maintained the concept of a single instance of RIPng running in the router. In order to understand the changes to the routing protocol, you also have to understand the changes to the RIB for site locals. So, how did I make it work? 1. The RIB now contains an additional field, the zone ID. I have done this in two different ways. The first is to add the zone ID as a separate field. The second is to embed the zone ID in the "unused" portion of the site local prefix. 2. RIPng was changed to build its route advertisement messages on a per zone ID basis. That is, it starts with adding all global prefixes to the message. It then adds site local prefixes that are in the same zone ID as the interface that the advertisement will be transmitted. It determines this by extracting the zone ID from the outgoing interface and using this find all site locals in the RIB with a matching zone ID. 3. When RIPng receives a route advertisement from a peer, it takes the zone ID from the receiving interface and using that to add the site local prefixes to the RIB. That, in a nutshell, allows a single instance of RIPng to control the advertising of site local unicast prefixes. Though I haven't done the work, I would see OSPF as acting in a similar manner. If someone wants me to describe the actual forwarding, just let me know. Regards, Brian Margaret Wasserman wrote: > > I sent the attached message to the routing area discussion list. I thought that people on > the IPv6 list might be interested in this discussion, so I will forward a message containing > the responses after this one. I suppose I just should have cc:ed the IPv6 group in the > first place... > > Margaret > > >Date: Fri, 24 May 2002 12:17:04 -0400 > >To: routing-discussion@ietf.org > >From: Margaret Wasserman > >Subject: IPv6 Scoped Addresses and Routing Protocols > > > > > > > >Hi All, > > > >I raised some questions with Bill Fenner in Minneapolis regarding IPv6 scoped > >addressing and our current IPv6 routing protocol specifications, and Bill suggested > >that I should send my questions to this list for discussion. So, here they are. > > > >First, some background... > > > >As many of you probably know, IPv6 includes the concept of scoped unicast > >addressing -- a unicast address can have link-local scope, site-local scope > >or global scope. The address scopes are defined in the IPv6 Addressing > >Architecture: > > > >http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-addr-arch-v3-07.txt > > > >Additional information can be found in the IPv6 Scoped Address > >Architecture: > > > >http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-scoping-arch-03.txt > > > >I would suggest that all of you read the IPv6 Scoped Address Architecture > >document, if you haven't already, as it contains information regarding > >the expected configuration and forwarding behaviour of IPv6 routers. > >It also defines the concept of an IPv6 site, which is important to understanding > >the questions that I am about to raise. > > > >In IPv6, there is a concept of site-local addressing that is quite different > >from the concept of "net 10" addresses in IPv4. Sites are administratively > >defined entities that must be "convex" (i.e. the best route between two nodes > >in the site must, at all scopes, fall completely within the site). Sites boundaries > >run through routers, so a single router (called a site border router (SBR)) can > >have interfaces in more than one site. And, IPv6 site-local addresses can be > >used for site-constrained communication, even when a site is globally > >connected and global addresses are available. > > > >Because all site-local addresses use the same well-known site-local prefix, the > >only way to tell that a particular site-local address belongs to a particular > >site is to know which site originated the address. SBRs will need > >to enforce site boundaries, not mixing site-local routing information, and not > >forwarding packets outside of a given site. To do this, it is expected that > >SBRs will need to maintain multiple "conceptual routing tables", including one > >site-local routing table for each attached site, and one global routing table. > > > >Unfortunately, I can't find any indication that these concepts have been reflected > >in the current IPv6 routing protocols. None of our IPv6 routing protocol documents > >deal with site-local boundaries or SBR behaviour explicitly. > > > >There are currently four standards for how IPv6 routes will be handled in BGP, OSPF, > >IS-IS and RIP. I will refer to these documents as BGP-IPv6, OSPF-IPv6 and IS-IS-IPv6, > >and RIP-IPv6 respectively: > > > >Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing: > >http://www.ietf.org/rfc/rfc2545.txt > > > >OSPF for IPv6 > >http://www.ietf.org/rfc/rfc2740.txt > > > >Routing IPv6 with IS-IS: > >http://www.ietf.org/internet-drafts/draft-ietf-isis-ipv6-02.txt > > > >RIPng for IPv6 > >http://www.ietf.org/rfc/rfc2080.txt > > > >So here are my actual questions: > > > >(1) Are the statements regarding the routing system in the IPv6 Scoped Addressing Architecture > >draft valid? Will they work in real life? Please read it, and comment to the IPv6 WG if you think that > >there are any issues with what it says. > > > >(2) BGP-IPv6: > > > >BGP-IPv6 states: "As this document makes no assumption on the characteristics of a particular > >routing realm where BGP-4 is used, it makes no distinction between global and site-local addresses > >and refers to both as "global" or "non-link-local"." > > > >Would it ever be reasonable for BGP to propagate site-local routing information? Why, under > >what circumstances? Would it be reasonable to assume that an Inter-Domain Routing protocol > >shouldn't propagate site-local information at all? > > > >If BGP should be capable of propagating site-local information, will it be possible, using existing > >BGP standards for a BGP SBR router with four interfaces (A, B, C & D), in two sites (A & B in S1, > >and C & D in S2) to maintain two separate sets of information for prefix FEC0::/10, one that applies > >to S1 (interfaces A & B) and one that applies to S2 (interfaces C & D), and to propagate that information > >accordingly? Is this really just an issue of configuring the router properly, as BGP-IPv6 implies? > > > >(3) OSPF-IPV6: > > > >In this specification, no distinction is made between site-local and global addresses. Unlike the > >previous specification (BGP-IPv6), this assumption is not stated up-front. Instead, everywhere in > >the draft where either site-local or global addresses are mentioned they are both mentioned (i.e. > >"site-local or global IPv6 addresses"). > > > >Again this specification makes no provision for separate sets of site local information. There is > >also no mention of a boundary for site-local route propagation, and no mention of multiple conceptual > >sets of site-local routing information. Would it make sense to tie the concept of an IPv6 site to > >one of the existing propagation boundaries in OSPF, such as an OSPF area? Or to assume that > >an OSPF AS will always be completely contained within one site -- which is what the current draft > >seems to assume? > > > >(4) IS-IS-IPv6: > > > >IS-IS-IPv6 makes no mention of site-local or scoped addressing at all. Is this appropriate? How will IS-IS > >SBRs know not to propagate site-local routing information between two attached sites? I don't yet > >know enough about IS-IS to understand how site-local routing information would best be handled > >in IS-IS. Any thoughts? > > > >(5) RIP-IPv6: > > > >The RIP-IPv6 document explicitly states that there is a single IPv6 routing table, and it makes no > >mention of sites. I think it would be fine to constrain RIP to operating within a single IPv6 > >site, but that should be explicitly stated somewhere. > > > >(6) Will the MIBs for any of these routing tables be capable of representing multiple independent, > >possibly overlapping sets of site-local routing information? I looked them over quickly, and it > >wasn't immediately obvious to me how they could do this. > > > >(7) Do you think that there would be some utility to defining the actual routing architecture (as > >opposed to just the addressing architecture) for IPv6? If so, what would be the best way to do > >that? > > > >(8) Should we mention link-local addresses anywhere in these specifications? We certainly would > >not want to propagate routing information for link-local addresses. > > > >If there is some work that needs to be done here, I am very happy to provide some IPv6 expertise > >to that effort. > > > >Margaret > > > > > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 9 07:38:51 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g59Ecpk7004469; Sun, 9 Jun 2002 07:38:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g59EcpnA004468; Sun, 9 Jun 2002 07:38:51 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g59Ecmk7004461 for ; Sun, 9 Jun 2002 07:38:48 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA24873 for ; Sun, 9 Jun 2002 07:38:51 -0700 (PDT) Received: from mail5.nc.rr.com (fe5.southeast.rr.com [24.93.67.52]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA24720 for ; Sun, 9 Jun 2002 08:38:50 -0600 (MDT) Received: from nc.rr.com ([24.162.252.183]) by mail5.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Sun, 9 Jun 2002 10:38:20 -0400 Message-ID: <3D0367AA.A7643813@nc.rr.com> Date: Sun, 09 Jun 2002 10:35:22 -0400 From: Brian Haberman X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Ralph Droms CC: ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols References: <200206090532.g595W9Zs008059@thunk.east.sun.com> <4.3.2.7.2.20020609064608.00b75948@funnel.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ralph, Ralph Droms wrote: > And, I don't think there's a good way to define default behavior > or auto-discovery for site-local addressing... Well, we could very easily apply RFC 2776 to the problem. It is already designed to advertise multicast zones. I may not help with auto-configuring the borders, but it will help debug them. 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 Sun Jun 9 07:42:55 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g59Egtk7004498; Sun, 9 Jun 2002 07:42:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g59EgtiF004497; Sun, 9 Jun 2002 07:42:55 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g59Egqk7004490 for ; Sun, 9 Jun 2002 07:42:52 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA08805 for ; Sun, 9 Jun 2002 07:42:54 -0700 (PDT) Received: from mail7.nc.rr.com (mail7.southeast.rr.com [24.93.67.54]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA11300 for ; Sun, 9 Jun 2002 08:44:24 -0600 (MDT) Received: from nc.rr.com ([24.162.252.183]) by mail7.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Sun, 9 Jun 2002 10:41:18 -0400 Message-ID: <3D03685F.3D959F56@nc.rr.com> Date: Sun, 09 Jun 2002 10:38:23 -0400 From: Brian Haberman X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Steven M. Bellovin" CC: Pekka Savola , Ralph Droms , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols References: <20020609141641.1896C7B4B@berkshire.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve, "Steven M. Bellovin" wrote: > Yah. Let's pick a prefix, and tell folks to pick a random number (more > precisely, use an RFC 1750-compatible RNG) to fill out the rest of the > high-order bits to a /48 or a /64. We encourage ISPs to provide real > prefixes to companies that are using application-layer gateways, and > hence don't "need" a routable prefix. We promise two months of > connectivity to folks using non-conflicting random prefixes when they > connect, while they renumber. We think of other, creative solutions > that exploit the fact that we have a really large address space that > we're not going to exhaust. > > In short, that we do *something* that isn't going to cause long-term > architectural and operational pain. I suggested several years ago that the site-local prefixes could contain more info to help "identify" it. I was told that it had been discussed and was not beneficial enough. Adding an AS # or some other identifier would definitely help clarify the prefixes. 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 Sun Jun 9 12:12:26 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g59JCPk7004934; Sun, 9 Jun 2002 12:12:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g59JCPRU004933; Sun, 9 Jun 2002 12:12:25 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g59JCMk7004926 for ; Sun, 9 Jun 2002 12:12:22 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA11060 for ; Sun, 9 Jun 2002 12:12:26 -0700 (PDT) Received: from tndh.net (evrtwa1-ar8-4-65-028-011.evrtwa1.dsl-verizon.net [4.65.28.11]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA18886 for ; Sun, 9 Jun 2002 13:12:21 -0600 (MDT) Received: from eagleswings (127.0.0.1) by localhost (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Sun, 09 Jun 2002 12:12:55 -0700 From: "Tony Hain" To: "Steven M. Bellovin" , "Pekka Savola" Cc: "Ralph Droms" , Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols Date: Sun, 9 Jun 2002 12:11:44 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20020609141641.1896C7B4B@berkshire.research.att.com> X-Mimeole: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steven M. Bellovin wrote: > In message > , Pekka Savola > writes: > >On Sun, 9 Jun 2002, Ralph Droms wrote: > >> problem. A router can't know when it's forwarding a > packet outside of a > >> site unless it's been configured with information about > site borders. So > >> network architects and admins have to define what makes up > sites and > >> configure the routers at the borders to know about those site > >> borders. And, I don't think there's a good way to define > default behavior > >> or auto-discovery for site-local addressing... > > > >Precisely. > > Yup -- and now we're elevating it to an architectural principle. > > > >> I don't see much difference between RFC 1918 addresses and > site-local > >> addresses in the areas of network design and deployment... > > > >Me neither. More probable outcome is that someone starts to > request that > >people implement NATv6, because 1) they're already used to > it (and like > >its "security") in v4 world, and 2) they think it's easier > for them to do > >NAT than to renumber. > > > >Site-locals were born in the era that not all sites had internet > >connectivity. Now that assumption is not all that valid > anymore. It's > >just easier for people to use a global address block (even > if we define > >that address block to be 3ffe:eff3::/32 or whatever) even with these > >"internal needs" (note: I believe there should be > _something_ that does > >not require you to fill any kind of paperwork). > > > > Yah. Let's pick a prefix, and tell folks to pick a random > number (more > precisely, use an RFC 1750-compatible RNG) to fill out the > rest of the > high-order bits to a /48 or a /64. We encourage ISPs to provide real > prefixes to companies that are using application-layer gateways, and > hence don't "need" a routable prefix. We promise two months of > connectivity to folks using non-conflicting random prefixes when they > connect, while they renumber. We think of other, creative solutions > that exploit the fact that we have a really large address space that > we're not going to exhaust. > > In short, that we do *something* that isn't going to cause long-term > architectural and operational pain. While I am all for avoiding architectural and operational pain, I don't see this is as big a deal as the thread seems to be making it out to be. There is no need for fixing the IGPs to deal with SiteLocal as they run within the context of the site, therefore shouldn't know about any other sites. Implementations where a given router will have an interface in multiple sites will need a way to tag and keep each IGP isolated. The simplest way is to track which interface the IGP message comes in on and make sure it maps to the corresponding IGP process. I think most of this thread is focused on what are simply implementation details, not an issue for the standards per se. The biggest issue I saw was related to DNS returning SL or not, and this is not an issue as long as the DNS server is not expected to deal with multiple sites. As long as routing is filtering SL at the borders, the only way a DNS query would get to the SL of the DNS server would be within a site, and the only reason a DNS server should return an SL address is if the query was addressed to its SL address. Maybe this needs to be stated clearly in the ngtrans doc on DNS issues, but this should be obvious from the perspective of 'don't return an answer that can't be used'. What this means is that an SP will not provide SL addresses for customers. This is not a problem today, unless an SP DNS is resolving to RFC1918 addresses. Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jun 9 12:46:36 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g59Jkak7004990; Sun, 9 Jun 2002 12:46:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g59JkatF004989; Sun, 9 Jun 2002 12:46: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.12.4/8.12.4) with ESMTP id g59JkXk7004982 for ; Sun, 9 Jun 2002 12:46:33 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA25866 for ; Sun, 9 Jun 2002 12:46:34 -0700 (PDT) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA08537 for ; Sun, 9 Jun 2002 13:46:34 -0600 (MDT) content-class: urn:content-classes:message Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 9 Jun 2002 12:46:31 -0700 Message-ID: <2B81403386729140A3A899A8B39B046405E0E6@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Fwd: IPv6 Scoped Addresses and Routing Protocols Thread-Index: AcIPpubg5M/XimvZQQuvePk/hCOvtgARa8rQ From: "Michel Py" To: "Ralph Droms" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g59JkXk7004983 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Ralph Droms wrote: > Regarding "Routers must not forward any packets with site-local source > or destination addresses outside of the site." [RFC 2373] (note lower > case for "must not"): the problem is not so much a vendor problem as > a deployment problem. A router can't know when it's forwarding a > packet outside of a site unless it's been configured with information > about site borders. So network architects and admins have to define > what makes up sites and configure the routers at the borders to know > about those site borders. Exactly. > I don't see much difference between RFC 1918 addresses and site-local > addresses in the areas of network design and deployment... The difference is that an RFC 1918 host is likely to have access to the outside world through NAT, when a site-local only v6 host is _not_. And we all agree that the "security" provided by RFC 1918 addresses is a joke, mostly because of the presence of NAT. In the v4 world, it is typical to have only one v4 address per host interface, and therefore where there is RFC 1918 addresses you can bet there is NAT nearby. The v6 situation is different: One does not need NAT to access the outside and use site-local at the same time. Therefore, one of the reasons people would use site-local addresses is for security reasons, and not a by-product of not having enough v4 addresses. The question Steve Bellovin was asking (if I interpret it correctly) is more or less "does anybody need site-local addresses anyway?". I do. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 9 16:02:13 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g59N2Dk7005148; Sun, 9 Jun 2002 16:02:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g59N2C4r005147; Sun, 9 Jun 2002 16:02:12 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g59N29k7005140 for ; Sun, 9 Jun 2002 16:02:09 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA05259 for ; Sun, 9 Jun 2002 16:02:12 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA24004 for ; Sun, 9 Jun 2002 16:02:12 -0700 (PDT) Received: from kenawang ([147.11.233.17]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id QAA14271; Sun, 9 Jun 2002 16:00:50 -0700 (PDT) Message-Id: <4.2.2.20020609185002.019fcc50@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Sun, 09 Jun 2002 18:56:11 -0400 To: Brian Haberman From: Margaret Wasserman Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols Cc: ipng@sunroof.eng.sun.com In-Reply-To: <3D036720.7B02E8E8@nc.rr.com> References: <4.2.2.20020605134805.0245def0@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Brian, >That, in a nutshell, allows a single instance of RIPng to control >the advertising of site local unicast prefixes. Though I haven't >done the work, I would see OSPF as acting in a similar manner. This does sound like it would work, and that similar changes would work for other routing protocols. I don't think that any rocket science is necessary to get site-local addressing and routing to work. However, there is additional specification work required in the routing area to make the routing protocols consistent with current IPv6 thinking on the use of site-local addresses. I'm also concerned about the complexity that site-local addressing adds to an IPv6 host. Looking at the default address selection rules, it appears that host implementations will be impacted by site-local addressing (implementation size and complexity), even in cases where it isn't really used. Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jun 9 16:12:19 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g59NCJk7005186; Sun, 9 Jun 2002 16:12:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g59NCJJE005185; Sun, 9 Jun 2002 16:12:19 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g59NCEk7005177 for ; Sun, 9 Jun 2002 16:12:14 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA06099 for ; Sun, 9 Jun 2002 16:12:18 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA10100 for ; Sun, 9 Jun 2002 17:12:17 -0600 (MDT) Received: from kenawang ([147.11.233.17]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id QAA18016; Sun, 9 Jun 2002 16:10:52 -0700 (PDT) Message-Id: <4.2.2.20020609190831.01a361b0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Sun, 09 Jun 2002 19:09:02 -0400 To: "Michel Py" From: Margaret Wasserman Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols Cc: "Ralph Droms" , In-Reply-To: <2B81403386729140A3A899A8B39B046405E0E6@server2000.arneill- py.sacramento.ca.us> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Michel, >The question Steve Bellovin was asking (if I interpret it correctly) is >more or less "does anybody need site-local addresses anyway?". I do. What do you need them for? Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jun 9 16:12:14 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g59NCEk7005176; Sun, 9 Jun 2002 16:12:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g59NCED0005175; Sun, 9 Jun 2002 16:12:14 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g59NCAk7005168 for ; Sun, 9 Jun 2002 16:12:10 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA02269 for ; Sun, 9 Jun 2002 16:12:10 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA10076 for ; Sun, 9 Jun 2002 17:12:09 -0600 (MDT) Received: from kenawang ([147.11.233.17]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id QAA18012; Sun, 9 Jun 2002 16:10:50 -0700 (PDT) Message-Id: <4.2.2.20020609185715.0196ab50@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Sun, 09 Jun 2002 19:07:39 -0400 To: "Tony Hain" From: Margaret Wasserman Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols Cc: In-Reply-To: References: <20020609141641.1896C7B4B@berkshire.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Tony, >While I am all for avoiding architectural and operational pain, I don't >see this is as big a deal as the thread seems to be making it out to be. >There is no need for fixing the IGPs to deal with SiteLocal as they run >within the context of the site, therefore shouldn't know about any other >sites. This is not necessarily true. There is no restriction on that site borders must match IGP or EGP routing borders of any kind. If we could require some relationship between site borders and routing protocol borders, it might make things easier. However, it is unclear which border it would make the most sense to pick. Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jun 9 16:49:51 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g59Nnok7005247; Sun, 9 Jun 2002 16:49:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g59NnoDN005246; Sun, 9 Jun 2002 16:49:50 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g59Nnjk7005239 for ; Sun, 9 Jun 2002 16:49:45 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA20190 for ; Sun, 9 Jun 2002 16:49:49 -0700 (PDT) Received: from minotaur.nge.isi.edu (minotaur.nge.isi.edu [65.114.169.202]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA16607 for ; Sun, 9 Jun 2002 17:51:20 -0600 (MDT) Received: from minotaur (mankin@localhost) by minotaur.nge.isi.edu (8.11.6/8.11.6) with ESMTP id g59NnYL11121; Sun, 9 Jun 2002 19:49:39 -0400 Message-Id: <200206092349.g59NnYL11121@minotaur.nge.isi.edu> To: "Tony Hain" cc: "Steven M. Bellovin" , "Pekka Savola" , "Ralph Droms" , ipng@sunroof.eng.sun.com Reply-To: mankin@isi.edu Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-reply-to: Your message of Sun, 09 Jun 2002 12:11:44 -0700. Mime-Version: 1.0 (generated by tm-edit 1.7) Content-Type: text/plain; charset=US-ASCII Date: Sun, 09 Jun 2002 19:49:34 -0400 From: Allison Mankin Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > and the > only reason a DNS server should return an SL address is if the query was > addressed to its SL address. Maybe this needs to be stated clearly in > the ngtrans doc on DNS issues, but this should be obvious from the > perspective of 'don't return an answer that can't be used'. I would question whether this is well-understood and DNS servers are ready to select which AAAA records to reply with depending on the address the query was sent to. Do current servers implement this, including caching servers? Allison -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 9 17:48:52 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5A0mpk7005287; Sun, 9 Jun 2002 17:48:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5A0mp0x005286; Sun, 9 Jun 2002 17:48:51 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5A0mmk7005279 for ; Sun, 9 Jun 2002 17:48:48 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA17390 for ; Sun, 9 Jun 2002 17:48:51 -0700 (PDT) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA02137 for ; Sun, 9 Jun 2002 18:48:50 -0600 (MDT) content-class: urn:content-classes:message Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 9 Jun 2002 17:48:44 -0700 Message-ID: <2B81403386729140A3A899A8B39B046405E0E8@server2000.arneill-py.sacramento.ca.us> X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 X-MS-TNEF-Correlator: Thread-Topic: Fwd: IPv6 Scoped Addresses and Routing Protocols Thread-Index: AcIQCykp6vweA9O9Q4KknxUQlqeH7AAAlzWQ From: "Michel Py" To: "Margaret Wasserman" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5A0mmk7005280 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret, > [site-local addresses] > What do you need them for? In a nutshell, to put one more obstacle in the hacker's way. I was trying to make the point that site-local addresses do provide some extra security, compared to RFC 1918 addresses that provide only the illusion of extra security. Let's look at a very common situation: IPv4 / RFC1918 : ---------------- - The network has a stateful firewall and uses NAT. - There is a web server with a public IP address in the DFZ. - There is a database server with an RFC 1918 address in the inside. - The web server needs to access the database server. - There is a hole in the firewall to let the web server access the database server. - There is a backdoor in the database server. (1) - The hacker wants the contents of the database and knows about the backdoor. How many things are necessary for the hacker to do in order to access the data? One: compromise the firewall. The hacker opens another hole in the firewall to allow backdoor access and creates a static NAT mapping and voila, data is gone. IPv6 / site-local: ------------------ - The network has a stateful firewall. - There is a web server with a public IP address in the DFZ. The web server also has a site-local address. - There is a database server with only a site-local address in the inside. - The web server needs to access the database server. - There is a hole in the firewall to let the web server access the database server. - There is a backdoor in the database server. (1) - The hacker wants the contents of the database and knows about the backdoor. How many things are necessary for the hacker to do in order to access the data? _more_ than one. If the hacker compromises the firewall and opens another hole in the firewall to allow backdoor access, it is not enough because the hacker's host does not have a route to the database server's site-local address. The odds of this are worse than winning the lottery. Even if we have occasionally seen people advertising 10.0.0.0/8 in the DFZ, this is typically filtered. Same thing applies to v6: it will quickly become standard practice to deny FEC0:: same as we deny 10.0.0.0 today. So, site-local addresses alone do not secure a network, but they do make the hacker's task more complicated, which does indeed help securing the network. In the example above, when I look at the extra annoyance for the hacker (we are talking about either installing a proxy on a third host that needs to be compromised or reconfiguring the IP stack on the database server) it appears to me that it is worth implementing it. You made a good point earlier about the consequences on default address selection, but the fact of the matter is that site-local addresses exist today; I agree with the assessment that Bob Hinden as made as chair that this working group was has been leaning towards full use of site-local addresses. The point I am trying to make is: site-local addresses do provide functionality, there are built in many documents, don't we have any better to do today but to try to remove them? Michel. (1) There are many examples of these, I remember one on Interbase that took two years to be discovered after the product became open-source. The backdoor could also have been installed by a disgruntled employee -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 9 19:31:40 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5A2Vek7005404; Sun, 9 Jun 2002 19:31:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5A2VeMu005403; Sun, 9 Jun 2002 19:31:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5A2Vak7005396 for ; Sun, 9 Jun 2002 19:31:36 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA25541 for ; Sun, 9 Jun 2002 19:31:36 -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 UAA17255 for ; Sun, 9 Jun 2002 20:31:35 -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 14FFC4CE03; Sun, 9 Jun 2002 22:31:31 -0400 (EDT) Received: from berkshire.research.att.com (postal.research.att.com [135.207.23.30]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id WAA09944; Sun, 9 Jun 2002 22:25:59 -0400 (EDT) Received: from research.att.com (localhost [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id C7ED07B4B; Sun, 9 Jun 2002 22:31:14 -0400 (EDT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: "Steven M. Bellovin" To: "Tony Hain" Cc: "Pekka Savola" , "Ralph Droms" , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 09 Jun 2002 22:31:14 -0400 Message-Id: <20020610023114.C7ED07B4B@berkshire.research.att.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message , "Tony Hain" writes : > > >While I am all for avoiding architectural and operational pain, I don't >see this is as big a deal as the thread seems to be making it out to be. >There is no need for fixing the IGPs to deal with SiteLocal as they run >within the context of the site, therefore shouldn't know about any other >sites. Implementations where a given router will have an interface in >multiple sites will need a way to tag and keep each IGP isolated. The >simplest way is to track which interface the IGP message comes in on and >make sure it maps to the corresponding IGP process. > >I think most of this thread is focused on what are simply implementation >details, not an issue for the standards per se. The biggest issue I saw >was related to DNS returning SL or not, and this is not an issue as long >as the DNS server is not expected to deal with multiple sites. As long >as routing is filtering SL at the borders, the only way a DNS query >would get to the SL of the DNS server would be within a site, and the >only reason a DNS server should return an SL address is if the query was >addressed to its SL address. Maybe this needs to be stated clearly in >the ngtrans doc on DNS issues, but this should be obvious from the >perspective of 'don't return an answer that can't be used'. > >What this means is that an SP will not provide SL addresses for >customers. This is not a problem today, unless an SP DNS is resolving to >RFC1918 addresses. The problem is that the definition of "site" you assume above doesn't match the RFCs, which are deliberately vague. If it were AS-local or organization-local addresses, I'd be much less concerned. But it's site-local, which is not the same thing. Quoting draft-ietf-ipngwg-scoping-arch-03.txt: A "site" is, by intent, not rigorously defined, but is typically expected to cover a region of topology that belongs to a single organization and is located within a single geographic location, such as an office, an office complex, or a campus. For a multi-site company, that's smaller than an AS. As I noted earlier, DNS servers are supposed to be distributed across multiple sites, and a remote one doesn't know whether or not a querier is in the same site as the destination. Maybe a DNS server could look to see if the querying address is site-local, but that implies site-local addresses (indirectly) in NS records. It also implies that even within a site, a host will sometimes get the site-local address of the destination and sometimes the global address, depending on which DNS server it happened to query. This strikes me as seriously ugly. And, as Allison has pointed out, it's not at all clear that we've worked through all the cases for caching servers or mobile IP. --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com ("Firewalls" book) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 9 21:03:18 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5A43Ik7005594; Sun, 9 Jun 2002 21:03:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5A43IFO005593; Sun, 9 Jun 2002 21:03:18 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5A43Fk7005586 for ; Sun, 9 Jun 2002 21:03:15 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA18090 for ; Sun, 9 Jun 2002 21:03:19 -0700 (PDT) Received: from TYO201.gate.nec.co.jp (TYO201.gate.nec.co.jp [202.32.8.214]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA09050 for ; Sun, 9 Jun 2002 22:03:06 -0600 (MDT) Received: from mailgate4.nec.co.jp ([10.7.69.195]) by TYO201.gate.nec.co.jp (8.11.6/3.7W01080315) with ESMTP id g5A434201039; Mon, 10 Jun 2002 13:03:04 +0900 (JST) Received: from mailsv.nec.co.jp (mailgate51.nec.co.jp [10.7.69.196]) by mailgate4.nec.co.jp (8.11.6/3.7W-MAILGATE-NEC) with ESMTP id g5A433821429; Mon, 10 Jun 2002 13:03:03 +0900 (JST) Received: from ryoma.jp.nec.com (ryoma.jp.nec.com [10.26.220.1]) by mailsv.nec.co.jp (8.11.6/3.7W-MAILSV-NEC) with ESMTP id g5A433Z13893; Mon, 10 Jun 2002 13:03:03 +0900 (JST) Received: from [10.42.72.128] by mail.jp.nec.com; Mon, 10 Jun 2002 13:03:02 +0900 Date: Mon, 10 Jun 2002 13:02:56 +0900 From: Hiroki Ishibashi Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols To: "Steven M. Bellovin" Cc: ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: TuruKame 1.96 (WinNT,500) Organization: NEC Corporation In-Reply-To: <20020607153544.37F897B4B@berkshire.research.att.com> References: <20020607153544.37F897B4B@berkshire.research.att.com> Message-Id: <6EC21033B3E449bashi@ipv6.nec.co.jp> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steven M. Bellovin wrote: >In message <63C20DCF3205EFbashi@ipv6.nec.co.jp>, Hiroki Ishibashi writes: > >>Now, OSPFv3. Since it is much complicated than any RIPng, of course, >>and it has capability to run multiple processes by nature, we decided to >>run an OSPFv3 process per site. Still, we could have handle site routing >>with single OSPFv3 process. Complication is the most dominant factor in our >>decision. For example, what if someone is sending an Intra-Area-Prefix-LSA >>which contains both global and site-local prefixes. Receiving OSPFv3 router >>might need to decompose LSA into two LSAs which contain global and site-local >>separately. BUT, this is not allowed. I believe that we need to make >>agreements on this point. >>One of our concerns on multi-process implementation is that >>global prefixes need to be redistributed among OSPFv3 process once >>sites are defined. >> > >I'm still confused. If a packet arrives on a site-enabled interface, >addressed to multicast address AllSPFRouters, and with protocol number >89 (OSPF), to which process is it delivered? Does something actually >peek inside the packet to see if it's advertising global or site-local >addresses when making the dispatching decision? "2.4. Explicit support for multiple instances per link" in RFC2740 is the one to be used to identify a process (instance) to which packet are delivered. Not necessary to peek into LSAs for the dispatching decision. Hiroki Ishibashi bashi@ipv6.nec.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jun 9 22:48:18 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5A5mHk7005725; Sun, 9 Jun 2002 22:48:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5A5mH64005724; Sun, 9 Jun 2002 22:48:17 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5A5mEk7005717 for ; Sun, 9 Jun 2002 22:48:14 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA19031 for ; Sun, 9 Jun 2002 22:48:18 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA13779 for ; Sun, 9 Jun 2002 23:48:17 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g5A5m4I06147; Mon, 10 Jun 2002 08:48:11 +0300 Date: Mon, 10 Jun 2002 08:48:04 +0300 (EEST) From: Pekka Savola To: Michel Py cc: Margaret Wasserman , Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols In-Reply-To: <2B81403386729140A3A899A8B39B046405E0E8@server2000.arneill-py.sacramento.ca.us> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sun, 9 Jun 2002, Michel Py wrote: > IPv4 / RFC1918 : > ---------------- > - The network has a stateful firewall and uses NAT. > - There is a web server with a public IP address in the DFZ. > - There is a database server with an RFC 1918 address in the inside. > - The web server needs to access the database server. > - There is a hole in the firewall to let the web server access > the database server. > - There is a backdoor in the database server. (1) > - The hacker wants the contents of the database and knows about > the backdoor. > > How many things are necessary for the hacker to do in order to access > the data? One: compromise the firewall. The hacker opens another hole in > the firewall to allow backdoor access and creates a static NAT mapping > and voila, data is gone. You take one approach and disregard all the others. The most common way by far, I think, is to compromise the web server and access the database server from there. > How many things are necessary for the hacker to do in order to access > the data? _more_ than one. Assuming web server is compromised, exactly one. > If the hacker compromises the firewall and opens another hole in the > firewall to allow backdoor access, it is not enough because the hacker's > host does not have a route to the database server's site-local address. 1) Just wait for NATv6 if this practise becomes common enough. 2) Use Routing Header to bounce off from a router with both site-local and global address (or site-local routes). Security is about finding the weakest links and strenghtening them. You just looked at only one of them here.. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jun 9 23:00:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5A60lk7005762; Sun, 9 Jun 2002 23:00:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5A60lvQ005761; Sun, 9 Jun 2002 23:00:47 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5A60ik7005754 for ; Sun, 9 Jun 2002 23:00:44 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA02344 for ; Sun, 9 Jun 2002 23:00:48 -0700 (PDT) Received: from tndh.net (evrtwa1-ar8-4-65-028-011.evrtwa1.dsl-verizon.net [4.65.28.11]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA17015 for ; Mon, 10 Jun 2002 00:00:47 -0600 (MDT) Received: from eagleswings (127.0.0.1) by localhost (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Sun, 09 Jun 2002 23:01:26 -0700 From: "Tony Hain" To: "Steven M. Bellovin" Cc: "Pekka Savola" , "Ralph Droms" , Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols Date: Sun, 9 Jun 2002 23:00:13 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20020610023114.C7ED07B4B@berkshire.research.att.com> X-Mimeole: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steven M. Bellovin wrote: > In message , > "Tony Hain" writes > : > > > > > >While I am all for avoiding architectural and operational > pain, I don't > >see this is as big a deal as the thread seems to be making > it out to be. > >There is no need for fixing the IGPs to deal with SiteLocal > as they run > >within the context of the site, therefore shouldn't know > about any other > >sites. Implementations where a given router will have an interface in > >multiple sites will need a way to tag and keep each IGP isolated. The > >simplest way is to track which interface the IGP message > comes in on and > >make sure it maps to the corresponding IGP process. > > > >I think most of this thread is focused on what are simply > implementation > >details, not an issue for the standards per se. The biggest > issue I saw > >was related to DNS returning SL or not, and this is not an > issue as long > >as the DNS server is not expected to deal with multiple > sites. As long > >as routing is filtering SL at the borders, the only way a DNS query > >would get to the SL of the DNS server would be within a site, and the > >only reason a DNS server should return an SL address is if > the query was > >addressed to its SL address. Maybe this needs to be stated clearly in > >the ngtrans doc on DNS issues, but this should be obvious from the > >perspective of 'don't return an answer that can't be used'. > > > >What this means is that an SP will not provide SL addresses for > >customers. This is not a problem today, unless an SP DNS is > resolving to > >RFC1918 addresses. > > The problem is that the definition of "site" you assume above doesn't > match the RFCs, which are deliberately vague. If it were AS-local or > organization-local addresses, I'd be much less concerned. But it's > site-local, which is not the same thing. Quoting > draft-ietf-ipngwg-scoping-arch-03.txt: > > A "site" is, by intent, not > rigorously defined, but is typically expected to cover a > region of topology that belongs to a single organization > and is located within a single geographic location, such > as an office, an office complex, or a campus. > > For a multi-site company, that's smaller than an AS. As I noted > earlier, DNS servers are supposed to be distributed across multiple > sites, and a remote one doesn't know whether or not a querier > is in the > same site as the destination. Maybe a DNS server could look > to see if > the querying address is site-local, but that implies site-local > addresses (indirectly) in NS records. It also implies that > even within > a site, a host will sometimes get the site-local address of the > destination and sometimes the global address, depending on which DNS > server it happened to query. This strikes me as seriously > ugly. And, > as Allison has pointed out, it's not at all clear that we've worked > through all the cases for caching servers or mobile IP. > THere is a mismatch between the DNS perception of 'site' and the site-local definition of 'site'. The DNS version is much stricter about physical separation, but there shouldn't be a requirement that DNS servers for a segment of an AS have to be in differrent SL regions. It sounds like there is more to do on the DNS operations document... In any case, the only way a DNS server should return a SL in a response is if the query was received on a SL. This is the only reasonable way for the server to know if the answer is usable. If the DNS servers for a given set of hosts are split across multiple SL zones, then some of the answers will be global. This is logically the right thing to do from the DNS query/response perspective, but from the operations perspective, the servers shouldn't be in separate SL zones. If a particular network doesn't want to add to the DNS infrastructure, there is no requirement to populate it with SL addresses. If the routers don't announce them in the RA, and they aren't in the DNS, they don't get used. That does not mean we should get rid of them, because smaller organizations will typically find them useful to minimize the impact of changing providers. Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jun 9 23:52:51 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5A6qpk7005831; Sun, 9 Jun 2002 23:52:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5A6qpDp005830; Sun, 9 Jun 2002 23:52:51 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5A6qlk7005823 for ; Sun, 9 Jun 2002 23:52:47 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA27684 for ; Sun, 9 Jun 2002 23:52:49 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA12214 for ; Sun, 9 Jun 2002 23:52:47 -0700 (PDT) Received: from localhost ([3ffe:501:4819:2000:200:39ff:fed9:21d7]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g5A6qf866572; Mon, 10 Jun 2002 15:52:41 +0900 (JST) Date: Mon, 10 Jun 2002 15:52:41 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Margaret Wasserman Cc: Brian Haberman , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-Reply-To: <4.2.2.20020609185002.019fcc50@mail.windriver.com> References: <4.2.2.20020605134805.0245def0@mail.windriver.com> <3D036720.7B02E8E8@nc.rr.com> <4.2.2.20020609185002.019fcc50@mail.windriver.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 24 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Sun, 09 Jun 2002 18:56:11 -0400, >>>>> Margaret Wasserman said: > I'm also concerned about the complexity that site-local addressing > adds to an IPv6 host. Looking at the default address selection rules, > it appears that host implementations will be impacted by site-local > addressing (implementation size and complexity), even in cases > where it isn't really used. Regarding the default address selection rules, I don't think site-local adds much stuff. We also need to handle link-local in the selection rules, which could impact the host implementations enough. In fact, in our implementation of the address selection, there is only few additional code that is specific to site-local. If the host implementation is *completely* unconscious of scoped addresses (which would be the case for some "minimal" implementation), it will be able to reduce much on the size and complexity. 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 Mon Jun 10 00:32:38 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5A7Wbk7005926; Mon, 10 Jun 2002 00:32:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5A7Wblq005925; Mon, 10 Jun 2002 00:32:37 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5A7WYk7005918 for ; Mon, 10 Jun 2002 00:32:34 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA03134 for ; Mon, 10 Jun 2002 00:32:02 -0700 (PDT) Received: from web12805.mail.yahoo.com (web12805.mail.yahoo.com [216.136.174.40]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id BAB05316 for ; Mon, 10 Jun 2002 01:32:01 -0600 (MDT) Message-ID: <20020610073201.74038.qmail@web12805.mail.yahoo.com> Received: from [203.129.237.108] by web12805.mail.yahoo.com via HTTP; Mon, 10 Jun 2002 00:32:01 PDT Date: Mon, 10 Jun 2002 00:32:01 -0700 (PDT) From: Merchant Rizwan Subject: Link Local address. To: ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Friends, I am new to IPv6 and while reading through RFC 2373 found that "Link-Local Address" are mandatory for IPv6 host and routers. Can any one give me some information why is it mandatory to have a link local address in addition to "Assigned Unicast Addresses" for an interface. Thanking you in advance. Best Regards. Rizwan Merchant. __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 10 01:07:51 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5A87pk7006025; Mon, 10 Jun 2002 01:07:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5A87oYN006024; Mon, 10 Jun 2002 01:07:50 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5A87kk7006017 for ; Mon, 10 Jun 2002 01:07:46 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA10404 for ; Mon, 10 Jun 2002 01:07:45 -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 CAA18543 for ; Mon, 10 Jun 2002 02:07:43 -0600 (MDT) Received: from localhost ([3ffe:501:4819:2000:200:39ff:fed9:21d7]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g5A87I867891; Mon, 10 Jun 2002 17:07:18 +0900 (JST) Date: Mon, 10 Jun 2002 17:07:18 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: mankin@isi.edu Cc: "Tony Hain" , "Steven M. Bellovin" , "Pekka Savola" , "Ralph Droms" , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-Reply-To: <200206092349.g59NnYL11121@minotaur.nge.isi.edu> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. References: <200206092349.g59NnYL11121@minotaur.nge.isi.edu> MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 28 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Sun, 09 Jun 2002 19:49:34 -0400, >>>>> Allison Mankin said: >> and the >> only reason a DNS server should return an SL address is if the query was >> addressed to its SL address. Maybe this needs to be stated clearly in >> the ngtrans doc on DNS issues, but this should be obvious from the >> perspective of 'don't return an answer that can't be used'. > I would question whether this is well-understood and DNS servers > are ready to select which AAAA records to reply with depending > on the address the query was sent to. Do current servers implement > this, including caching servers? BIND 9 servers could do this in the sense that they can change a zone in question based on the query's destination, but I don't think this feature handles the case in this thread. Anyway, I don't think the issue about site-local addresses and DNS is that simple. The point is that DNS is a global database while the notion of scoped addresses is not global (there is nothing new about the gap, though. this should have been discussed many times in the context of IPv4 private addresses and DNS). 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 Mon Jun 10 01:55:38 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5A8tck7006109; Mon, 10 Jun 2002 01:55:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5A8tcn5006108; Mon, 10 Jun 2002 01:55:38 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5A8tYk7006101 for ; Mon, 10 Jun 2002 01:55:35 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA15531 for ; Mon, 10 Jun 2002 01:55:38 -0700 (PDT) Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.211]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA24554 for ; Mon, 10 Jun 2002 01:55:37 -0700 (PDT) Received: from tarski.cs.uni-bonn.de (tarski.cs.uni-bonn.de [131.220.4.200]) by theory.cs.uni-bonn.de (8.9.1a/8.9.1) with ESMTP id KAA13134 for ; Mon, 10 Jun 2002 10:55:36 +0200 (MET DST) Received: (from ignatios@localhost) by tarski.cs.uni-bonn.de (8.9.1a/8.9.1) id KAA17473 for ipng@sunroof.eng.sun.com; Mon, 10 Jun 2002 10:55:01 +0200 (CEST) Date: Mon, 10 Jun 2002 10:55:01 +0200 From: Ignatios Souvatzis Cc: ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols Message-ID: <20020610105501.E17133@tarski.cs.uni-bonn.de> References: <2B81403386729140A3A899A8B39B046405E0E1@server2000.arneill-py.sacramento.ca.us> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="TakKZr9L6Hm6aLOc" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <2B81403386729140A3A899A8B39B046405E0E1@server2000.arneill-py.sacramento.ca.us>; from michel@arneill-py.sacramento.ca.us on Sat, Jun 08, 2002 at 06:38:22PM -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --TakKZr9L6Hm6aLOc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jun 08, 2002 at 06:38:22PM -0700, Michel Py wrote: > - With an RFC 1918 host behind a firewall, compromising the firewall is > enough to grant that host outside access. Single point of failure. >=20 > - With a site-local only host behind a firewall, this become a double > hack thing: you need to reconfigure the firewall _and_ reconfigure the > host to give it a public IP. >=20 > Let's look at the following situation: The hacker can reconfigure the > firewall and is using an OS vulnerability that allows him to read data > from the hosts but not to reconfigure it. virtually all 1918 "firewalls" I've experienced are at least capable, most also configured to do NAT. Having NAT at the border of your firewall allows Joe E. Hacker to get access to the internal machines by using pre-existing border router capabilities. I see no difference to the "public addresses and configured firewall" scenario here - only that it slightly more difficult to set up and maintain, thus slightly more easy to misconfigure. Oh, and it breaks lots of existing and future protocols for machines that need access to the outside - or requires to put specialized active code for each of them at the border. Now, if you're talking about a firewall with internal 1918 addressing=20 that does NOT do IPNAT, I admit you're right. However, in that case, it=20 is easier to leave the cables disconnected, isn't it? Ok, there might be a third class of machines besides "inside, noaccess", and "outside" - "inside, global address, access to outside, but need access to inside". In this case, Joe E. Hacker will attack one of the third class machines to get access to the "secure" inside machines. Single point of failure again, possibly multiple parallel instances of it. Regards, -is --TakKZr9L6Hm6aLOc Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: 2.6.i iQEVAgUBPQRpYjCn4om+4LhpAQGZ/gf/bwBiIaF2tepYx793rH33Z536SedjN+0y saoogWkYWemkvy0xR3io3yjniUHZ3o/wLCz/pxPDIp8D5CseXy93EtccTCgaZzVo Q79Xh3NvZkk9vIRqPRoSLvaCIr9KtNSJ2ML0k0zJUSMn51eW/lM3nfEqwl6wpCat WwNMnvlM+uO8rbMRXGssufj/FyhS+DNrkKua7yOAKCoeB/5u8qgolzoR6Oq63eu6 jZa/LB3y3ZQT82sImVhkKbd0i0XX4cHML0ScXwuDF95SE8nh287voMk71pC1cb9d jJQ4h5qBhDCaEymP1DOKhOvJA3EqRAqMKFwAUcA9WPlgWgFa0Pl8zw== =DPpw -----END PGP SIGNATURE----- --TakKZr9L6Hm6aLOc-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 10 02:14:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5A9Emk7006175; Mon, 10 Jun 2002 02:14:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5A9EmOY006174; Mon, 10 Jun 2002 02:14:48 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5A9Ejk7006167 for ; Mon, 10 Jun 2002 02:14:45 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA18412 for ; Mon, 10 Jun 2002 02:14:49 -0700 (PDT) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA02525 for ; Mon, 10 Jun 2002 02:14:48 -0700 (PDT) content-class: urn:content-classes:message Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 10 Jun 2002 02:14:46 -0700 Message-ID: <2B81403386729140A3A899A8B39B046406C7F0@server2000.arneill-py.sacramento.ca.us> X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 X-MS-TNEF-Correlator: Thread-Topic: Fwd: IPv6 Scoped Addresses and Routing Protocols Thread-Index: AcIQQosnTvhJHxOvQnW4Eo4GaliiFgAHLUfg From: "Michel Py" To: "Pekka Savola" Cc: "Margaret Wasserman" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5A9Ejk7006168 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Pekka Savola wrote > You take one approach and disregard all the others. I don't. I just say that in this scenario site-local address helps. What is the hacker knows the backdoor because he installed it himself and cannot compromise the web server? Your argument is irrelevant. > Security is about finding the weakest links and strengthening them. > You just looked at only one of them here.. Security is about plugging holes. There are hundreds to plug. Saying that plugging a hole is useless because some other holes might be open is the best way to get hacked. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 10 02:22:21 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5A9MKk7006204; Mon, 10 Jun 2002 02:22:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5A9MKij006203; Mon, 10 Jun 2002 02:22:20 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5A9MHk7006196 for ; Mon, 10 Jun 2002 02:22:17 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA25584 for ; Mon, 10 Jun 2002 02:22:21 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA28753 for ; Mon, 10 Jun 2002 03:23:53 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g5A9MJG07946 for ; Mon, 10 Jun 2002 12:22:19 +0300 Date: Mon, 10 Jun 2002 12:22:18 +0300 (EEST) From: Pekka Savola To: ipng@sunroof.eng.sun.com Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols In-Reply-To: <2B81403386729140A3A899A8B39B046406C7F0@server2000.arneill-py.sacramento.ca.us> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 10 Jun 2002, Michel Py wrote: > > Pekka Savola wrote > > You take one approach and disregard all the others. > > I don't. I just say that in this scenario site-local address helps. What > is the hacker knows the backdoor because he installed it himself and > cannot compromise the web server? Your argument is irrelevant. > > > Security is about finding the weakest links and strengthening them. > > You just looked at only one of them here.. > > Security is about plugging holes. There are hundreds to plug. Saying > that plugging a hole is useless because some other holes might be open > is the best way to get hacked. If hacking into the firewall to install a static NAT mapping is the easiest (or one of the easiest) way to break into a system, something is REALLY REALLY wrong IMO. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 10 02:22:43 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5A9Mgk7006214; Mon, 10 Jun 2002 02:22:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5A9MgI3006213; Mon, 10 Jun 2002 02:22:42 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5A9Mck7006206 for ; Mon, 10 Jun 2002 02:22:38 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA25630 for ; Mon, 10 Jun 2002 02:22:41 -0700 (PDT) Received: from delta.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA11882 for ; Mon, 10 Jun 2002 03:22:39 -0600 (MDT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g5A9ARn05734; Mon, 10 Jun 2002 16:10:32 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Pekka Savola cc: Ralph Droms , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 10 Jun 2002 16:10:27 +0700 Message-ID: <5732.1023700227@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Sun, 9 Jun 2002 14:54:33 +0300 (EEST) From: Pekka Savola Message-ID: | Me neither. More probable outcome is that someone starts to request that | people implement NATv6, because 1) they're already used to it (and like | its "security") in v4 world, This is bogus - but then again we see here over and over where people are only happy when nothing changes (and we're seeing it again here). | and 2) they think it's easier for them to do NAT than to renumber. And they're right. And that's what site locals are good at - their main function in my mind. If site local addresses were used for all internal communications (whatever "internal" is defined to be), and globals only for external communications, then renumbering IPv6 becomes close to isomorphic to renumbering IPv4 using NAT - all the nodes need to be renumbered, but with IPv6 that's close to automatic, so not much of an issue. All internal communications are unaffected, as they're using site local (just like 1918 addresses in v4 with NAT), and all external communications are disrupted, because the global address has changed (just like IPv4 with NAT). | Site-locals were born in the era that not all sites had internet | connectivity. That was one of their planned uses, in my mind, always a minor one. | It's | just easier for people to use a global address block (even if we define | that address block to be 3ffe:eff3::/32 or whatever) even with these | "internal needs" (note: I believe there should be _something_ that does | not require you to fill any kind of paperwork). Huh? What difference do you think that would make? We just define fec0::/10 as a "global" address block, and we're done according to this theory. That's absurd - the bit pattern used can't possibly be relevant. What matters is whether or not there is some block of addresses that can be arbitrarily simply "taken" and assigned for local use, and which won't work for communication that isn't local (whatever definition of local has been chosen to apply). If there is, then all the same issues remain - how to discover the address, how to decide when to use it, how to prevent it leaking where it shouldn't, etc - none of which is in the slightest impacted by the bit pattern chosen. And on this, Steve Bellovin went on to suggest ... | Yah. Let's pick a prefix, and tell folks to pick a random number | (more precisely, use an RFC 1750-compatible RNG) to fill out the rest | of the high-order bits to a /48 or a /64. So, let the prefix be fec0::/10 and then when you have just suggested is Paul Francis' NUSLA's - see the thread from Feb 2001 with the illumination Subject of "Wade through the archives" (and perhaps also the threads on "Question on scopes involving IPv6 addresses" and "what is a site??" from March '01). This stuff seemed to just drift into silence, without any real discussion, which it really deserved having. 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 Jun 10 02:39:03 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5A9d3k7006291; Mon, 10 Jun 2002 02:39:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5A9d25T006290; Mon, 10 Jun 2002 02:39:02 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5A9cxk7006283 for ; Mon, 10 Jun 2002 02:38:59 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA05314 for ; Mon, 10 Jun 2002 02:39:03 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA12646 for ; Mon, 10 Jun 2002 02:39:02 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g5A9YCi22311; Mon, 10 Jun 2002 11:35:04 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id LAA03213; Mon, 10 Jun 2002 11:34:12 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g5A9Y7T95196; Mon, 10 Jun 2002 11:34:11 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200206100934.g5A9Y7T95196@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: itojun@iijlab.net cc: Margaret Wasserman , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-reply-to: Your message of Thu, 06 Jun 2002 07:22:10 +0900. <21624.1023315730@itojun.org> Date: Mon, 10 Jun 2002 11:34:07 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: in my opinion, site border routers need to have ability to run separate entity of RIP/OSPFv3/IS-IS for each site (don't mix them up). there's no need for protocol modification, since there will be no interaction between routes in site A and site B. => I fully agree : this is the key point. And we already have the answer for RIP (no) and OSPFv3 (yes). NEC IX router is the only implementation supporting this, as far as i know (i'm a bit embarrassed, KAME doesn't handle this - yet). => perhaps because you think (like me) that to use site-local addresses for a connected organization is not a good idea. But we know we won't get a consensus about this point so considering (mainly on the paper :-) multi-sited routers is not so absurd... Thanks Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 10 02:40:28 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5A9eSk7006308; Mon, 10 Jun 2002 02:40:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5A9eRiu006307; Mon, 10 Jun 2002 02:40:27 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5A9eOk7006300 for ; Mon, 10 Jun 2002 02:40:24 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA04473 for ; Mon, 10 Jun 2002 02:40:27 -0700 (PDT) Received: from delta.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA09636 for ; Mon, 10 Jun 2002 03:40:26 -0600 (MDT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g5A9Jfn05748; Mon, 10 Jun 2002 16:21:02 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: mankin@isi.edu cc: ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-Reply-To: <200206092349.g59NnYL11121@minotaur.nge.isi.edu> References: <200206092349.g59NnYL11121@minotaur.nge.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 10 Jun 2002 16:19:41 +0700 Message-ID: <5746.1023700781@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Sun, 09 Jun 2002 19:49:34 -0400 From: Allison Mankin Message-ID: <200206092349.g59NnYL11121@minotaur.nge.isi.edu> | I would question whether this is well-understood and DNS servers | are ready to select which AAAA records to reply with depending | on the address the query was sent to. Do current servers implement | this, including caching servers? It is much worse than that - just imagine a DNS server running on a site border router (which is much more likely in some environments than others - but in those ones, it is quite plausible). How such a server figures out which particular site local AAAA records it should forward into which site, even assuming that the DNS server is actually taught about sites, is mind blowing. This all could be kind of managed if Paul Francis' NUSLA proposal were adopted (see the message I just sent) but without that, I thought that we had pretty much concluded ages ago that putting site local addresses in the DNS (other than for people using site locals for the purpose of running a disconnected net, where those are the only addresses that exist) was a total write off as an idea. Sure it can be made to work in particular cases with special care (just as sticking 1918 addresses in the DNS can be coerced into working) - but it isn't something that anyone rational would ever actually suggest as SOP. What we need is a way to decide when to use site local addresses, and to discover what the appropriate address is, that does not use the DNS. I think that's entirely possible, and certainly don't believe that the current lack of a specification for how to do it warrants discarding site local from the architecture (though it probably warrants suggesting extreme caution in their use for now). kre ps: Aside: note we have no process problem advancing the specs we have with site local remaining in them - we have enough implementations of site local, which work as much as the spec says they should work, which isn't very much, for the specs to be able to advance as they are. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 10 02:44:32 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5A9iWk7006356; Mon, 10 Jun 2002 02:44:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5A9iV6e006355; Mon, 10 Jun 2002 02:44:31 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5A9iSk7006348 for ; Mon, 10 Jun 2002 02:44:28 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA05985 for ; Mon, 10 Jun 2002 02:44:32 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA09158 for ; Mon, 10 Jun 2002 03:46:04 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g5A9gA608150; Mon, 10 Jun 2002 12:42:10 +0300 Date: Mon, 10 Jun 2002 12:42:10 +0300 (EEST) From: Pekka Savola To: Robert Elz cc: Ralph Droms , Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-Reply-To: <5732.1023700227@munnari.OZ.AU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 10 Jun 2002, Robert Elz wrote: > | It's > | just easier for people to use a global address block (even if we define > | that address block to be 3ffe:eff3::/32 or whatever) even with these > | "internal needs" (note: I believe there should be _something_ that does > | not require you to fill any kind of paperwork). > > Huh? What difference do you think that would make? We just define > fec0::/10 as a "global" address block, and we're done according to this > theory. That's absurd - the bit pattern used can't possibly be relevant. > What matters is whether or not there is some block of addresses that can > be arbitrarily simply "taken" and assigned for local use, and which won't > work for communication that isn't local (whatever definition of local has > been chosen to apply). > > If there is, then all the same issues remain - how to discover the address, > how to decide when to use it, how to prevent it leaking where it shouldn't, > etc - none of which is in the slightest impacted by the bit pattern chosen. Bit pattern is not relevant of course (except how it is handled by "legacy" implementations, which is why I tossed 3ffe:eff3::/32 in the air). What I'd like is that there wouldn't need to be special handling for site-local addresses. If you really wanted to have Site Border Routers, you would just be shooting in your own foot (like with 10.0.0.0/8 etc. today). Implementation (and specification) simplicity.. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 10 02:45:42 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5A9jfk7006398; Mon, 10 Jun 2002 02:45:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5A9jfFl006397; Mon, 10 Jun 2002 02:45:41 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5A9jck7006390 for ; Mon, 10 Jun 2002 02:45:38 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA22770 for ; Mon, 10 Jun 2002 02:45:38 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA23132 for ; Mon, 10 Jun 2002 03:45:37 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g5A9jUi24111; Mon, 10 Jun 2002 11:45:30 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id LAA03334; Mon, 10 Jun 2002 11:45:30 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g5A9jQT95268; Mon, 10 Jun 2002 11:45:29 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200206100945.g5A9jQT95268@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Steven M. Bellovin" cc: ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-reply-to: Your message of Thu, 06 Jun 2002 13:36:28 EDT. <20020606173628.3E1DE7B4B@berkshire.research.att.com> Date: Mon, 10 Jun 2002 11:45:26 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: My strong preference would be to drop site-local addresses completely. I think they're an administrative and technical nightmare. => many of us share your opinion but the other side has enough people to make a consensus unlikely... Margaret has pointed out that our routing protocols don't support site-local addresses. The only alternative suggestion I've seen thus far is to run multiple instances of, say, OSPF on all routers within a site. But how are these distinguished from each other? => using the fact an interface belongs only to one site. OSPFv3 has an explicite provision for multi-instance per router (the idea was to make OSPF available on DMZs) so someone can shoot in his foot (oops, can run multiple OSPF processes on a multi-sited router). I'm very concerned about DNS entries. When should a DNS server -- or a caching resolver -- return a site-local address? (If the DNS never returns such things, they're useless.) One suggestion I've heard is two-faced DNS servers -- only return site-local information if the querier is within the same site. => yes, the basic answer is the two-headed devil... RFC 2182 (aka BCP 0016) specifically warns against putting all secondary servers for a zone within a site: => this obviously doesn't apply in this way for scoped names/addresses. Philosophically, I think that the problem is that a "site" is a new (and deliberately poorly defined) concept. => I propose to reserve the "what is a site?" question to Steve Deering (:-). Thanks Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 10 02:56:16 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5A9uFk7006467; Mon, 10 Jun 2002 02:56:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5A9uFGl006466; Mon, 10 Jun 2002 02:56:15 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5A9uCk7006459 for ; Mon, 10 Jun 2002 02:56:12 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA07546 for ; Mon, 10 Jun 2002 02:56:16 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA19441 for ; Mon, 10 Jun 2002 02:56:15 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g5A9tSi26554; Mon, 10 Jun 2002 11:55:38 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id LAA03503; Mon, 10 Jun 2002 11:55:28 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g5A9tKT95351; Mon, 10 Jun 2002 11:55:20 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200206100955.g5A9tKT95351@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: itojun@iijlab.net cc: Keith Moore , aditya@grot.org (R.P. Aditya), ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-reply-to: Your message of Sat, 08 Jun 2002 02:09:33 +0900. <9155.1023469773@itojun.org> Date: Mon, 10 Jun 2002 11:55:20 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: as long as the applications are properly implemented with sockaddrs, they are okay. the problem reside in protocols that pass IPv6 addresses in payloads (since view of the scope is different by nodes), including: - FTP (EPSV/EPRT does not help - for instance, how do you decide the scope zone for data connection?) - DNS (AAAA/PTR does not represent scope correctly) => add IKE in this list (with an additional security issue too). - and all NAT-unfriendly protocols => as I proved in a not-yet published draft, for some protocols to be NAT-friendly introduce a nasty vulnerability... I'm okay to see site-local IPv6 address to go away, however, I'm worried because there are more than a couple of protocols designed with site-local IPv6 address in mind (DHCPv6, router renumbering, ...). => this is a design error and the last meeting discussion about where are the site boundaries for a dialup connection showed where is the problem. we need to keep link-local IPv6 address at least for ND. use of link-locals within zeroconf environment needs further study. => I am not against scoped addresses in zeroconf environment where they use only one zone, i.e. link-locals with only one link, or site-locals with only one (disconnected) site... Thanks Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 10 03:49:14 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5AAnEk7006566; Mon, 10 Jun 2002 03:49:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5AAnDKq006560; Mon, 10 Jun 2002 03:49:13 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5AAn9k7006551 for ; Mon, 10 Jun 2002 03:49:09 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA01479 for ; Mon, 10 Jun 2002 03:49:12 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA05473 for ; Mon, 10 Jun 2002 04:50:45 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g5AAB6i28311; Mon, 10 Jun 2002 12:11:06 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id MAA03720; Mon, 10 Jun 2002 12:11:06 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g5AAAhT95472; Mon, 10 Jun 2002 12:10:47 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200206101010.g5AAAhT95472@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pekka Savola cc: Bill Sommerfeld , Michel Py , Bob Hinden , "Steven M. Bellovin" , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-reply-to: Your message of Sun, 09 Jun 2002 09:04:52 +0300. Date: Mon, 10 Jun 2002 12:10:43 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Well, addr-arch states that routers MUST drop traffic with site-local source address at the edge of a site. => yes, there is a new ICMP error for this case. But as site is rather vaguely defined, I think many vendors just skip this little detail.. => I disagree: we have a similar but more complex issue for multicast forwarding and the zone boundary check is very easy to implement (this point was verified when the multicast addressing stuff was advanced). If this is the only hard point in a multi-sited implementation I (and many of us) will be *very* happy (:-)! Thanks Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 10 03:53:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5AArdk7006596; Mon, 10 Jun 2002 03:53:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5AArdY3006595; Mon, 10 Jun 2002 03:53:39 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5AArak7006588 for ; Mon, 10 Jun 2002 03:53:36 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA01845 for ; Mon, 10 Jun 2002 03:53:38 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA07261 for ; Mon, 10 Jun 2002 04:55:11 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g5AAMti28974; Mon, 10 Jun 2002 12:24:40 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id MAA03777; Mon, 10 Jun 2002 12:22:55 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g5AAMsT95537; Mon, 10 Jun 2002 12:22:54 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200206101022.g5AAMsT95537@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Brian Haberman cc: Margaret Wasserman , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-reply-to: Your message of Sun, 09 Jun 2002 10:33:05 EDT. <3D036720.7B02E8E8@nc.rr.com> Date: Mon, 10 Jun 2002 12:22:54 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: 1. The RIB now contains an additional field, the zone ID. I have done this in two different ways. The first is to add the zone ID as a separate field. The second is to embed the zone ID in the "unused" portion of the site local prefix. => please put a warning in front of your message where there is nasty idea like the "second way". It is lunch time and I shan't be enable to eat something now... Regards Francis.Dupont@enst-bretagne.fr PS: to put a random thing in the unused part of site-locals was proposed twice and rejected twice... -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 10 04:06:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5AB6jk7006627; Mon, 10 Jun 2002 04:06:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5AB6j02006626; Mon, 10 Jun 2002 04:06:45 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5AB6gk7006619 for ; Mon, 10 Jun 2002 04:06:42 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA18228 for ; Mon, 10 Jun 2002 04:06:41 -0700 (PDT) Received: from roam.psg.com (dhcp3202.nanog25.merit.net [192.35.167.202]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA21759 for ; Mon, 10 Jun 2002 05:06:40 -0600 (MDT) Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.04) id 17HN0R-00016S-00; Mon, 10 Jun 2002 04:06:39 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Francis Dupont Cc: "Steven M. Bellovin" , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols References: <200206101010.g5AAAhT95472@givry.rennes.enst-bretagne.fr> Message-Id: Date: Mon, 10 Jun 2002 04:06:39 -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> But as site is rather vaguely defined, I think many vendors just skip >> this little detail.. > I disagree: we have a similar but more complex issue for multicast > forwarding and the zone boundary check is very easy to implement cool. how do you detect that you are at the edge of a site? randy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 10 04:17:23 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5ABHNk7006703; Mon, 10 Jun 2002 04:17:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5ABHM6i006702; Mon, 10 Jun 2002 04:17:22 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5ABHHk7006695 for ; Mon, 10 Jun 2002 04:17:17 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA19483 for ; Mon, 10 Jun 2002 04:17:20 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA18657 for ; Mon, 10 Jun 2002 05:17:19 -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 HAA28221; Mon, 10 Jun 2002 07:16:41 -0400 (EDT) Message-Id: <200206101116.HAA28221@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-ipv6-cellular-host-03.txt Date: Mon, 10 Jun 2002 07:16: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 IP Version 6 Working Group Working Group of the IETF. Title : IPv6 for Some Second and Third Generation Cellular Hosts Author(s) : J. Arkko et al. Filename : draft-ietf-ipv6-cellular-host-03.txt Pages : 20 Date : 07-Jun-02 As the deployment of second and third generation cellular networks progresses, a large number of cellular hosts are being connected to the Internet. Standardization organizations are making IPv6 mandatory in their specifications. However, the concept of IPv6 covers many aspects and numerous specifications. In addition, the characteristics of cellular links in terms of bandwidth, cost and delay put special requirements on how IPv6 is used. This document considers IPv6 for cellular hosts that attach to the General Packet Radio Service (GPRS), or Universal Mobile Telecommunications System (UMTS) networks. The document lists basic components of IPv6 functionality and discusses some issues relating to the use of these components when operating in these networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-cellular-host-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipv6-cellular-host-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipv6-cellular-host-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020607133049.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-cellular-host-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-cellular-host-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020607133049.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 Jun 10 04:41:18 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5ABfIk7006868; Mon, 10 Jun 2002 04:41:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5ABfIqL006867; Mon, 10 Jun 2002 04:41:18 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5ABfFk7006860 for ; Mon, 10 Jun 2002 04:41:15 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA22871 for ; Mon, 10 Jun 2002 04:41:18 -0700 (PDT) Received: from delta.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA29433 for ; Mon, 10 Jun 2002 04:41:09 -0700 (PDT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g5ABZVn06353; Mon, 10 Jun 2002 18:35:31 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Pekka Savola cc: Ralph Droms , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 10 Jun 2002 18:35:31 +0700 Message-ID: <6351.1023708931@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 10 Jun 2002 12:42:10 +0300 (EEST) From: Pekka Savola Message-ID: | Bit pattern is not relevant of course (except how it is handled by | "legacy" implementations, which is why I tossed 3ffe:eff3::/32 in the | air). But how is the handling by legacy implementations any different than what you would require anyway? | What I'd like is that there wouldn't need to be special handling for | site-local addresses. How can there not be? | If you really wanted to have Site Border Routers, | you would just be shooting in your own foot (like with 10.0.0.0/8 etc. | today). If there are to be uses of non-unique addressing (site locals, 1918's or anything else) then there has to be borders. And if there are borders, then there has to be border routers. Something has to keep one use of the addresses separate from others. Perhaps what you want to discourage is multi-site nodes ? (Usually would be a router, but doesn't have to be). As I recall, when site locals were first discussed, there were 3 possibilities for how the border between one site and other would be handled. One was to have only single site nodes, but allow links to be in multiple sites. That doesn't work at all with the current packet/addressing formats, as there's no way to tell on the wire which site a packet would belong to, so that one's just a write off. Two was to have only single site nodes, only single site links, and non-site links (DMZs) between sites. Three is what we have now - single site links, and multi-site nodes. This was all debated and settled so long ago, I've even forgotten which of the two (feasible) proposals I supported, though I suspect it was probably the one called "two" above. Which is what you're also probably really suggesting here. However, upon reflection, there is comparatively little to be gained by that choice over the third one (some things get simpler to explain while the lack of regularity makes others harder to fathom, and some stuff becomes simply impossible to manage - like if two sites are connected via a router that has LANS for each site connected to it, there's no convenient link to make be the DMZ). Scoping has to exist for link locals to work anyway, and so routers need to deal with that (and link locals, and their properties, are too deeply ingrained now to possibly contemplate their removal). By their very nature, link locals require multi-scope nodes to exist, or we could not have routers at all. The only real difference between 2 & 3 above for implementations, given that apps can run on "routers" and that apps need to be able to use link local addressing if necessary (for the unconnected dentist's office nets) so all the scoping architecture needs to exist - all that would be gained is that in (2) a router would have a different decision to make before forwarding site local addresses - rather than "is this link in the same site?" it would need to ask "is this link in a DMZ?" Is that (trivial) simplification really worth the loss of flexibility? The difficult part of handing any situation where there are multiple addresses is how to decide which address should get used, initially. This is just the same when a node as two global addresses (whether they're in different prefixes, or the same one) or when it has global & private addresses. In IPv4 we just ignore the question mostly - a node with two global addresses we just toss a coin. And nodes with private addresses mostly just don't get given global addresses (and/or the two are treated for essentially all purposes as if they belonged to two different nodes). For IPv6 we're being asked to actually attempt to provide some answers to this question - as essentially all nodes (certainly the vast majority) with private addresses will also have global ones. 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 Jun 10 04:43:29 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5ABhSk7006893; Mon, 10 Jun 2002 04:43:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5ABhSjY006892; Mon, 10 Jun 2002 04:43:28 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5ABhOk7006885 for ; Mon, 10 Jun 2002 04:43:24 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA23274 for ; Mon, 10 Jun 2002 04:43:27 -0700 (PDT) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA00303 for ; Mon, 10 Jun 2002 04:43:27 -0700 (PDT) Received: from postal.research.att.com (postal.research.att.com [135.207.23.30]) by mail-blue.research.att.com (Postfix) with ESMTP id C4BA54CE5C; Mon, 10 Jun 2002 07:43:21 -0400 (EDT) Received: from berkshire.research.att.com (postal.research.att.com [135.207.23.30]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id HAA13581; Mon, 10 Jun 2002 07:38:04 -0400 (EDT) Received: from research.att.com (localhost [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id F12237B4B; Mon, 10 Jun 2002 07:43:18 -0400 (EDT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: "Steven M. Bellovin" To: Hiroki Ishibashi Cc: ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 10 Jun 2002 07:43:18 -0400 Message-Id: <20020610114319.F12237B4B@berkshire.research.att.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <6EC21033B3E449bashi@ipv6.nec.co.jp>, Hiroki Ishibashi writes: >Steven M. Bellovin wrote: > >>I'm still confused. If a packet arrives on a site-enabled interface, >>addressed to multicast address AllSPFRouters, and with protocol number >>89 (OSPF), to which process is it delivered? Does something actually >>peek inside the packet to see if it's advertising global or site-local >>addresses when making the dispatching decision? > >"2.4. Explicit support for multiple instances per link" in RFC2740 >is the one to be used to identify a process (instance) to which packet >are delivered. Not necessary to peek into LSAs for the dispatching >decision. > I must be missing something; I still don't understand. Let's look at a simple case, a router with two physical interfaces with one attached to the site backbone, and one feeding a departmental LAN. I'm perfectly willing to assume multiple logical interfaces on either physical interface. Let's consider the backbone interface. It's going to be seeing two types of routing advertisement, site-local and global. When an incoming OSPF packet arrives, it's addressed to the same multicast address in either case. To which logical interface does it belong? --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com ("Firewalls" book) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 10 04:53:53 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5ABrqk7006942; Mon, 10 Jun 2002 04:53:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5ABrquv006941; Mon, 10 Jun 2002 04:53:52 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5ABrnk7006934 for ; Mon, 10 Jun 2002 04:53:49 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA24705 for ; Mon, 10 Jun 2002 04:53:52 -0700 (PDT) Received: from delta.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA01858 for ; Mon, 10 Jun 2002 04:53:47 -0700 (PDT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g5ABeFn06369; Mon, 10 Jun 2002 18:40:16 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Francis Dupont cc: Brian Haberman , Margaret Wasserman , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-Reply-To: <200206101022.g5AAMsT95537@givry.rennes.enst-bretagne.fr> References: <200206101022.g5AAMsT95537@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 10 Jun 2002 18:40:15 +0700 Message-ID: <6367.1023709215@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 10 Jun 2002 12:22:54 +0200 From: Francis Dupont Message-ID: <200206101022.g5AAMsT95537@givry.rennes.enst-bretagne.fr> | PS: to put a random thing in the unused part of site-locals was proposed | twice and rejected twice... It was rejected once, when I made it, because it wasn't really a very well thought out proposal (the rejection was largely based upon administrative kinds of issues, rather than anything related to IPv6 as a protocol, etc). The second time, I don't think it was rejected, it just sort of fizzled out, or that's how it appeared to me. I'm pretty sure the draft will have long expired, but I still regard the proposal as open. 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 Jun 10 08:14:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5AFEtk7007361; Mon, 10 Jun 2002 08:14:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5AFEtAd007360; Mon, 10 Jun 2002 08:14:55 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5AFEpk7007353 for ; Mon, 10 Jun 2002 08:14:51 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA06352 for ; Mon, 10 Jun 2002 08:14:54 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA14693 for ; Mon, 10 Jun 2002 09:14:53 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5AFDUn07424; Mon, 10 Jun 2002 11:13:30 -0400 (EDT) Message-Id: <200206101513.g5AFDUn07424@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Tony Hain" cc: "Steven M. Bellovin" , "Pekka Savola" , "Ralph Droms" , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-reply-to: (Your message of "Sun, 09 Jun 2002 23:00:13 PDT.") Date: Mon, 10 Jun 2002 11:13:30 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > In any > case, the only way a DNS server should return a SL in a response is if > the query was received on a SL. This is the only reasonable way for the > server to know if the answer is usable. it doesn't work in general, because the query could be from a cache that doesn't know anything about SL. putting limited-scope addrs in DNS is a Bad Idea, period. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 10 08:18:01 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5AFI0k7007384; Mon, 10 Jun 2002 08:18:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5AFI0kQ007383; Mon, 10 Jun 2002 08:18:00 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5AFHuk7007373 for ; Mon, 10 Jun 2002 08:17:56 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA17666 for ; Mon, 10 Jun 2002 08:17:59 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA21126 for ; Mon, 10 Jun 2002 09:19:32 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5AFGbn07988; Mon, 10 Jun 2002 11:16:37 -0400 (EDT) Message-Id: <200206101516.g5AFGbn07988@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Michel Py" cc: "Pekka Savola" , "Margaret Wasserman" , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-reply-to: (Your message of "Mon, 10 Jun 2002 02:14:46 PDT.") <2B81403386729140A3A899A8B39B046406C7F0@server2000.arneill-py.sacramento.ca.us> Date: Mon, 10 Jun 2002 11:16:37 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Security is about plugging holes. There are hundreds to plug. Saying > that plugging a hole is useless because some other holes might be open > is the best way to get hacked. that's sort of like saying that putting your finger in a crack in the dam is useless because there are probably other cracks. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 10 10:20:54 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5AHKrk7007530; Mon, 10 Jun 2002 10:20:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5AHKr0c007529; Mon, 10 Jun 2002 10:20:53 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5AHKok7007522 for ; Mon, 10 Jun 2002 10:20:50 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA15435 for ; Mon, 10 Jun 2002 10:20:53 -0700 (PDT) From: rbrabson@us.ibm.com Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA09670 for ; Mon, 10 Jun 2002 10:20:52 -0700 (PDT) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.us.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.12.2/8.12.2) with ESMTP id g5AHKpRY047420; Mon, 10 Jun 2002 13:20:51 -0400 Received: from d04nm200.raleigh.ibm.com (d04nm200.raleigh.ibm.com [9.67.226.57]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5AHKp695150; Mon, 10 Jun 2002 13:20:51 -0400 Subject: RE: Multiple Sites and DNS (was IPv6 Scoped Addresses and Routing Protocols) To: "Tony Hain" Cc: ipng@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Mon, 10 Jun 2002 13:20:41 -0400 X-MIMETrack: Serialize by Router on D04NM200/04/M/IBM(Build M13TT_05222002 Pre-release 2|May 22, 2002) at 06/10/2002 13:20:50 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=0ABBE147DFC271828f9e8a93df938690918c0ABBE147DFC27182" Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --0__=0ABBE147DFC271828f9e8a93df938690918c0ABBE147DFC27182 Content-type: text/plain; charset=US-ASCII On Sunday, 06/09/2002 at 11:00 MST, "Tony Hain" wrote: > THere is a mismatch between the DNS perception of 'site' and the > site-local definition of 'site'. The DNS version is much stricter about > physical separation, but there shouldn't be a requirement that DNS > servers for a segment of an AS have to be in differrent SL regions. It > sounds like there is more to do on the DNS operations document... In any > case, the only way a DNS server should return a SL in a response is if > the query was received on a SL. This is the only reasonable way for the > server to know if the answer is usable. If the DNS servers for a given > set of hosts are split across multiple SL zones, then some of the > answers will be global. This is logically the right thing to do from the > DNS query/response perspective, but from the operations perspective, the > servers shouldn't be in separate SL zones. If a particular network > doesn't want to add to the DNS infrastructure, there is no requirement > to populate it with SL addresses. If the routers don't announce them in > the RA, and they aren't in the DNS, they don't get used. That does not > mean we should get rid of them, because smaller organizations will > typically find them useful to minimize the impact of changing providers. The DNS issues surrounding site-local addresses concern me far more than routing issues which have been discussed. I tried to imagine how DNS would work given what is described above, especially for the case where a host is attached to multiple sites. I don't think this is just an operational problem, but requires new standards and new code at both the resolvers as well as name servers in order for it to work. The more I thought about it, the more I liked the idea of site-local addresses disappearing from the architecture or, at a minimum, a host being restricted to connecting to a single site at any given time. Imagine a host (Host1) which is directly connected to multiple sites, both of which are using site-local addressing. When connecting to a 2nd host (Host2), Host2 may also be connected to multiple sites - perhaps even the same two as Host1. Host1 / \ / \ SiteA SiteB \ / \ / Host2 | | SiteC When Host1 queries DNS for the addresses for Host2, what addresses should it receive back? I'd think Host1 would want Host2's global addresses, site-local addresses for interfaces attached to SiteA, and site-local addresses for interfaces attached to SiteB. Since Host1 is not attached to SiteC, it would not want to receive site-local addresses for SiteC. In each case, Host1 must know the site in which the site-local addresses returned are valid, so that it will only forward packets using the destination site-local address into the site in which the address is valid. Host1 may also want to restrict the results returned so that it only receives site-local addresses for a single site (say SiteA), and not receive any of Host2's site-local addresses for SiteB. >From what I read above, in order for Host1 to receive all of Host2's addresses, it would need to send two queries to the DNS name server - one via SiteA and one via SiteB. In each case, in order to receive a site-local address the destination address for the DNS name server would need to be a site-local address for the site over which the query is sent. In order to receive the packets with a site-local destination address, the DNS name server must be directly connected to each site that a host in a zone for which it is authoritative is also connected. For instance, the each authoritative name server for Host2 must be connected to SiteA, SiteB, and SiteC, while the authoritative name server for Host1 only needs to be connected to SiteA and SiteB. In order for a client to receive all IP addresses for a given host, the client must be directly attached to each site to which the host is also attached, as it cannot receive any site-local addresses for sites to which it is not attached. That is, to receive all of Host2's addresses, the client must be directly connected to SiteA, SiteB, and SiteC. For a "typical" application, only receiving site-local addresses for sites to which the client is attached should be fine. For DNS management tools (nslookup, dig, etc.) it might not be. When performing a zone transfer, the primary name server needs to somehow tell the secondary name servers which zone a site-local address for a host is associated with. This way, the secondary name server can restrict which site-local addresses it returns to a client. When referring a client to another name server, the referring name server must know if the client and new target name server are in the same site. If so, the address of the new name server should be a site-local address for the site to which both are directly attached (if the name server has a site-local address for that site); otherwise, it should be a global address. When returning the sockaddr_in6 structures to the requesting application, the resolver must fill in the sin6_scope_id field for any site-local addresses based on the site to which the DNS query is sent. This allows the TCP/IP stack to know the site in which the site-local address is valid, and to route packets using the site-local address to the site in which the address is valid. When registering IP addresses, a host must ensure that it only register site-local addresses via the site in which the site-local address is defined, while global addresses may be registered via any site. This way, the DNS name server can know which site-local addresses are associated with which sites. Roy --0__=0ABBE147DFC271828f9e8a93df938690918c0ABBE147DFC27182 Content-type: text/html; charset=US-ASCII Content-Disposition: inline On Sunday, 06/09/2002 at 11:00 MST, "Tony Hain" <alh-ietf@tndh.net> wrote:
> THere is a mismatch between the DNS perception of 'site' and the
> site-local definition of 'site'. The DNS version is much stricter about
> physical separation, but there shouldn't be a requirement that DNS
> servers for a segment of an AS have to be in differrent SL regions. It
> sounds like there is more to do on the DNS operations document... In any
> case, the only way a DNS server should return a SL in a response is if
> the query was received on a SL. This is the only reasonable way for the
> server to know if the answer is usable. If the DNS servers for a given
> set of hosts are split across multiple SL zones, then some of the
> answers will be global. This is logically the right thing to do from the
> DNS query/response perspective, but from the operations perspective, the
> servers shouldn't be in separate SL zones. If a particular network
> doesn't want to add to the DNS infrastructure, there is no requirement
> to populate it with SL addresses. If the routers don't announce them in
> the RA, and they aren't in the DNS, they don't get used. That does not
> mean we should get rid of them, because smaller organizations will
> typically find them useful to minimize the impact of changing providers.

The DNS issues surrounding site-local addresses concern me far more than
routing issues which have been discussed.  I tried to imagine how DNS
would work given what is described above, especially for the case where
a host is attached to multiple sites.  I don't think this is just an
operational problem, but requires new standards and new code at both the
resolvers as well as name servers in order for it to work.  The more I
thought about it, the more I liked the idea of site-local addresses
disappearing from the architecture or, at a minimum, a host being
restricted to connecting to a single site at any given time.

Imagine a host (Host1) which is directly connected to multiple sites, both
of which are using site-local addressing.  When connecting to a 2nd host
(Host2), Host2 may also be connected to multiple sites - perhaps even the
same two as Host1.

            Host1
           /     \
          /       \
       SiteA     SiteB
          \        /
           \      /
            Host2
              |
              |
            SiteC

When Host1 queries DNS for the addresses for Host2, what addresses should
it receive back?  I'd think Host1 would want Host2's global addresses,
site-local addresses for interfaces attached to SiteA, and site-local
addresses for interfaces attached to SiteB.  Since Host1 is not attached
to SiteC, it would not want to receive site-local addresses for SiteC.  In
each case, Host1 must know the site in which the site-local addresses
returned are valid, so that it will only forward packets using the
destination site-local address into the site in which the address is
valid.  Host1 may also want to restrict the results returned so that it
only receives site-local addresses for a single site (say SiteA), and not
receive any of Host2's site-local addresses for SiteB.

From what I read above, in order for Host1 to receive all of Host2's
addresses, it would need to send two queries to the DNS name server - one
via SiteA and one via SiteB.  In each case, in order to receive a
site-local address the destination address for the DNS name server would
need to be a site-local address for the site over which the query is sent.

In order to receive the packets with a site-local destination address, the
DNS name server must be directly connected to each site that a host in a
zone for which it is authoritative is also connected.  For instance, the
each authoritative name server for Host2 must be connected to SiteA, SiteB,
and SiteC, while the authoritative name server for Host1 only needs to be
connected to SiteA and SiteB.

In order for a client to receive all IP addresses for a given host, the
client must be directly attached to each site to which the host is also
attached, as it cannot receive any site-local addresses for sites to
which it is not attached.  That is, to receive all of Host2's addresses,
the client must be directly connected to SiteA, SiteB, and SiteC.  For
a "typical" application, only receiving site-local addresses for sites
to which the client is attached should be fine.  For DNS management tools
(nslookup, dig, etc.) it might not be.

When performing a zone transfer, the primary name server needs to somehow
tell the secondary name servers which zone a site-local address for a
host is associated with.  This way, the secondary name server can restrict
which site-local addresses it returns to a client.

When referring a client to another name server, the referring name server
must know if the client and new target name server are in the same site.  
If so, the address of the new name server should be a site-local address
for the site to which both are directly attached (if the name server has
a site-local address for that site); otherwise, it should be a global
address.

When returning the sockaddr_in6 structures to the requesting application,
the resolver must fill in the sin6_scope_id field for any site-local
addresses based on the site to which the DNS query is sent.  This
allows the TCP/IP stack to know the site in which the site-local address
is valid, and to route packets using the site-local address to the
site in which the address is valid.

When registering IP addresses, a host must ensure that it only register
site-local addresses via the site in which the site-local address is
defined, while global addresses may be registered via any site.  This
way, the DNS name server can know which site-local addresses are
associated with which sites.

Roy --0__=0ABBE147DFC271828f9e8a93df938690918c0ABBE147DFC27182-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 10 10:45:18 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5AHjIk7007725; Mon, 10 Jun 2002 10:45:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5AHjI6f007724; Mon, 10 Jun 2002 10:45:18 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5AHjEk7007717 for ; Mon, 10 Jun 2002 10:45:14 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA22651; Mon, 10 Jun 2002 13:45:17 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g5AHjHZs022737; Mon, 10 Jun 2002 13:45:17 -0400 (EDT) Message-Id: <200206101745.g5AHjHZs022737@thunk.east.sun.com> From: Bill Sommerfeld To: Ignatios Souvatzis cc: ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-Reply-To: Your message of "Mon, 10 Jun 2002 10:55:01 +0200." <20020610105501.E17133@tarski.cs.uni-bonn.de> Reply-to: sommerfeld@east.sun.com Date: Mon, 10 Jun 2002 13:45:16 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk It's also worth pointing out that NAT is not the only way a site-local-only system could get external connectivity. A transport-layer gateway/relay like a socks implementation for v6 or the KAME "faithd" would be another way.. - 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 Jun 10 11:28:28 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5AISSk7007845; Mon, 10 Jun 2002 11:28:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5AISRFL007844; Mon, 10 Jun 2002 11:28:27 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5AISQk7007837 for ; Mon, 10 Jun 2002 11:28:26 -0700 (PDT) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g5AISPoR003226 for ; Mon, 10 Jun 2002 11:28:25 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g5AISOtu003225 for ipng@sunroof.eng.sun.com; Mon, 10 Jun 2002 11:28:24 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g57DGtk7000111 for ; Fri, 7 Jun 2002 06:16:55 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA22104 for ; Fri, 7 Jun 2002 06:16:57 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA23054 for ; Fri, 7 Jun 2002 07:18:18 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id D23A36A90A; Fri, 7 Jun 2002 16:16:55 +0300 (EEST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 586BC6A907 for ; Fri, 7 Jun 2002 16:16:54 +0300 (EEST) Message-ID: <3D00B28F.1080902@piuha.net> Date: Fri, 07 Jun 2002 16:18:07 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: finalizing cellular hosts document, version -03 now out References: <3CFFD2EC.101@kolumbus.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Version -03 of the cellular host document has now been published. You can download it from http://www-nrc.nokia.com/sua/draft-ietf-ipv6-cellular-host-03.txt http://www-nrc.nokia.com/sua/draft-ietf-ipv6-cellular-host-03-pa10.doc (with edits) Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 10 11:29:50 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5AITok7007885; Mon, 10 Jun 2002 11:29:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5AIToRA007884; Mon, 10 Jun 2002 11:29:50 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5AITmk7007876 for ; Mon, 10 Jun 2002 11:29:48 -0700 (PDT) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g5AITloR003234 for ; Mon, 10 Jun 2002 11:29:47 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g5AITlg8003233 for ipng@sunroof.eng.sun.com; Mon, 10 Jun 2002 11:29:47 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g59JBik7004915 for ; Sun, 9 Jun 2002 12:11:44 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA22182 for ; Sun, 9 Jun 2002 12:11:47 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA01200 for ; Sun, 9 Jun 2002 13:11:47 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id 452AE6A907; Sun, 9 Jun 2002 22:11:46 +0300 (EEST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id E2B796A901; Sun, 9 Jun 2002 22:11:37 +0300 (EEST) Message-ID: <3D03A8B3.1020309@piuha.net> Date: Sun, 09 Jun 2002 22:12:51 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: James Kempf Cc: Pekka Savola , ipng@sunroof.eng.sun.com Subject: Re: Securing Neighbor Discovery BOF References: <003401c20f81$27268970$1e6015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk James Kempf wrote: > Pekka, > > We will shortly be releasing the ABK draft with a statement like the > Photuris statement, which was included in IKE. Sounds interesting! > Also, some people believe that IPsec will work. If some way can be found > around the keying problem, it could be a viable alternative. There may be ways around some of the problems, in the way that my previous e-mail outlined. However, generally speaking you will end up with a solution that separates good guys from the bad guys. But it isn't necessarily going to be able to indicate which ones of the "good guys" can use which IP addresses. This may or may not be sufficient, depending on who you ask. Jari P.S. There's also a separate e-mail list set up for the discussions. Send e-mail to ietf-send-request@standards.ericsson.net with the text "subscribe" in the body to join. The name of the list is "SEND" for Secure Neighbour Discovery. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 10 11:30:34 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5AIUXk7007901; Mon, 10 Jun 2002 11:30:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5AIUXpq007900; Mon, 10 Jun 2002 11:30:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5AIUVk7007893 for ; Mon, 10 Jun 2002 11:30:32 -0700 (PDT) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g5AIUUoR003242 for ; Mon, 10 Jun 2002 11:30:30 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g5AIUU3c003241 for ipng@sunroof.eng.sun.com; Mon, 10 Jun 2002 11:30:30 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5AFxJk7007439 for ; Mon, 10 Jun 2002 08:59:19 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA19210 for ; Mon, 10 Jun 2002 08:58:07 -0700 (PDT) Received: from cisco.com (edinburgh.cisco.com [144.254.112.76]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA10786 for ; Mon, 10 Jun 2002 09:58:06 -0600 (MDT) Received: (from dfawcus@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id QAA18465; Mon, 10 Jun 2002 16:57:57 +0100 (BST) Date: Mon, 10 Jun 2002 16:57:57 +0100 From: Derek Fawcus To: "Steven M. Bellovin" Cc: Hiroki Ishibashi , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols Message-ID: <20020610165757.E7031@edinburgh.cisco.com> Mail-Followup-To: "Steven M. Bellovin" , Hiroki Ishibashi , ipng@sunroof.eng.sun.com References: <20020610114319.F12237B4B@berkshire.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20020610114319.F12237B4B@berkshire.research.att.com>; from smb@research.att.com on Mon, Jun 10, 2002 at 07:43:18AM -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, Jun 10, 2002 at 07:43:18AM -0400, Steven M. Bellovin wrote: > In message <6EC21033B3E449bashi@ipv6.nec.co.jp>, Hiroki Ishibashi writes: > >Steven M. Bellovin wrote: > > > > >>I'm still confused. If a packet arrives on a site-enabled interface, > >>addressed to multicast address AllSPFRouters, and with protocol number > >>89 (OSPF), to which process is it delivered? Does something actually > >>peek inside the packet to see if it's advertising global or site-local > >>addresses when making the dispatching decision? > > > >"2.4. Explicit support for multiple instances per link" in RFC2740 > >is the one to be used to identify a process (instance) to which packet > >are delivered. Not necessary to peek into LSAs for the dispatching > >decision. > > > > I must be missing something; I still don't understand. > > Let's look at a simple case, a router with two physical interfaces with > one attached to the site backbone, and one feeding a departmental LAN. > I'm perfectly willing to assume multiple logical interfaces on either > physical interface. > > Let's consider the backbone interface. It's going to be seeing two > types of routing advertisement, site-local and global. When an > incoming OSPF packet arrives, it's addressed to the same multicast > address in either case. To which logical interface does it belong? It looks as if the intended use of this Instance ID is to have multiple groups of OSPF routers running on the same link, _which know nothing about each other_. It doesn't look as if it's intended that any particular router would ever have a given interface assigned more than one Instance ID. Mind that said, it would be possible to do this, with one instance ID for globals and one for site locals, but it would require some form of receive demultiplexing to deliver the appropriate packets to the appropriate 'instance' of OSPF running locally. This would obviouly require peeking into the OSPF header, but not into the LSAs. e.g. a unix method - have a listener process on protocol 89, it peeks at the instance ID, and demuxes the packets to the appropriate local OSPF process. For Tx the OSPF process can send direct to the interface. DF -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 10 11:53:34 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5AIrYk7008046; Mon, 10 Jun 2002 11:53:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5AIrXha008045; Mon, 10 Jun 2002 11:53:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5AIrUk7008038 for ; Mon, 10 Jun 2002 11:53:30 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA27713 for ; Mon, 10 Jun 2002 11:53:34 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA21056 for ; Mon, 10 Jun 2002 12:53:33 -0600 (MDT) Message-ID: <002f01c210af$df9ec240$246015ac@T23KEMPF> From: "James Kempf" To: "Steven M. Bellovin" Cc: "Jari Arkko" , "Pekka Savola" , References: <20020609141117.0B9717B4B@berkshire.research.att.com> Subject: Re: Securing Neighbor Discovery BOF Date: Mon, 10 Jun 2002 11:51:43 -0700 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 Hi Steve, > >Key distribution could be done via Layer 2 AAA or using the roaming > >consortia idea we had in the ABK draft. However, I think that might > >require some change in IPsec policy, because I believe the policy only > >allows IKE or manual keying for key distribution. > > That's not correct. In fact, there's another working group, KINK, > whose goal is Kerberos key management for IPsec. > Thanx for the correction. So is it the case then that there would be no change in IPsec policy required for doing AAA-based or roaming consortia-based key management? Is so, then perhaps this problem is fairly straightforward to solve. jak -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 10 12:01:50 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5AJ1nk7008071; Mon, 10 Jun 2002 12:01:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5AJ1nJ8008070; Mon, 10 Jun 2002 12:01:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5AJ1jk7008063 for ; Mon, 10 Jun 2002 12:01:45 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA00304 for ; Mon, 10 Jun 2002 12:01:49 -0700 (PDT) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA10852 for ; Mon, 10 Jun 2002 12:01:48 -0700 (PDT) Received: from postal.research.att.com (postal.research.att.com [135.207.23.30]) by mail-blue.research.att.com (Postfix) with ESMTP id 115CE4CE23; Mon, 10 Jun 2002 15:01:44 -0400 (EDT) Received: from berkshire.research.att.com (postal.research.att.com [135.207.23.30]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id OAA21719; Mon, 10 Jun 2002 14:56:26 -0400 (EDT) Received: from research.att.com (localhost [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id 4B4C17B4B; Mon, 10 Jun 2002 15:01:43 -0400 (EDT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: "Steven M. Bellovin" To: "James Kempf" Cc: "Jari Arkko" , "Pekka Savola" , ipng@sunroof.eng.sun.com Subject: Re: Securing Neighbor Discovery BOF Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 10 Jun 2002 15:01:43 -0400 Message-Id: <20020610190143.4B4C17B4B@berkshire.research.att.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <002f01c210af$df9ec240$246015ac@T23KEMPF>, "James Kempf" writes: >Hi Steve, > >> >Key distribution could be done via Layer 2 AAA or using the roaming >> >consortia idea we had in the ABK draft. However, I think that might >> >require some change in IPsec policy, because I believe the policy >only >> >allows IKE or manual keying for key distribution. >> >> That's not correct. In fact, there's another working group, KINK, >> whose goal is Kerberos key management for IPsec. >> > >Thanx for the correction. > >So is it the case then that there would be no change in IPsec policy >required for doing AAA-based or roaming consortia-based key management? >Is so, then perhaps this problem is fairly straightforward to solve. Well, as straight-forward as any key management issue... But the word "policy" is important; there's a lot more to setting up an IPsec than key exchange. Deciding exactly what to encrypt and how has to be negotiated, imposed, or otherwise agreed-upon. --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com ("Firewalls" book) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 10 13:00:52 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5AK0qk7008225; Mon, 10 Jun 2002 13:00:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5AK0p1r008224; Mon, 10 Jun 2002 13:00:51 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5AK0mk7008217 for ; Mon, 10 Jun 2002 13:00:48 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA23940 for ; Mon, 10 Jun 2002 13:00:53 -0700 (PDT) Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA11897 for ; Mon, 10 Jun 2002 13:00:52 -0700 (PDT) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id D8F7E1E003 for ; Mon, 10 Jun 2002 16:00:51 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id QAA10748 for ; Mon, 10 Jun 2002 16:00:51 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id NAA25336; Mon, 10 Jun 2002 13:00:50 -0700 (PDT) Message-Id: <200206102000.NAA25336@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols References: <20020610114319.F12237B4B@berkshire.research.att.com> <20020610165757.E7031@edinburgh.cisco.com> Date: Mon, 10 Jun 2002 13:00:50 -0700 Versions: dmail (solaris) 2.4c/makemail 2.9d Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk An example that may be a little too contrived: H1 | |// B-------A / // \ / | | | C D | | | | \ \\ / E--------F |\\ | H2 A,B,C,E,F are in one site (on the left); A, D, and F are in another site (or no site). H1 is connected to A, and H2 is connected to F. It's fairly clear how to allow A and F to not advertise site-local addresses across the boundary (at least, as long as it coincides with a routing protocol boundary, e.g. OSPF area). However, if H1 knows that H2 is witchin the same site, H1 is allowed to use its site-local source address to send to H2's global address. However, along the H1-A-D-F-H2 path, A would have to drop the packet because it has a site-local address and is trying to cross a site boundary. Although this example is a bit contrived, it comes close to describing the topology at AT&T, with Research split between the coasts and both a private link (e.g. the internal site link) and links to the AT&T internal network (which is still organizational-internal, so it's reasonable to speak an IGP). 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 Jun 10 13:26:58 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5AKQvk7008304; Mon, 10 Jun 2002 13:26:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5AKQv5q008303; Mon, 10 Jun 2002 13:26:57 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5AKQrk7008296 for ; Mon, 10 Jun 2002 13:26:53 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA02135 for ; Mon, 10 Jun 2002 13:26:57 -0700 (PDT) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA10894 for ; Mon, 10 Jun 2002 14:28:31 -0600 (MDT) Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 10 Jun 2002 13:26:56 -0700 Received: from 157.54.5.25 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 10 Jun 2002 13:26:55 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 10 Jun 2002 13:26:55 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 10 Jun 2002 13:26:55 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3590.0); Mon, 10 Jun 2002 13:26:21 -0700 Content-Class: urn:content-classes:message Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 10 Jun 2002 13:27:01 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6236.0 Message-ID: <2E33960095B58E40A4D3345AB9F65EC1047CF1F4@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Fwd: IPv6 Scoped Addresses and Routing Protocols thread-index: AcIQufTvq4+1Mp0ZQfuODqHerZ/feAAAm+hg From: "Dave Thaler" To: "Bill Fenner" Cc: X-OriginalArrivalTime: 10 Jun 2002 20:26:21.0557 (UTC) FILETIME=[15831250:01C210BD] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5AKQsk7008297 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > -----Original Message----- > From: Bill Fenner [mailto:fenner@research.att.com] [...] > It's fairly clear how to allow A and F to not advertise site-local > addresses across the boundary (at least, as long as it coincides with a > routing protocol boundary, e.g. OSPF area). However, if H1 knows that > H2 is witchin the same site, H1 is allowed to use its site-local source > address to send to H2's global address. However, along the H1-A-D-F-H2 > path, A would have to drop the packet because it has a site-local address > and is trying to cross a site boundary. Yes, scopes have to be convex. This is not new in IPv6. See section 7 of the IPv4 scoped multicast RFC (2365). -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 Mon Jun 10 13:37:15 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5AKbFk7008367; Mon, 10 Jun 2002 13:37:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5AKbFOC008366; Mon, 10 Jun 2002 13:37:15 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5AKbBk7008359 for ; Mon, 10 Jun 2002 13:37:12 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA05537 for ; Mon, 10 Jun 2002 13:37:16 -0700 (PDT) Received: from mail-blue.research.att.com (H-135-207-30-102.research.att.com [135.207.30.102]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA04259 for ; Mon, 10 Jun 2002 14:37:11 -0600 (MDT) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id D3D6E4CEBC; Mon, 10 Jun 2002 16:37:06 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id QAA11248; Mon, 10 Jun 2002 16:37:05 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id NAA25889; Mon, 10 Jun 2002 13:37:05 -0700 (PDT) Message-Id: <200206102037.NAA25889@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: dthaler@windows.microsoft.com Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols Cc: ipng@sunroof.eng.sun.com Date: Mon, 10 Jun 2002 13:37:05 -0700 Versions: dmail (solaris) 2.4c/makemail 2.9d Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Yes, scopes have to be convex. This is not new in IPv6. >See section 7 of the IPv4 scoped multicast RFC (2365). The worry is that people might look at routing protocols mechanisms that keep the site convex wrt site-local addresses and consider that sufficient. draft-ietf-ipngwg-scoping-arch-03.txt only says: o Each zone is required to be "convex" from a routing perspective, i.e., packets sent from one interterface to any other interface in the same zone are never routed outside the zone. which does not seem to preclude my example topology, since the routing protocol causes the site-local scope zone to be convex. 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 Jun 10 13:56:30 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5AKuUk7008435; Mon, 10 Jun 2002 13:56:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5AKuTdc008434; Mon, 10 Jun 2002 13:56:29 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5AKuQk7008427 for ; Mon, 10 Jun 2002 13:56:26 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA16087 for ; Mon, 10 Jun 2002 13:56:29 -0700 (PDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA11326 for ; Mon, 10 Jun 2002 13:56:29 -0700 (PDT) Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 10 Jun 2002 13:56:28 -0700 Received: from 157.54.6.197 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 10 Jun 2002 13:56:28 -0700 Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 10 Jun 2002 13:56:28 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 10 Jun 2002 13:56:27 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3604.0); Mon, 10 Jun 2002 13:56:04 -0700 Content-Class: urn:content-classes:message Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 10 Jun 2002 13:56:35 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6236.0 Message-ID: <2E33960095B58E40A4D3345AB9F65EC1047CF1F6@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Fwd: IPv6 Scoped Addresses and Routing Protocols thread-index: AcIQvp0nt4Vfd1YvQ3mh8dPWsGVFTwAAhB+w From: "Dave Thaler" To: "Bill Fenner" Cc: X-OriginalArrivalTime: 10 Jun 2002 20:56:04.0155 (UTC) FILETIME=[3C05F0B0:01C210C1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5AKuQk7008428 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: Bill Fenner [mailto:fenner@research.att.com] [...] > >Yes, scopes have to be convex. This is not new in IPv6. > >See section 7 of the IPv4 scoped multicast RFC (2365). > > The worry is that people might look at routing protocols mechanisms > that keep the site convex wrt site-local addresses and consider > that sufficient. > > draft-ietf-ipngwg-scoping-arch-03.txt only says: > > o Each zone is required to be "convex" from a routing > perspective, i.e., packets sent from one interterface to > any other interface in the same zone are never routed > outside the zone. > > which does not seem to preclude my example topology, since the routing > protocol causes the site-local scope zone to be convex. I believe it does preclude your example topology, since you have packets sent from one interface (H1's) to another interface (H2's) that are routed outside the zone. The fact that the destination address is global is orthogonal. -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 Mon Jun 10 14:25:47 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5ALPlk7008523; Mon, 10 Jun 2002 14:25:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5ALPkDK008522; Mon, 10 Jun 2002 14:25:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5ALPhk7008515 for ; Mon, 10 Jun 2002 14:25:43 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA27538 for ; Mon, 10 Jun 2002 14:25:46 -0700 (PDT) Received: from mail-blue.research.att.com (H-135-207-30-102.research.att.com [135.207.30.102]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA29990 for ; Mon, 10 Jun 2002 15:25:45 -0600 (MDT) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 47E2E4CEC2; Mon, 10 Jun 2002 17:25:45 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id RAA11942; Mon, 10 Jun 2002 17:25:44 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id OAA26688; Mon, 10 Jun 2002 14:25:43 -0700 (PDT) Message-Id: <200206102125.OAA26688@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: dthaler@windows.microsoft.com Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols Cc: ipng@sunroof.eng.sun.com Date: Mon, 10 Jun 2002 14:25:43 -0700 Versions: dmail (solaris) 2.4c/makemail 2.9d Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I think this restriction precludes lots of real network topologies. I also think that the wording in the spec needs to be a little more clear that it means globally convex and not just convex with respect to the zone-scoped addresses. 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 Jun 10 14:43:13 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5ALhDk7008563; Mon, 10 Jun 2002 14:43:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5ALhC4f008562; Mon, 10 Jun 2002 14:43:12 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5ALh8k7008555 for ; Mon, 10 Jun 2002 14:43:09 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA04771 for ; Mon, 10 Jun 2002 14:43:11 -0700 (PDT) Received: from esunmail ([129.147.58.122]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA23111 for ; Mon, 10 Jun 2002 15:44:47 -0600 (MDT) Received: from xpa-fe2 (esunmail-ge0 [129.147.58.121]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 0.3 (built May 13 2002)) with ESMTP id <0GXI00EFMEZX4B@edgemail1.Central.Sun.COM> for ipng@sunroof.eng.sun.com; Mon, 10 Jun 2002 15:43:10 -0600 (MDT) Received: from localhost ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 0.2 (built Apr 26 2002)) with ESMTPSA id <0GXI00AYOEZW4R@mail.sun.net> for ipng@sunroof.eng.sun.com; Mon, 10 Jun 2002 15:43:09 -0600 (MDT) Date: Mon, 10 Jun 2002 14:43:08 -0700 From: Alain Durand Subject: Re: IPv6 Scoped Addresses and Routing Protocols In-reply-to: To: ipng@sunroof.eng.sun.com Message-id: <0D87F839-7CBB-11D6-AC39-00039376A6AA@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.482) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sunday, June 9, 2002, at 12:11 PM, Tony Hain wrote: > I think most of this thread is focused on what are simply implementation > details, not an issue for the standards per se. The biggest issue I saw > was related to DNS returning SL or not, and this is not an issue as long > as the DNS server is not expected to deal with multiple sites. An issue that is overlooked in this discussion is reverse path DNS lookup for site local addresses. Today, with IPv4+NAT on my home network, I simply point my stub-resolvers to my ISP DNS resolver. It's simple, and works fine, at least until I try to do reverse DNS lookup for my internal addresses. Then it just fails. Some applications that I run on my local LAN don't work well or wait forever for timeouts, because they can not resolve 1.1.168 .192.in-addr.arpa. If I had enough IPv4 address space, I could get my ISP to populate the DNS reverse maps, and my problem would be solved. I would expect that IPv6 will help me here by giving me a global prefix (although I agree that getting my ISP to populate a v6 reverse map is somehow more complex than in IPv4), but if, according to the address selection rules, my system will prefer site local addresses for internal communication, amd I'll back to square 1. - 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 Mon Jun 10 15:08:55 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5AM8tk7008597; Mon, 10 Jun 2002 15:08:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5AM8srS008596; Mon, 10 Jun 2002 15:08:54 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5AM8ok7008589 for ; Mon, 10 Jun 2002 15:08:50 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA16543 for ; Mon, 10 Jun 2002 15:08:54 -0700 (PDT) Received: from esunmail ([129.147.58.122]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA10381 for ; Mon, 10 Jun 2002 16:08:54 -0600 (MDT) Received: from xpa-fe1 (esunmail-ge0 [129.147.58.121]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 0.3 (built May 13 2002)) with ESMTP id <0GXI00AERG6S07@edgemail1.Central.Sun.COM> for ipng@sunroof.eng.sun.com; Mon, 10 Jun 2002 16:08:53 -0600 (MDT) Received: from localhost ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 0.2 (built Apr 26 2002)) with ESMTPSA id <0GXI00MECG6RX0@mail.sun.net> for ipng@sunroof.eng.sun.com; Mon, 10 Jun 2002 16:08:52 -0600 (MDT) Date: Mon, 10 Jun 2002 15:08:50 -0700 From: Alain Durand Subject: Re: IPv6 Scoped Addresses and Routing Protocols In-reply-to: <4.3.2.7.2.20020607110536.02f48db0@mailhost.iprg.nokia.com> To: Bob Hinden Cc: ipng@sunroof.eng.sun.com Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.482) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Friday, June 7, 2002, at 03:56 PM, Bob Hinden wrote: > I think the w.g. has some choices to make regarding site-local > addresses. > > 1) Remove site-local from the IPv6. > > This would involve remove it from the IPv6 addressing documents and > find all other documents that mention them and update these. Some of > these may require significant modification if use site-local as a basic > part of their mechanisms. There will also be an impact to shipping > IPv6 implementations. This would have to be sorted out. A good > understanding of what different vendors plan here would be useful. > > 2) Keep site-local but limit it's scope of usage. > > This would be something like writing an applicability document that > defines it usage and for example restricts it use to sites not > connected to the Internet. Other usage would be for future study. > This would be consistent with most of the current specifications. It > would make completing the scoped address architecture document > simpler. There might be other specifications to update if they were > using site-local and didn't have any provision to move to global > addresses. A potential drawback is that the day those sites connect to the Internet, they will have to renumber. Until the renumbering story is significantly better, there will be temptations to use IPv6 NAT... > 3) Keep site-local and allow full usage > > This would mean fully specifying how to use site-local, documenting the > router and DNS issues, completing the scoped addressing architecture > document, perhaps enhancing IPv6 routing protocols to have more > knowledge of site-local addresses, etc. > > The working group has been going down 3) for some time now. I think > your email is a good start at seeing if should continue in this > direction or change course. This path is expensive, as seen in the current thread. - 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 Mon Jun 10 19:18:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5B2Iuk7009060; Mon, 10 Jun 2002 19:18:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5B2Iutc009059; Mon, 10 Jun 2002 19:18:56 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5B2Iqk7009052 for ; Mon, 10 Jun 2002 19:18:52 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA07574 for ; Mon, 10 Jun 2002 19:18:54 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA27154 for ; Mon, 10 Jun 2002 19:18:53 -0700 (PDT) Received: from localhost ([3ffe:501:4819:2000:200:39ff:fed9:21d7]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g5B2Iq875745 for ; Tue, 11 Jun 2002 11:18:52 +0900 (JST) Date: Tue, 11 Jun 2002 11:18:54 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipng@sunroof.eng.sun.com Subject: Re: IPv6 Scoped Addresses and Routing Protocols In-Reply-To: <0D87F839-7CBB-11D6-AC39-00039376A6AA@sun.com> References: <0D87F839-7CBB-11D6-AC39-00039376A6AA@sun.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 36 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Mon, 10 Jun 2002 14:43:08 -0700, >>>>> Alain Durand said: > An issue that is overlooked in this discussion is reverse path > DNS lookup for site local addresses. > Today, with IPv4+NAT on my home network, I simply point my > stub-resolvers to my ISP DNS resolver. It's simple, and works > fine, at least until I try to do reverse DNS lookup for my internal > addresses. Then it just fails. Some applications that I run on > my local LAN don't work well or wait forever for timeouts, > because they can not resolve 1.1.168 .192.in-addr.arpa. > If I had enough IPv4 address space, I could get my ISP > to populate the DNS reverse maps, and my problem would > be solved. > I would expect that IPv6 will help me here by giving me a > global prefix (although I agree that getting my ISP to populate > a v6 reverse map is somehow more complex than in IPv4), > but if, according to the address selection rules, my system will prefer > site local addresses for internal communication, amd I'll back to square > 1. (this is not directly related to the site-local address issue any more) Aside from whether site-local addresses are good, acceptable, or bad, I believe the described problem means we'll have to try to not rely on the reverse lookup in IPv6 much more than in IPv4. draft-ietf-dnsop-inaddr-required-03.txt should be taken seriously in IPv6. 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 Mon Jun 10 19:29:53 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5B2Trk7009103; Mon, 10 Jun 2002 19:29:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5B2Tr9M009102; Mon, 10 Jun 2002 19:29:53 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5B2Tnk7009095 for ; Mon, 10 Jun 2002 19:29:49 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA21275 for ; Mon, 10 Jun 2002 19:29:53 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA26388 for ; Mon, 10 Jun 2002 20:29:50 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 19C334B29 for ; Tue, 11 Jun 2002 11:29:47 +0900 (JST) To: ipng@sunroof.eng.sun.com In-reply-to: jinmei's message of Tue, 11 Jun 2002 11:18:54 +0900. 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: IPv6 Scoped Addresses and Routing Protocols From: itojun@iijlab.net MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Content-ID: <10873.1023762579.0@itojun.org> Date: Tue, 11 Jun 2002 11:29:47 +0900 Message-ID: <10875.1023762587@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <10873.1023762579.1@itojun.org> >> An issue that is overlooked in this discussion is reverse path >> DNS lookup for site local addresses. > >> Today, with IPv4+NAT on my home network, I simply point my >> stub-resolvers to my ISP DNS resolver. It's simple, and works >> fine, at least until I try to do reverse DNS lookup for my internal >> addresses. Then it just fails. Some applications that I run on >> my local LAN don't work well or wait forever for timeouts, >> because they can not resolve 1.1.168 .192.in-addr.arpa. >> If I had enough IPv4 address space, I could get my ISP >> to populate the DNS reverse maps, and my problem would >> be solved. > >> I would expect that IPv6 will help me here by giving me a >> global prefix (although I agree that getting my ISP to populate >> a v6 reverse map is somehow more complex than in IPv4), >> but if, according to the address selection rules, my system will prefer >> site local addresses for internal communication, amd I'll back to square >> 1. there are at least three major reasons why DNS reverse mapping do not work with scoped address. (1) global nature of DNS directly conflicts with scoped address model. (2) DNS wire packet format only uses 128bits. (3) the querier of the reverse mapping differs from the machine holding the database, thus the view of the scope is different (and there's no way of identifying particular scopes, like "this subnet" or "this site""). if the querier could directly resolve the reverse mapping, we could solve the problem. here's one of my proposed solution. some may not like it, specifically dnsext folks... itojun ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <10873.1023762579.2@itojun.org> Internet Engineering Task Force Jun-ichiro itojun Hagino INTERNET-DRAFT IIJ Research Laboratory Expires: November 17, 2002 May 17, 2002 Use of ICMPv6 node information query for reverse DNS lookup draft-itojun-ipv6-nodeinfo-revlookup-00.txt 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.'' To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. Distribution of this memo is unlimited. The internet-draft will expire in 6 months. The date of expiration will be November 17, 2002. Abstract The document proposes an alternative way to perform reverse DNS lookup, by using ICMPv6 node information query/reply [Crawford, 2002] . The proposed protocol works only with IPv6 (not with IPv4). 1. Motivation As documented in [Senie, 2001] , even though many applications assume reverse address mapping to exist, DNS reverse address mapping table may not be present. With IPv4, automatically-generated reverse mapping table, like following, has been used. 123.123.123.123.in-addr.arpa. IN PTR 123-123-123-123.reverse.example.org. However, it is difficult to provide such mapping for IPv6, due to the number of reverse mapping records needed. Therefore, with IPv6, it is more likely to see IPv6 addresses without reverse DNS mapping. While it may be possible to register reverse DNS records via dynamic DNS updates, it is still not widely practiced due to difficulties with authentication ITOJUN Expires: November 17, 2002 [Page 1] DRAFT ICMPv6 node info query for reverse DNS lookup May 2002 (distribution of TSIG authentication keys). Also, reverse DNS lookup based on PTR record can cause more delay to applications than IPv4 case, as an IPv6 reverse DNS mapping requires much more of NS indirections (34 levels rather than 6 levels). Another problem is that DNS PTR records do not support scoped IPv6 addresses well, as DNS infrastructure is global in nature and there is no way to differentiate between scope zones. For this reason, this document discusses an alternative way to provide reverse DNS lookups. The approach uses ICMPv6 node information query/reply [Crawford, 2002] . 2. Protocol There are two parties: querier and responder. The querier knows an IPv6 address of the responder, and is interested in getting fully-qualified DNS name for the responder, Querier transmits the following ICMPv6 node information query packet to the reponder's address: IPv6 source: one of querier's address (Q) IPv6 destination: responder's address (R) Code: 0 (Subject is an IPv6 address) Qtype: 2 (DNS name) Nonce: pseudo-random (N) Data (Subject): responder's address In response, the reponder transmits ICMPv6 node information reply with fully-qualified DNS name. IPv6 source: one of responder's address IPv6 destination: Q Code: 0 (Successful) Qtype: 2 (DNS name) Flag: lowermost bit set (TTL is valid) Nonce: N Data: fully-qualified DNS name. TTL must be set based on R's address lifetime. Note: o The IPv6 source address of the reply need not be R; Nonce field should be used to match replies against a query. o Fully-qualified DNS name must be sent on replies. If DNS name on the reply is a single-component name, the querier should ignore the response. o Administrators are advised to provide consistent reverse mapping with forward DNS record, where possible. ITOJUN Expires: November 17, 2002 [Page 2] DRAFT ICMPv6 node info query for reverse DNS lookup May 2002 Querier is allowed to retransmit query 3 times with 1 second interval. Querier should implement cache mechanism, based on the TTL value sent from the responder. If TTL value is not present on replies, querier must not cache values on replies. If there is no response after 3 retransmissions, negative-cache entry with lifetime of 30 second should be installed. Querier must ignore responses with a Nonce value unknown to the querier (it could be a malicious attempt to taint the cache). Responder must rate-limit replies as documented in ICMPv6 node information query document [Crawford, 2002] . 3. Appicability 3.1. Is "DNS name" on the reply really a DNS name? Responses returned on "DNS name" query can contain arbitrary string independent from deployed DNS infrastructure. For example, any node can respond with DNS name "foo.example.org" without example.org administrator's knowledge. This is also true for reverse DNS mapping based on PTR records. 3.2. Consistency with forward DNS records? We cannot assume consistency with forward DNS records. It is the same as DNS PTR records. With scoped IPv6 address, it is not possible to keep consistency between forward and reverse mapping (both with DNS PTR records and ICMPv6 node information queries), as it is discouraged to put scoped IPv6 address into global DNS database, and there is no DNS PTR delegation for scoped IPv6 addresses. 3.3. Number of configured elements? With DNS PTR records, the reverse address mapping needs to be configured on DNS server. With ICMPv6 node information query, all nodes need to be configured with fully-qualified DNS name. 3.4. Interaction with scoped IPv6 addresses DNS PTR records do not support scoped IPv6 addresses well, due to the following reasons: o DNS database is a global database in nature, and does not fit well with scoped IPv6 address. o ip6.arpa (or ip6.int) delegation structure does not deal with scoped delegation. ITOJUN Expires: November 17, 2002 [Page 3] DRAFT ICMPv6 node info query for reverse DNS lookup May 2002 o The view of scope zones differs from nodes to nodes. Therefore, if the querier node of DNS PTR record is different from the node holding DNS PTR database, they have different idea about/access to scope zones. o There is no way to differentiate between scope zones, specifically from remote. ICMPv6 node information query/reply handles scoped IPv6 address well, as the querier directly tries to obtain reverse name mapping (hence there is no difference in the view of scope zones). Even with ICMPv6 node information query/reply, it is not possible to provide a consistent mapping between forward and reverse lookup for scoped IPv6 addresses, as DNS wire packet format (AAAA) does not have a way to identify scope zones. 4. Security consideration 4.1. Are there any possibility for forgery? Yes. Intermediate nodes can intercept node information query/reply packet and throw in forged queries/replies. It is true for DNS query/reply too. There are ongoing efforts in DNS arena for data integrity protection - DNSSEC. It is a bit hard to do similar thing for node information query. DNSSEC is possible because there is NS delegation tree in DNS. There is no obvious "structure" in node information query. 4.2. Use of reverse DNS mapping for authentication As documented in [Senie, 2001] it is discouraged to use the existence of reverse DNS mapping as authentication. References Crawford, 2002. Matt Crawford, "IPv6 Node Information Queries" in draft-ietf-ipngwg- icmp-name-lookups-09.txt (May 2002). work in progress material. Senie, 2001. Daniel Senie, "Requiring DNS IN-ADDR Mapping" in draft-ietf-dnsop- inaddr-required-02.txt (July 2001). work in progress material. Change history None. ITOJUN Expires: November 17, 2002 [Page 4] DRAFT ICMPv6 node info query for reverse DNS lookup May 2002 Acknowledgements (to be filled) Author's address Jun-ichiro itojun HAGINO Research Laboratory, Internet Initiative Japan Inc. Takebashi Yasuda Bldg., 3-13 Kanda Nishiki-cho, Chiyoda-ku,Tokyo 101-0054, JAPAN Tel: +81-3-5259-6350 Fax: +81-3-5259-6351 Email: itojun@iijlab.net ITOJUN Expires: November 17, 2002 [Page 5] ------- =_aaaaaaaaaa0-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 10 19:37:13 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5B2bDk7009134; Mon, 10 Jun 2002 19:37:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5B2bDKk009133; Mon, 10 Jun 2002 19:37:13 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5B2b9k7009126 for ; Mon, 10 Jun 2002 19:37:10 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA11989 for ; Mon, 10 Jun 2002 19:37:14 -0700 (PDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA14974 for ; Mon, 10 Jun 2002 19:37:13 -0700 (PDT) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g5B2abIZ003722; Mon, 10 Jun 2002 19:36:37 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ABV48573; Mon, 10 Jun 2002 19:33:40 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id TAA11153; Mon, 10 Jun 2002 19:36:36 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15621.25139.902578.605910@thomasm-u1.cisco.com> Date: Mon, 10 Jun 2002 19:36:35 -0700 (PDT) To: "James Kempf" Cc: "Steven M. Bellovin" , "Jari Arkko" , "Pekka Savola" , Subject: Re: Securing Neighbor Discovery BOF In-Reply-To: <002f01c210af$df9ec240$246015ac@T23KEMPF> References: <20020609141117.0B9717B4B@berkshire.research.att.com> <002f01c210af$df9ec240$246015ac@T23KEMPF> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk James Kempf writes: > So is it the case then that there would be no change in IPsec policy > required for doing AAA-based or roaming consortia-based key management? > Is so, then perhaps this problem is fairly straightforward to solve. Which working group has this in their charter? Mike -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 10 20:12:15 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5B3CFk7009208; Mon, 10 Jun 2002 20:12:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5B3CFJL009207; Mon, 10 Jun 2002 20:12:15 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5B3CAk7009200 for ; Mon, 10 Jun 2002 20:12:11 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA29817 for ; Mon, 10 Jun 2002 20:12:14 -0700 (PDT) From: john.loughney@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA25561 for ; Mon, 10 Jun 2002 20:12:13 -0700 (PDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g5B3Cdi11279 for ; Tue, 11 Jun 2002 06:12:39 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 11 Jun 2002 06:12:12 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 11 Jun 2002 06:12:12 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: finalizing cellular hosts document, version -03 now out Date: Tue, 11 Jun 2002 06:12:11 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC653C7@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: finalizing cellular hosts document, version -03 now out Thread-Index: AcIQrQtTyTua/pL/S/SlYMG3b1u4EgASLPxw To: , X-OriginalArrivalTime: 11 Jun 2002 03:12:12.0340 (UTC) FILETIME=[C7B5AF40:01C210F5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5B3CBk7009201 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, Actually, it was announced yesterday, so it can now be found here: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-cellular-host-03.txt John > -----Original Message----- > From: ext Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: 07 June, 2002 16:18 > To: ipng@sunroof.eng.sun.com > Subject: finalizing cellular hosts document, version -03 now out > > > > Version -03 of the cellular host document has now been published. > You can download it from > > http://www-nrc.nokia.com/sua/draft-ietf-ipv6-cellular-host-03.txt > > http://www-nrc.nokia.com/sua/draft-ietf-ipv6-cellular-host-03- > pa10.doc (with edits) > > Jari > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 10 20:48:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5B3mik7009236; Mon, 10 Jun 2002 20:48:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5B3migd009235; Mon, 10 Jun 2002 20:48:44 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5B3mfk7009228 for ; Mon, 10 Jun 2002 20:48:41 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA04903 for ; Mon, 10 Jun 2002 20:48:42 -0700 (PDT) Received: from drugs.dv.isc.org (drugs.dv.isc.org [130.155.191.236]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA18066 for ; Mon, 10 Jun 2002 21:48:36 -0600 (MDT) Received: from drugs.dv.isc.org (localhost.dv.isc.org [127.0.0.1]) by drugs.dv.isc.org (8.12.3/8.12.3) with ESMTP id g5B3lnm0004460; Tue, 11 Jun 2002 13:47:49 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200206110347.g5B3lnm0004460@drugs.dv.isc.org> To: Keith Moore Cc: "Tony Hain" , "Steven M. Bellovin" , "Pekka Savola" , "Ralph Droms" , ipng@sunroof.eng.sun.com From: Mark.Andrews@isc.org Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-reply-to: Your message of "Mon, 10 Jun 2002 11:13:30 -0400." <200206101513.g5AFDUn07424@astro.cs.utk.edu> Date: Tue, 11 Jun 2002 13:47:49 +1000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > In any > > case, the only way a DNS server should return a SL in a response is if > > the query was received on a SL. This is the only reasonable way for the > > server to know if the answer is usable. > > it doesn't work in general, because the query could be from a cache > that doesn't know anything about SL. > > putting limited-scope addrs in DNS is a Bad Idea, period. No. Putting limited-scope addrs in DNS is a bad idea *unless* you have a way to uniquely identify the scope. Neither AAAA or A6 provide support for this. I made a proposal that would have added this to A6 *before* there was any A6 deployment. It got totally ignored by the IPv6 community (with the exception of Matt). Now might be a good time to raise the idea again except I won't tie it to A6. SA SA scoped address scopename is a domainname choosen to be globally unique. global addresses have a scopename of ".". the conversion from scopename to scopeid / zoneid is a *local* resolution problem for the machine. Mark > > Keith > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@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 Mon Jun 10 21:12:19 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5B4CIk7009286; Mon, 10 Jun 2002 21:12:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5B4CIXG009285; Mon, 10 Jun 2002 21:12:18 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5B4CEk7009278 for ; Mon, 10 Jun 2002 21:12:14 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA10028 for ; Mon, 10 Jun 2002 21:12:17 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA25763 for ; Mon, 10 Jun 2002 22:12:16 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5B49On28896; Tue, 11 Jun 2002 00:09:24 -0400 (EDT) Message-Id: <200206110409.g5B49On28896@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Mark.Andrews@isc.org cc: Keith Moore , "Tony Hain" , "Steven M. Bellovin" , "Pekka Savola" , "Ralph Droms" , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-reply-to: (Your message of "Tue, 11 Jun 2002 13:47:49 +1000.") <200206110347.g5B3lnm0004460@drugs.dv.isc.org> Date: Tue, 11 Jun 2002 00:09:24 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > In any > > > case, the only way a DNS server should return a SL in a response is if > > > the query was received on a SL. This is the only reasonable way for the > > > server to know if the answer is usable. > > > > it doesn't work in general, because the query could be from a cache > > that doesn't know anything about SL. > > > > putting limited-scope addrs in DNS is a Bad Idea, period. > > No. > > Putting limited-scope addrs in DNS is a bad idea *unless* > you have a way to uniquely identify the scope. since there is no notion of a scope identifier in the Internet architecure, what you are saying is tantamount to saying that putting limited-scope addresses in the DNS is a bad idea. > Now might be a good time to raise the idea again except I won't > tie it to A6. > > SA > > SA scoped address > scopename is a domainname choosen to be globally unique. > global addresses have a scopename of ".". > > the conversion from scopename to scopeid / zoneid is a > *local* resolution problem for the machine. great - so let's add a lot of complexity to every application just so we can get no additional functionality and reduced reliability. let's stamp out SL addresses, now. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 10 23:14:52 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5B6Epk7009425; Mon, 10 Jun 2002 23:14:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5B6Epax009424; Mon, 10 Jun 2002 23:14:51 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5B6Emk7009417 for ; Mon, 10 Jun 2002 23:14:48 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA29514 for ; Mon, 10 Jun 2002 23:14:53 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA24155 for ; Mon, 10 Jun 2002 23:14:52 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g5B6E7B18446; Tue, 11 Jun 2002 09:14:07 +0300 Date: Tue, 11 Jun 2002 09:14:06 +0300 (EEST) From: Pekka Savola To: Robert Elz cc: Ralph Droms , Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-Reply-To: <6351.1023708931@munnari.OZ.AU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 10 Jun 2002, Robert Elz wrote: > Date: Mon, 10 Jun 2002 12:42:10 +0300 (EEST) > From: Pekka Savola > Message-ID: > > | Bit pattern is not relevant of course (except how it is handled by > | "legacy" implementations, which is why I tossed 3ffe:eff3::/32 in the > | air). > > But how is the handling by legacy implementations any different than > what you would require anyway? I don't know what assumptions different implementations might have glued in to fec0::/8, but selecting a different one would mean it would be treated as global no matter what. (I don't think there would really be problems even if fec0::/8 was used.) > | What I'd like is that there wouldn't need to be special handling for > | site-local addresses. > > How can there not be? By limiting the applicability of the addresses. > | If you really wanted to have Site Border Routers, > | you would just be shooting in your own foot (like with 10.0.0.0/8 etc. > | today). > > If there are to be uses of non-unique addressing (site locals, 1918's > or anything else) then there has to be borders. And if there are > borders, then there has to be border routers. Something has to keep > one use of the addresses separate from others. Sure. > Perhaps what you want to discourage is multi-site nodes ? > (Usually would be a router, but doesn't have to be). Yes. RFC1918 model has not required changes to routing protocols, partially because we acknowledge "you can always shoot in your foot". Now with IPv6 site-locals, it seems we want to add features to e.g. routing protocols to (try to) prevent that, which leads more complexity. > Two was to have only single site nodes, only single site links, and > non-site links (DMZs) between sites. This seems the best to me IMO. > However, upon reflection, there is comparatively little to be gained > by that choice over the third one (some things get simpler to explain > while the lack of regularity makes others harder to fathom, and some > stuff becomes simply impossible to manage - like if two sites are > connected via a router that has LANS for each site connected to it, > there's no convenient link to make be the DMZ). In more complex topologies, one could always just enforce globals and be done with it. > Scoping has to exist for link locals to work anyway, and so routers need > to deal with that (and link locals, and their properties, are too deeply > ingrained now to possibly contemplate their removal). By their very > nature, link locals require multi-scope nodes to exist, or we could not > have routers at all. Sure, but the link scope is rather easily defined, and the addresses of link scope are meaningless outside of the link (ie. no need to carry them in routing protocols). > The only real difference between 2 & 3 above for implementations, given > that apps can run on "routers" and that apps need to be able to use link > local addressing if necessary (for the unconnected dentist's office nets) I'm not sure if link-locals is the right way to go in this particular case. > so all the scoping architecture needs to exist - all that would be gained > is that in (2) a router would have a different decision to make before > forwarding site local addresses - rather than "is this link in the same > site?" it would need to ask "is this link in a DMZ?" A question is, is the scoping architecture required for only link-local addresses more lightweigh than one for both LL's and e.g. site-locals. > In IPv4 we just ignore the question mostly - a node with two global > addresses we just toss a coin. And nodes with private addresses mostly > just don't get given global addresses (and/or the two are treated for > essentially all purposes as if they belonged to two different nodes). > > For IPv6 we're being asked to actually attempt to provide some answers > to this question - as essentially all nodes (certainly the vast majority) > with private addresses will also have global ones. The thing is, how usable is it to try to solve this problem, at least in its most generic form? I'm not all that certain it's all that beneficial. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 10 23:18:20 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5B6IKk7009453; Mon, 10 Jun 2002 23:18:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5B6IK6b009452; Mon, 10 Jun 2002 23:18:20 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5B6IHk7009445 for ; Mon, 10 Jun 2002 23:18:17 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA00095 for ; Mon, 10 Jun 2002 23:18:21 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA11825 for ; Tue, 11 Jun 2002 00:18:20 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g5B6IH118479; Tue, 11 Jun 2002 09:18:18 +0300 Date: Tue, 11 Jun 2002 09:18:17 +0300 (EEST) From: Pekka Savola To: Alain Durand cc: ipng@sunroof.eng.sun.com Subject: Re: IPv6 Scoped Addresses and Routing Protocols In-Reply-To: <0D87F839-7CBB-11D6-AC39-00039376A6AA@sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 10 Jun 2002, Alain Durand wrote: > Today, with IPv4+NAT on my home network, I simply point my > stub-resolvers to my ISP DNS resolver. It's simple, and works > fine, at least until I try to do reverse DNS lookup for my internal > addresses. You could run your own authorative DNS server in your router/firewall/whatever. That's what I do. That isn't really a recipe for the masses, but if that's all it takes, I guess router vendors might implement something like that. > Then it just fails. Some applications that I run on > my local LAN don't work well or wait forever for timeouts, > because they can not resolve 1.1.168 .192.in-addr.arpa. > If I had enough IPv4 address space, I could get my ISP > to populate the DNS reverse maps, and my problem would > be solved. Wildcard records (shudder) ? -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 11 02:10:36 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5B9Aak7009662; Tue, 11 Jun 2002 02:10:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5B9AZSm009661; Tue, 11 Jun 2002 02:10:35 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5B9AWk7009654 for ; Tue, 11 Jun 2002 02:10:32 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA28324 for ; Tue, 11 Jun 2002 02:10:36 -0700 (PDT) Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.211]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA04764 for ; Tue, 11 Jun 2002 03:12:13 -0600 (MDT) Received: from tarski.cs.uni-bonn.de (tarski.cs.uni-bonn.de [131.220.4.200]) by theory.cs.uni-bonn.de (8.9.1a/8.9.1) with ESMTP id LAA23701 for ; Tue, 11 Jun 2002 11:10:34 +0200 (MET DST) Received: (from ignatios@localhost) by tarski.cs.uni-bonn.de (8.9.1a/8.9.1) id LAA21615 for ipng@sunroof.eng.sun.com; Tue, 11 Jun 2002 11:09:57 +0200 (CEST) Date: Tue, 11 Jun 2002 11:09:57 +0200 From: Ignatios Souvatzis Cc: ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols Message-ID: <20020611110957.A21584@tarski.cs.uni-bonn.de> References: <20020610105501.E17133@tarski.cs.uni-bonn.de> <200206101745.g5AHjHZs022737@thunk.east.sun.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="7JfCtLOvnd9MIVvH" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200206101745.g5AHjHZs022737@thunk.east.sun.com>; from sommerfeld@east.sun.com on Mon, Jun 10, 2002 at 01:45:16PM -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --7JfCtLOvnd9MIVvH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jun 10, 2002 at 01:45:16PM -0400, Bill Sommerfeld wrote: > It's also worth pointing out that NAT is not the only way a > site-local-only system could get external connectivity. >=20 > A transport-layer gateway/relay like a socks implementation for v6 or > the KAME "faithd" would be another way.. faithd does NAT while changing the address family at the same time, doesn't= =20 it? -is --7JfCtLOvnd9MIVvH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: 2.6.i iQEVAgUBPQW+YjCn4om+4LhpAQEG3gf/ViZNSBjS8ToRc27/LkFb+D9WYX12+vjg fnH7ljXHKvIN4KXqzKRhacV55jFu3xi1KxkpH1+chuQqwH3il4vM6kCATgjfpxqn 290heb9X0tm8FceDRmZphvnKuLYxrnhs+oDDiQi2MZH+KQKItX+gZ/MA6Mru3G2H E3A51L3LXvcS1uhya1RAgNv/vwVQhyHGnOcp4xgmFpND2Cy/ffjtXhlxb7ecuB1/ YWTyvHCM9AgoLgu7L/rZFA4l5K67ElDRbwOg9SLmZcCW2sBjcjwoqyezT4E1OWmE QL/fenfx5ae4Knwf/h7VMvN7bTtskxQcU9jACEF/jeU9IqwlPB+xyw== =+5GR -----END PGP SIGNATURE----- --7JfCtLOvnd9MIVvH-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 11 03:49:36 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BAnZk7009755; Tue, 11 Jun 2002 03:49:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5BAnZWH009754; Tue, 11 Jun 2002 03:49:35 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BAnVk7009747 for ; Tue, 11 Jun 2002 03:49:32 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA15790 for ; Tue, 11 Jun 2002 03:49:31 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA09564 for ; Tue, 11 Jun 2002 04:49:26 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g5BA4cX13307; Tue, 11 Jun 2002 12:04:43 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id MAA18491; Tue, 11 Jun 2002 12:04:38 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g5BA4bT99998; Tue, 11 Jun 2002 12:04:37 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200206111004.g5BA4bT99998@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Robert Elz cc: Brian Haberman , Margaret Wasserman , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-reply-to: Your message of Mon, 10 Jun 2002 18:40:15 +0700. <6367.1023709215@munnari.OZ.AU> Date: Tue, 11 Jun 2002 12:04:37 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: | PS: to put a random thing in the unused part of site-locals was proposed | twice and rejected twice... It was rejected once, when I made it, because it wasn't really a very well thought out proposal (the rejection was largely based upon administrative kinds of issues, rather than anything related to IPv6 as a protocol, etc). => I believe Christian Huitema still reads this list so can comment. The second time, I don't think it was rejected, it just sort of fizzled out, or that's how it appeared to me. I'm pretty sure the draft will have long expired, but I still regard the proposal as open. => the second time was more recent so I remember exactly what happened: Paul Francis' proposal was killed by Steve Deering with an incredible unfair question about "what is a site?" As nobody withdraws drafts (we just let them expire) it is hard to analyze old failures... Regards Francis.Dupont@enst-bretagne.fr PS: my opinion is site-locals should be reserved to never connected (never = today and at any time in the future) not-gigantic (i.e. one site is enough) organizations. In fact for unicasts we don't need more than link-locals and globals... -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 11 03:54:14 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BAsEk7009772; Tue, 11 Jun 2002 03:54:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5BAsE12009771; Tue, 11 Jun 2002 03:54:14 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BAsBk7009764 for ; Tue, 11 Jun 2002 03:54:11 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA16194 for ; Tue, 11 Jun 2002 03:54:13 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA14227 for ; Tue, 11 Jun 2002 04:55:49 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g5B9idX12195; Tue, 11 Jun 2002 11:45:40 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id LAA18284; Tue, 11 Jun 2002 11:44:39 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g5B9idT99837; Tue, 11 Jun 2002 11:44:39 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200206110944.g5B9idT99837@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Randy Bush cc: "Steven M. Bellovin" , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-reply-to: Your message of Mon, 10 Jun 2002 04:06:39 PDT. Date: Tue, 11 Jun 2002 11:44:39 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: >> But as site is rather vaguely defined, I think many vendors just skip >> this little detail.. > I disagree: we have a similar but more complex issue for multicast > forwarding and the zone boundary check is very easy to implement cool. how do you detect that you are at the edge of a site? => no detection but static configuration... Technically this is easy to implement, of course the question whether this is easy to manage is very different (BTW I am on the "site-local == private for never connected sites" side from the beginning). Regards Francis.Dupont@enst-bretagne.fr PS: IMHO to reopen the site-local addressing question for the third time (at least) is a good idea *only* if we have a reasonable chance to reach a consensus. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 11 04:06:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BB6Zk7009802; Tue, 11 Jun 2002 04:06:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5BB6YGw009801; Tue, 11 Jun 2002 04:06:34 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BB6Uk7009794 for ; Tue, 11 Jun 2002 04:06:30 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA06705 for ; Tue, 11 Jun 2002 04:06:33 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA03874 for ; Tue, 11 Jun 2002 04:06:32 -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 HAA17796; Tue, 11 Jun 2002 07:05:56 -0400 (EDT) Message-Id: <200206111105.HAA17796@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-scoping-arch-04.txt Date: Tue, 11 Jun 2002 07:05:56 -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 IP Version 6 Working Group Working Group of the IETF. Title : IPv6 Scoped Address Architecture Author(s) : S. Deering, B. Haberman, T. Jinmei, E. Nordmark, A. Onoe, B. Zill Filename : draft-ietf-ipngwg-scoping-arch-04.txt Pages : 19 Date : 10-Jun-02 This document specifies the architectural characteristics, expected behavior, textual representation, and usage of IPv6 addresses of different scopes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-scoping-arch-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-scoping-arch-04.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-scoping-arch-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020610143026.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-scoping-arch-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-scoping-arch-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020610143026.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 Jun 11 04:06:29 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BB6Tk7009792; Tue, 11 Jun 2002 04:06:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5BB6TNo009791; Tue, 11 Jun 2002 04:06:29 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BB6Pk7009784 for ; Tue, 11 Jun 2002 04:06:25 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA06688 for ; Tue, 11 Jun 2002 04:06:27 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA19229 for ; Tue, 11 Jun 2002 04:06:26 -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 HAA17778; Tue, 11 Jun 2002 07:05:51 -0400 (EDT) Message-Id: <200206111105.HAA17778@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-ipv6-router-selection-02.txt Date: Tue, 11 Jun 2002 07:05:50 -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 IP Version 6 Working Group Working Group of the IETF. Title : Default Router Preferences, More-Specific Routes and Load Sharing Author(s) : R. Draves, B. Hinden Filename : draft-ietf-ipv6-router-selection-02.txt Pages : 13 Date : 10-Jun-02 This document describes two changes to Neighbor Discovery. The first change is an optional extension to Router Advertisement messages for communicating default router preferences and more-specific routes from routers to hosts. This improves the ability of hosts to pick an appropriate router, especially when the host is multi-homed and the routers are on different links. The preference values and specific routes advertised to hosts require administrative configuration; they are not automatically derived from routing tables. The second change is a mandatory modification of the conceptual sending algorithm to support load-sharing among equivalent routers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-router-selection-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipv6-router-selection-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-ipv6-router-selection-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: <20020610143015.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-router-selection-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-router-selection-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020610143015.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 Jun 11 06:47:05 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BDl4k7010044; Tue, 11 Jun 2002 06:47:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5BDl4Ge010043; Tue, 11 Jun 2002 06:47:04 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BDl1k7010036 for ; Tue, 11 Jun 2002 06:47:01 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA13125 for ; Tue, 11 Jun 2002 06:46:52 -0700 (PDT) From: rbrabson@us.ibm.com Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA25766 for ; Tue, 11 Jun 2002 07:48:29 -0600 (MDT) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.us.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.12.2/8.12.2) with ESMTP id g5BDkkRY064350; Tue, 11 Jun 2002 09:46:49 -0400 Received: from d04nm200.raleigh.ibm.com (d04nm200.raleigh.ibm.com [9.67.226.57]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5BDkj655984; Tue, 11 Jun 2002 09:46:45 -0400 Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols To: Mark.Andrews@isc.org, ipng@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Tue, 11 Jun 2002 09:46:34 -0400 X-MIMETrack: Serialize by Router on D04NM200/04/M/IBM(Build M13TT_05222002 Pre-release 2|May 22, 2002) at 06/11/2002 09:46:45 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=0ABBE146DFD818728f9e8a93df938690918c0ABBE146DFD81872" Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --0__=0ABBE146DFD818728f9e8a93df938690918c0ABBE146DFD81872 Content-type: text/plain; charset=US-ASCII On Tuesday, 06/11/2002 at 01:47ZE10, Mark.Andrews@isc.org wrote: > Putting limited-scope addrs in DNS is a bad idea *unless* > you have a way to uniquely identify the scope. > > Neither AAAA or A6 provide support for this. I made a proposal > that would have added this to A6 *before* there was any A6 > deployment. It got totally ignored by the IPv6 community (with > the exception of Matt). > > Now might be a good time to raise the idea again except I won't > tie it to A6. > > SA > > SA scoped address > scopename is a domainname choosen to be globally unique. > global addresses have a scopename of ".". > > the conversion from scopename to scopeid / zoneid is a > *local* resolution problem for the machine. So, to make SL work, we need changes to the DNS name server, changes to the resolver, routers to advertise the scope zones, hosts to learn the scope zones from routers and include them on DDNS registrations and use them in making routing decisions, updates to routing protocols, IANA needs to manage a new zone scope naming space, and who knows what else. Wouldn't it make sense to hold off on SL until we at least have some proposals on the table which describe the changes necessary to make SL work, at which time we could have a discussion on the technical merits of the proposal(s)? Until that time, though, the SL unicast address space should either be reserved or moved to experimental. Roy --0__=0ABBE146DFD818728f9e8a93df938690918c0ABBE146DFD81872 Content-type: text/html; charset=US-ASCII Content-Disposition: inline On Tuesday, 06/11/2002 at 01:47ZE10, Mark.Andrews@isc.org wrote:
> Putting limited-scope addrs in DNS is a bad idea *unless*
> you have a way to uniquely identify the scope.
>
> Neither AAAA or A6 provide support for this.  I made a proposal
> that would have added this to A6 *before* there was any A6
> deployment.  It got totally ignored by the IPv6 community (with
> the exception of Matt).
>
> Now might be a good time to raise the idea again except I won't
> tie it to A6.
>
> <ownername> SA <IPV6 address> <scopename>
>
> SA  scoped address
> scopename is a domainname choosen to be globally unique.
>  global addresses have a scopename of ".".
>
> the conversion from scopename to scopeid / zoneid is a
> *local* resolution problem for the machine.

So, to make SL work, we need changes to the DNS name server, changes
to the resolver, routers to advertise the scope zones, hosts to
learn the scope zones from routers and include them on DDNS
registrations and use them in making routing decisions, updates to
routing protocols, IANA needs to manage a new zone scope naming
space, and who knows what else.

Wouldn't it make sense to hold off on SL until we at least have
some proposals on the table which describe the changes necessary to
make SL work, at which time we could have a discussion on the
technical merits of the proposal(s)?  Until that time, though, the
SL unicast address space should either be reserved or moved to
experimental.

Roy --0__=0ABBE146DFD818728f9e8a93df938690918c0ABBE146DFD81872-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 11 08:16:31 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BFGVk7010256; Tue, 11 Jun 2002 08:16:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5BFGVoH010255; Tue, 11 Jun 2002 08:16:31 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BFGRk7010248 for ; Tue, 11 Jun 2002 08:16:27 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA10583 for ; Tue, 11 Jun 2002 08:16:30 -0700 (PDT) Received: from mail-blue.research.att.com (H-135-207-30-102.research.att.com [135.207.30.102]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA23110 for ; Tue, 11 Jun 2002 09:16:29 -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 2FD194CE3F; Tue, 11 Jun 2002 11:16:29 -0400 (EDT) Received: from berkshire.research.att.com (postal.research.att.com [135.207.23.30]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id LAA07408; Tue, 11 Jun 2002 11:11:10 -0400 (EDT) Received: from research.att.com (localhost [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id F31F77B53; Tue, 11 Jun 2002 11:05:25 -0400 (EDT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: "Steven M. Bellovin" To: rbrabson@us.ibm.com Cc: ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 11 Jun 2002 11:05:25 -0400 Message-Id: <20020611150526.F31F77B53@berkshire.research.att.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message , rbrabson@us.ib m.com writes: >So, to make SL work, we need changes to the DNS name server, changes >to the resolver, routers to advertise the scope zones, hosts to >learn the scope zones from routers and include them on DDNS >registrations and use them in making routing decisions, updates to >routing protocols, IANA needs to manage a new zone scope naming >space, and who knows what else. > >Wouldn't it make sense to hold off on SL until we at least have >some proposals on the table which describe the changes necessary to >make SL work, at which time we could have a discussion on the >technical merits of the proposal(s)? Until that time, though, the >SL unicast address space should either be reserved or moved to >experimental. > I think this is the key point. Regardless of the possible benefits of site-local addresses -- and I'm willing to withhold judgment on that point -- we don't know in detail how to make them work. At a minimum, we need changes in routing and the DNS. We may need new global namespaces as well, with all that implies for co-ordination and administrative overhead. --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com ("Firewalls" book) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 11 09:08:02 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BG81k7010390; Tue, 11 Jun 2002 09:08:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5BG81pk010389; Tue, 11 Jun 2002 09:08:01 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BG7wk7010382 for ; Tue, 11 Jun 2002 09:07:58 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA00385 for ; Tue, 11 Jun 2002 09:08:01 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA20847 for ; Tue, 11 Jun 2002 10:08:00 -0600 (MDT) Message-ID: <003d01c21161$dab65ec0$246015ac@T23KEMPF> From: "James Kempf" To: "Michael Thomas" Cc: "Steven M. Bellovin" , "Jari Arkko" , "Pekka Savola" , References: <20020609141117.0B9717B4B@berkshire.research.att.com><002f01c210af$df9ec240$246015ac@T23KEMPF> <15621.25139.902578.605910@thomasm-u1.cisco.com> Subject: Re: Securing Neighbor Discovery BOF Date: Tue, 11 Jun 2002 09:05:49 -0700 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 None that I know of. I didn't mean to suggest that this should be a chartered item, that is for the BOF to decide. Any solution to IPsec key distribution that does not involve IKE (due to chicken and egg problem) or manual keying (due to inconvenience for large scale public access networks) should be on the table at this point, in addition to other techniques, such as CGAs. jak ----- Original Message ----- From: "Michael Thomas" To: "James Kempf" Cc: "Steven M. Bellovin" ; "Jari Arkko" ; "Pekka Savola" ; Sent: Monday, June 10, 2002 7:36 PM Subject: Re: Securing Neighbor Discovery BOF > James Kempf writes: > > So is it the case then that there would be no change in IPsec policy > > required for doing AAA-based or roaming consortia-based key management? > > Is so, then perhaps this problem is fairly straightforward to solve. > > Which working group has this in their charter? > > Mike > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Jun 11 09:21:42 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BGLfk7010438; Tue, 11 Jun 2002 09:21:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5BGLflW010437; Tue, 11 Jun 2002 09:21:41 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BGLck7010430 for ; Tue, 11 Jun 2002 09:21:38 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA06439 for ; Tue, 11 Jun 2002 09:21:42 -0700 (PDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA29439 for ; Tue, 11 Jun 2002 09:21:41 -0700 (PDT) Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.194.24]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g5BGL9g5087796 for ; Tue, 11 Jun 2002 12:21:13 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.9.21]) by westrelay03.boulder.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5BGL9s190560 for ; Tue, 11 Jun 2002 10:21:09 -0600 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id g5BGJGv08724 for ; Tue, 11 Jun 2002 12:19:16 -0400 Message-Id: <200206111619.g5BGJGv08724@rotala.raleigh.ibm.com> To: ipng@sunroof.eng.sun.com Subject: IESG comments on draft-ietf-ipngwg-default-addr-select-06.txt Date: Tue, 11 Jun 2002 12:19:16 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has a number of comments on this document. Most of them are of an editorial nature, and I'll let Rich summarize those in a separate note. One issue was substantive and requires WG feedback. The -06 document specifies that public addresses are to be preferred over temporary by default. My recollection is that the WG originally had temporary addresses being preferred, but more recently switched this under concerns that there were cases where the use of temporary addresses might harm an application. Thus, the conservative thing to do would be to prefer public addresses but allow the application (via an API) to reverse this preference. The IESG is concerned that if temporary addresses are not enabled by default, they won't see widespread use in practice. This would significantly decrease the overall impact that RFC 3041 will have on reducing the threat it attempts to address. What the IESG would prefer seeing is that temporary addresses be given preference by default, but also include more guidance text in the document to make it clear that there are cases where the use of temporary addresses by default may not be appropriate. The following text has been proposed to address this issue: Proposed new wording: Rule 7: Prefer public addresses. If SA is a temporary address and SB is a public address, then prefer SA. Similarly, if SB is a temporary address and SA is a public address, then prefer SB. An implementation MUST support a per-connection configuration mechanism (for example, an API extension) to reverse the sense of this preference and prefer public addresses over public addresses. In order for temporary addresses to have their desired effect, they must become widely used in practice. The above rule is designed to ensure widespread usage and enablement of temporary addresses. It is believed that in many cases, temporary addresses can be used in place of public addresses without problems. However, there are some classes of applications that may fail due to the relatively short lifetime of temporary addresses (compared with public addresses) or due to the possibility of the reverse lookup of a temporary address either failing or returning a randomized name. Implementations in which it is believed that such applications exist MAY reverse the sense of this rule and by default prefer public addresses over temporary addresses. It should also be noted that a simple "prefer" or "don't prefer" configuration switch with regards to the default selection of temporary addresses is not sufficiently flexible in many cases. In practice, it is expected that both client and server applications will run on the same devices simultaneously. Client applications will generally be able to use temporary addresses, while servers will generally need to use public addresses. One possible heuristic for distinguishing these cases is to assume that an application that invokes a passive open (as its first network usage) is a server, while an application that first invokes an active open be assumed to be a client. (Note also, that the above text changes a "may" to MUST with regards the need to provide a way for individual applications to change the default via, e.g, a socket option) Is the above a reasonable way forward? (Individual responses, even if they are along the lines of "fine with me" would be appreciated, as this document is needed soon to meet a 3GPP deadline). Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 11 10:00:13 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BH0Ck7010680; Tue, 11 Jun 2002 10:00:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5BH0CkC010679; Tue, 11 Jun 2002 10:00:12 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BH08k7010672 for ; Tue, 11 Jun 2002 10:00:08 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA14523 for ; Tue, 11 Jun 2002 10:00:12 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA21160 for ; Tue, 11 Jun 2002 11:00:11 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5BGxin22826; Tue, 11 Jun 2002 12:59:44 -0400 (EDT) Message-Id: <200206111659.g5BGxin22826@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Steven M. Bellovin" cc: rbrabson@us.ibm.com, ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-reply-to: (Your message of "Tue, 11 Jun 2002 11:05:25 EDT.") <20020611150526.F31F77B53@berkshire.research.att.com> Date: Tue, 11 Jun 2002 12:59:44 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I think this is the key point. Regardless of the possible benefits of > site-local addresses -- and I'm willing to withhold judgment on that > point -- we don't know in detail how to make them work. At a minimum, > we need changes in routing and the DNS. We may need new global > namespaces as well, with all that implies for co-ordination and > administrative overhead. and given that all that stuff is "needed", and the costs associated not just with this infrastructure but also of the increased burden on applications, it ought to raise a strong suspicion that SL addresses are not worth the cost. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 11 10:05:05 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BH55k7010714; Tue, 11 Jun 2002 10:05:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5BH55NS010713; Tue, 11 Jun 2002 10:05:05 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BH51k7010706 for ; Tue, 11 Jun 2002 10:05:01 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA16689 for ; Tue, 11 Jun 2002 10:05:05 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA27565 for ; Tue, 11 Jun 2002 10:05:05 -0700 (PDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5BH4rn23548; Tue, 11 Jun 2002 13:04:53 -0400 (EDT) Message-Id: <200206111704.g5BH4rn23548@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Thomas Narten cc: ipng@sunroof.eng.sun.com Subject: Re: IESG comments on draft-ietf-ipngwg-default-addr-select-06.txt In-reply-to: (Your message of "Tue, 11 Jun 2002 12:19:16 EDT.") <200206111619.g5BGJGv08724@rotala.raleigh.ibm.com> Date: Tue, 11 Jun 2002 13:04:52 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I believe that temporary addresses should be available, but they should NOT be enabled by default. Many applications will fail in odd ways if assigned a temporary address. Temporary addresses are best viewed as a tool which may enhance privacy but are not applicable to all situations. The best default for the API is to assign a stable address, and let those apps which can benefit from temporary addresses request them specifically. I respect the desire for temporary addresses (and AFAIK I was one of the first people to raise concerns about embedding tracable information in an IPv6 address) but I don't think it's a good idea to effectively change the API in a way that would break apps at this late date. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 11 10:16:43 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BHGhk7010742; Tue, 11 Jun 2002 10:16:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5BHGhS7010741; Tue, 11 Jun 2002 10:16:43 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BHGek7010734 for ; Tue, 11 Jun 2002 10:16:40 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA27587 for ; Tue, 11 Jun 2002 10:16:42 -0700 (PDT) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA09368 for ; Tue, 11 Jun 2002 11:16:41 -0600 (MDT) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id UAA30633; Tue, 11 Jun 2002 20:16:40 +0300 Date: Tue, 11 Jun 2002 20:16:40 +0300 Message-Id: <200206111716.UAA30633@burp.tkv.asdf.org> From: Markku Savela To: ipng@sunroof.eng.sun.com Subject: Re: IPv6 Scoped Addresses and Routing Protocols References: <200206111659.g5BGxin22826@astro.cs.utk.edu> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Well, I've not yet fully gotten into issue of getting site local addresses from the name server, but... ... I assume when a resolver gets an address as a reply from the DNS, it will supply the scope id from the interface which the DNS reply came in. And, this applies to all scope levels (consider, multicast groups could be in DNS too, with any of the 15 or so scope levels). Now, for this to truly work, the DNS server does need some extra code to deal with non-global scopes. The database must include the scope in some form (for example interface name), and it must not return replies of non-local addresses to other than indicated interface. However, this seems to be a local implementation issue, which does not change the protocol on the wire. I think similar considerations apply to routing protocols: the zone ids are always available from the interface which the packet is using. Of course, some system admin must configure them to the interface first. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 11 10:43:20 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BHhJk7010785; Tue, 11 Jun 2002 10:43:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5BHhJ1f010784; Tue, 11 Jun 2002 10:43:19 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BHhFk7010777 for ; Tue, 11 Jun 2002 10:43:15 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA02956 for ; Tue, 11 Jun 2002 10:43:17 -0700 (PDT) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA22364 for ; Tue, 11 Jun 2002 10:43:17 -0700 (PDT) Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 11 Jun 2002 10:43:17 -0700 Received: from 157.54.5.25 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 11 Jun 2002 10:43:17 -0700 Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 11 Jun 2002 10:43:12 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 11 Jun 2002 10:43:12 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3590.0); Tue, 11 Jun 2002 10:43:14 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6236.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: IPv6 Scoped Addresses and Routing Protocols Date: Tue, 11 Jun 2002 10:43:13 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC1047CF203@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv6 Scoped Addresses and Routing Protocols Thread-Index: AcIREFgxJ63oEx1pQaWilA4XjeUG/AAXn7bg From: "Dave Thaler" To: "Pekka Savola" , "Alain Durand" Cc: X-OriginalArrivalTime: 11 Jun 2002 17:43:14.0749 (UTC) FILETIME=[76886ED0:01C2116F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5BHhGk7010778 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] [...] > On Mon, 10 Jun 2002, Alain Durand wrote: > > Today, with IPv4+NAT on my home network, I simply point my > > stub-resolvers to my ISP DNS resolver. It's simple, and works > > fine, at least until I try to do reverse DNS lookup for my internal > > addresses. > > You could run your own authorative DNS server in your > router/firewall/whatever. That's what I do. That isn't really a recipe > for the masses, but if that's all it takes, I guess router vendors might > implement something like that. > > > Then it just fails. Some applications that I run on > > my local LAN don't work well or wait forever for timeouts, > > because they can not resolve 1.1.168 .192.in-addr.arpa. > > If I had enough IPv4 address space, I could get my ISP > > to populate the DNS reverse maps, and my problem would > > be solved. Personally I think DNS reverse lookups should go away, not site-locals. In my opinion, using ICMP name lookups to the node itself is a much better solution to making reverse lookups work, and they would work fine for scoped addresses. (Yes it would only work when the node is reachable, but I don't consider that a problem, whereas DNS has bigger problems.) -Dave -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 11 10:49:30 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BHnTk7010848; Tue, 11 Jun 2002 10:49:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5BHnTdG010847; Tue, 11 Jun 2002 10:49:29 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BHnOk7010833 for ; Tue, 11 Jun 2002 10:49:24 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA11475 for ; Tue, 11 Jun 2002 10:49:27 -0700 (PDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA26205 for ; Tue, 11 Jun 2002 10:49:26 -0700 (PDT) Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 11 Jun 2002 10:49:26 -0700 Received: from 157.54.8.155 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 11 Jun 2002 10:49:25 -0700 Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 11 Jun 2002 10:49:17 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 11 Jun 2002 10:49:16 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3604.0); Tue, 11 Jun 2002 10:49:16 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6236.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: IESG comments on draft-ietf-ipngwg-default-addr-select-06.txt Date: Tue, 11 Jun 2002 10:49:17 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC1047CF204@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IESG comments on draft-ietf-ipngwg-default-addr-select-06.txt Thread-Index: AcIRZN63DyDS5M0/Snm8w9IoE+VMCwACyhtQ From: "Dave Thaler" To: "Thomas Narten" , X-OriginalArrivalTime: 11 Jun 2002 17:49:16.0640 (UTC) FILETIME=[4E3C9E00:01C21170] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5BHnOk7010834 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Proposed new wording: > > Rule 7: Prefer public addresses. > > If SA is a temporary address and SB is a public address, then prefer > SA. [...] The rest of the line after "Rule 7" doesn't match the rest of the text. The rest of the new wording looks fine to me. -Dave -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 11 10:49:31 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BHnVk7010851; Tue, 11 Jun 2002 10:49:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5BHnVQW010850; Tue, 11 Jun 2002 10:49:31 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BHnPk7010840 for ; Tue, 11 Jun 2002 10:49:25 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA12834; Tue, 11 Jun 2002 13:49:28 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g5BHnRZs003547; Tue, 11 Jun 2002 13:49:27 -0400 (EDT) Message-Id: <200206111749.g5BHnRZs003547@thunk.east.sun.com> From: Bill Sommerfeld To: Thomas Narten cc: ipng@sunroof.eng.sun.com Subject: Re: IESG comments on draft-ietf-ipngwg-default-addr-select-06.txt In-Reply-To: Your message of "Tue, 11 Jun 2002 12:19:16 EDT." <200206111619.g5BGJGv08724@rotala.raleigh.ibm.com> Reply-to: sommerfeld@east.sun.com Date: Tue, 11 Jun 2002 13:49:27 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This comment is only on the heuristic: One possible heuristic for distinguishing these cases is to assume that an application that invokes a passive open (as its first network usage) is a server, while an application that first invokes an active open be assumed to be a client. My first reaction is that this heuristic is significantly flawed. The mapping between "application" and OS-visible objects (process/program) may not be 1:1; in particular, consider inetd on most unix systems -- common infrastructure code does the passive open, and the application isn't started until after the connection is established. Even in the case of single-process applications, the server may invoke some library routine during initialization might do an under-the-covers active open (e.g., getpwuid() or gethostbyaddr() to get a character string user or host name for a log entry). What's more, in the case of TCP, it's largely pointless -- TCP passive opens do not require source address selection at all. The networking API's I'm familiar with typically allow an application to open a port with wildcarded local address, or to specify the local address in addition to the port. In the former case, the peer picks the local address and it "sticks" for the life of the connection. In the case of datagram sockets (where there isn't a passive/active distinction), it might make sense to prefer permanent addresses if the first activity was the receipt of a packet. - Bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 11 10:53:54 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BHrrk7010925; Tue, 11 Jun 2002 10:53:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5BHrrrN010924; Tue, 11 Jun 2002 10:53:53 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BHrok7010917 for ; Tue, 11 Jun 2002 10:53:50 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA07665 for ; Tue, 11 Jun 2002 10:53:52 -0700 (PDT) Received: from mail6.microsoft.com (mail6.microsoft.com [131.107.3.126]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA29213 for ; Tue, 11 Jun 2002 10:53:52 -0700 (PDT) Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 11 Jun 2002 10:53:52 -0700 Received: from 157.54.8.23 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 11 Jun 2002 10:53:52 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 11 Jun 2002 10:53:52 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 11 Jun 2002 10:53:51 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3590.0); Tue, 11 Jun 2002 10:53:54 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6236.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: IPv6 Scoped Addresses and Routing Protocols Date: Tue, 11 Jun 2002 10:53:51 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC1047CF205@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv6 Scoped Addresses and Routing Protocols Thread-Index: AcIRbC9+LZyxiEXGQeu9g92ODyuIdwABGFcQ From: "Dave Thaler" To: "Markku Savela" , X-OriginalArrivalTime: 11 Jun 2002 17:53:54.0386 (UTC) FILETIME=[F3C94B20:01C21170] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5BHrok7010918 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > -----Original Message----- > From: Markku Savela [mailto:msa@burp.tkv.asdf.org] > Sent: Tuesday, June 11, 2002 10:17 AM > To: ipng@sunroof.eng.sun.com > Subject: Re: IPv6 Scoped Addresses and Routing Protocols > > Well, I've not yet fully gotten into issue of getting site local > addresses from the name server, but... > > ... I assume when a resolver gets an address as a reply from the DNS, > it will supply the scope id from the interface which the DNS reply > came in. And, this applies to all scope levels (consider, multicast > groups could be in DNS too, with any of the 15 or so scope levels). Correct. > Now, for this to truly work, the DNS server does need some extra code > to deal with non-global scopes. The database must include the scope in > some form (for example interface name), and it must not return replies > of non-local addresses to other than indicated interface. Or just implement Erik Nordmark's draft on the host and the DNS server doesn't need to do anything. This is the approach we prefer (not to say we have any objection to modifying the DNS server too, just that it can work without it). > However, this seems to be a local implementation issue, which does not > change the protocol on the wire. > > I think similar considerations apply to routing protocols: the zone > ids are always available from the interface which the packet is > using. Of course, some system admin must configure them to the > interface first. Correct. -Dave -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 11 11:02:43 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BI2hk7011033; Tue, 11 Jun 2002 11:02:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5BI2hbS011032; Tue, 11 Jun 2002 11:02:43 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BI2dk7011025 for ; Tue, 11 Jun 2002 11:02:40 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA16491; Tue, 11 Jun 2002 14:02:42 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g5BI2gZs003734; Tue, 11 Jun 2002 14:02:42 -0400 (EDT) Message-Id: <200206111802.g5BI2gZs003734@thunk.east.sun.com> From: Bill Sommerfeld To: Ignatios Souvatzis cc: ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-Reply-To: Your message of "Tue, 11 Jun 2002 11:09:57 +0200." <20020611110957.A21584@tarski.cs.uni-bonn.de> Reply-to: sommerfeld@east.sun.com Date: Tue, 11 Jun 2002 14:02:42 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > faithd does NAT while changing the address family at the same time, doesn't > it? No doubt one of the KAME folks will correct me but my impression was that it was more of a TCP-layer proxy rather than a layer-3 NAT. Regardless of how it works, it's one of many ways for a site-local-addresses-only node to get external connectivity. - Bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 11 11:13:05 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BID5k7011060; Tue, 11 Jun 2002 11:13:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5BID4fs011059; Tue, 11 Jun 2002 11:13:04 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BID0k7011052 for ; Tue, 11 Jun 2002 11:13:00 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA21473 for ; Tue, 11 Jun 2002 11:13:03 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA22886 for ; Tue, 11 Jun 2002 11:13:02 -0700 (PDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5BICxn26261; Tue, 11 Jun 2002 14:12:59 -0400 (EDT) Message-Id: <200206111812.g5BICxn26261@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Markku Savela cc: ipng@sunroof.eng.sun.com Subject: Re: IPv6 Scoped Addresses and Routing Protocols In-reply-to: (Your message of "Tue, 11 Jun 2002 20:16:40 +0300.") <200206111716.UAA30633@burp.tkv.asdf.org> Date: Tue, 11 Jun 2002 14:12:59 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is just insane. DNS is supposed to return the same results for everyone, not try to guess whether the client can use a particular address. The DNS server isn't even aware of where the client is attached to the net, nor about how many interfaces it has or where they're connected. It's simply not acceptable to add scope ids to addresses. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 11 11:17:02 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BIH2k7011104; Tue, 11 Jun 2002 11:17:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5BIH1kW011103; Tue, 11 Jun 2002 11:17:01 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BIGvk7011096 for ; Tue, 11 Jun 2002 11:16:58 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA29303 for ; Tue, 11 Jun 2002 11:17:00 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA12762; Tue, 11 Jun 2002 12:16:58 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5BIFen26282; Tue, 11 Jun 2002 14:15:40 -0400 (EDT) Message-Id: <200206111815.g5BIFen26282@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Dave Thaler" cc: "Pekka Savola" , "Alain Durand" , ipng@sunroof.eng.sun.com Subject: Re: IPv6 Scoped Addresses and Routing Protocols In-reply-to: (Your message of "Tue, 11 Jun 2002 10:43:13 PDT.") <2E33960095B58E40A4D3345AB9F65EC1047CF203@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Date: Tue, 11 Jun 2002 14:15:40 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Personally I think DNS reverse lookups should go away, not site-locals you mean you'd take away functionality that's actually *useful* in order to save a hack of dubious value? > In my opinion, using ICMP name lookups to the > node itself is a much better solution to making reverse > lookups work, and they would work fine for scoped addresses. the node's opinion of its name isn't the same piece of information as the network administrator's opinion of a node's name. you might be able to trust the network admin, but you certainly can't trust the node. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 11 11:23:04 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BIN4k7011149; Tue, 11 Jun 2002 11:23:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5BIN3sM011148; Tue, 11 Jun 2002 11:23:03 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BIN0k7011141 for ; Tue, 11 Jun 2002 11:23:00 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA25481 for ; Tue, 11 Jun 2002 11:23:03 -0700 (PDT) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA07255 for ; Tue, 11 Jun 2002 12:23:01 -0600 (MDT) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id VAA30811; Tue, 11 Jun 2002 21:22:46 +0300 Date: Tue, 11 Jun 2002 21:22:46 +0300 Message-Id: <200206111822.VAA30811@burp.tkv.asdf.org> From: Markku Savela To: moore@cs.utk.edu CC: ipng@sunroof.eng.sun.com In-reply-to: <200206111812.g5BICxn26261@astro.cs.utk.edu> (message from Keith Moore on Tue, 11 Jun 2002 14:12:59 -0400) Subject: Re: IPv6 Scoped Addresses and Routing Protocols References: <200206111812.g5BICxn26261@astro.cs.utk.edu> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: Keith Moore > DNS is supposed to return the same results for everyone, not try to > guess whether the client can use a particular address. The DNS server > isn't even aware of where the client is attached to the net, nor about > how many interfaces it has or where they're connected. Probably right, but sadly similar thing happens already with IPv4 10-nets. The local ISP's provide only 10/8 addressess (with NAT), and their DNS returns 10-addresses. Now if your host is connected simultaneously to two ISP's (for example first to local ISP to get access, and then virtually through a VPN tunnel to remote intranet, which also SADLY happens to use 10-addresses and own DNS servers). In this case you have to do similar "scope-id" things with IPv4 addresses, route queries to different DNS servers depending whether application is using ISP's addresses or intranet addresses (yes, host implementation GETS difficult). -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 11 11:30:04 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BIU2k7011253; Tue, 11 Jun 2002 11:30:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5BITx3M011250; Tue, 11 Jun 2002 11:29:59 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BITsk7011241 for ; Tue, 11 Jun 2002 11:29:54 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA04634 for ; Tue, 11 Jun 2002 11:29:57 -0700 (PDT) Received: from roam.psg.com (dhcp3202.nanog25.merit.net [192.35.167.202]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA10638 for ; Tue, 11 Jun 2002 12:29:56 -0600 (MDT) Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.04) id 17HqOs-0002fa-00; Tue, 11 Jun 2002 11:29:50 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Keith Moore Cc: Markku Savela , ipng@sunroof.eng.sun.com Subject: Re: IPv6 Scoped Addresses and Routing Protocols References: <200206111716.UAA30633@burp.tkv.asdf.org> <200206111812.g5BICxn26261@astro.cs.utk.edu> Message-Id: Date: Tue, 11 Jun 2002 11:29:50 -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > DNS is supposed to return the same results for everyone, not try to > guess whether the client can use a particular address. you may want to look a tdraft-ietf-dnsop-dontpublish-unreachable-03.txt and why and what it is trying to achieve. essentially, everyone does not have the same view of the address space. randy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 11 11:34:06 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BIY6k7011274; Tue, 11 Jun 2002 11:34:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5BIY6wl011273; Tue, 11 Jun 2002 11:34:06 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BIY2k7011265 for ; Tue, 11 Jun 2002 11:34:02 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA29313 for ; Tue, 11 Jun 2002 11:34:05 -0700 (PDT) Received: from roam.psg.com (dhcp3202.nanog25.merit.net [192.35.167.202]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA26202 for ; Tue, 11 Jun 2002 12:34:05 -0600 (MDT) Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.04) id 17HqSy-0002g1-00; Tue, 11 Jun 2002 11:34:05 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Keith Moore Cc: ipng@sunroof.eng.sun.com Subject: Re: IPv6 Scoped Addresses and Routing Protocols References: <2E33960095B58E40A4D3345AB9F65EC1047CF203@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> <200206111815.g5BIFen26282@astro.cs.utk.edu> Message-Id: Date: Tue, 11 Jun 2002 11:34:05 -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> In my opinion, using ICMP name lookups to the node itself is a much >> better solution to making reverse lookups work, and they would work fine >> for scoped addresses. cool knowing the intent of the icmp draft, isn't it? > the node's opinion of its name isn't the same piece of information as > the network administrator's opinion of a node's name. ^ cryptogtaphically signed can you say "name spoofing" randy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 11 11:41:38 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BIfbk7011294; Tue, 11 Jun 2002 11:41:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5BIfbV3011293; Tue, 11 Jun 2002 11:41:37 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BIfXk7011286 for ; Tue, 11 Jun 2002 11:41:33 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA09875 for ; Tue, 11 Jun 2002 11:41:36 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA00865 for ; Tue, 11 Jun 2002 12:41:35 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5BIfVn26455; Tue, 11 Jun 2002 14:41:31 -0400 (EDT) Message-Id: <200206111841.g5BIfVn26455@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Randy Bush cc: Keith Moore , Markku Savela , ipng@sunroof.eng.sun.com Subject: Re: IPv6 Scoped Addresses and Routing Protocols In-reply-to: (Your message of "Tue, 11 Jun 2002 11:29:50 PDT.") Date: Tue, 11 Jun 2002 14:41:30 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk it seems obvious in hindsight that private addresses were a mistake in IPv4. so the fact that they exist, and that we now find it necessary to warn people to not advertise them in DNS, shouldn't be cited as a justification to make further mistakes which will then necessitate further kludges to DNS. as for the idea that we need SL addresses for nonconnected sites - far better that we establish a new prefix for those addresses and allow IANA or the RIRs to dole out address blocks from that space, with the caveat that they will never be advertised on the public Internet (actually they should be filtered). they will still be useful for private connections between networks, and giving everyone a unique prefix whether they are connected or not will eliminate a big motivation to use NAT in IPv6. granted that still creates a kind of scoped address, but at least it's globally unique. I think it would be better to advertise addresses with non-routable prefixes in DNS than to advertise SLs in DNS, with all of the kludges that this would entail. at least a host or app should be able to tell rather quickly that a prefix is private and that it doesn't have a route to it. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 11 11:42:20 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BIgJk7011306; Tue, 11 Jun 2002 11:42:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5BIgJIS011305; Tue, 11 Jun 2002 11:42:19 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BIgFk7011298 for ; Tue, 11 Jun 2002 11:42:15 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA28585 for ; Tue, 11 Jun 2002 11:42:18 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA11155 for ; Tue, 11 Jun 2002 11:42:18 -0700 (PDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5BIgFn26478; Tue, 11 Jun 2002 14:42:15 -0400 (EDT) Message-Id: <200206111842.g5BIgFn26478@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Randy Bush cc: Keith Moore , ipng@sunroof.eng.sun.com Subject: Re: IPv6 Scoped Addresses and Routing Protocols In-reply-to: (Your message of "Tue, 11 Jun 2002 11:34:05 PDT.") Date: Tue, 11 Jun 2002 14:42:15 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > the node's opinion of its name isn't the same piece of information as > > the network administrator's opinion of a node's name. > ^ cryptogtaphically signed > > can you say "name spoofing" > either piece of information can be signed, but the two are still different pieces of information. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 11 12:02:36 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BJ2ak7011374; Tue, 11 Jun 2002 12:02:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5BJ2aa6011373; Tue, 11 Jun 2002 12:02: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.12.4/8.12.4) with ESMTP id g5BJ2Xk7011366 for ; Tue, 11 Jun 2002 12:02:33 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA09221 for ; Tue, 11 Jun 2002 12:02:36 -0700 (PDT) Received: from roam.psg.com (dhcp3202.nanog25.merit.net [192.35.167.202]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA11098 for ; Tue, 11 Jun 2002 13:02:36 -0600 (MDT) Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.04) id 17HquY-0002hr-00; Tue, 11 Jun 2002 12:02:34 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Keith Moore Cc: Markku Savela , ipng@sunroof.eng.sun.com Subject: Re: IPv6 Scoped Addresses and Routing Protocols References: <200206111841.g5BIfVn26455@astro.cs.utk.edu> Message-Id: Date: Tue, 11 Jun 2002 12:02:34 -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > it seems obvious in hindsight that private addresses were a mistake > in IPv4. so the fact that they exist, and that we now find it necessary > to warn people to not advertise them in DNS, shouldn't be cited as > a justification to make further mistakes which will then necessitate > further kludges to DNS. agree. so let's get rid of these kinky scoped addresses in v6 randy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 11 12:07:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BJ7Wk7011394; Tue, 11 Jun 2002 12:07:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5BJ7Whp011393; Tue, 11 Jun 2002 12:07:32 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BJ7Sk7011386 for ; Tue, 11 Jun 2002 12:07:28 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA10813 for ; Tue, 11 Jun 2002 12:07:31 -0700 (PDT) Received: from esunmail ([129.147.58.122]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA15733 for ; Tue, 11 Jun 2002 13:07:31 -0600 (MDT) Received: from xpa-fe1 (esunmail-ge0 [129.147.58.121]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 0.3 (built May 13 2002)) with ESMTP id <0GXK00KYO2GIC6@edgemail1.Central.Sun.COM> for ipng@sunroof.eng.sun.com; Tue, 11 Jun 2002 13:07:31 -0600 (MDT) Received: from localhost ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 0.2 (built Apr 26 2002)) with ESMTPSA id <0GXK000VV2GHRT@mail.sun.net> for ipng@sunroof.eng.sun.com; Tue, 11 Jun 2002 13:07:30 -0600 (MDT) Date: Tue, 11 Jun 2002 12:07:23 -0700 From: Alain Durand Subject: Re: IPv6 Scoped Addresses and Routing Protocols In-reply-to: To: Randy Bush Cc: Keith Moore , ipng@sunroof.eng.sun.com Message-id: <761B0259-7D6E-11D6-A58E-00039376A6AA@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.482) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tuesday, June 11, 2002, at 11:34 AM, Randy Bush wrote: > l knowing the intent of the icmp draft, isn't it? > >> the node's opinion of its name isn't the same piece of information as >> the network administrator's opinion of a node's name. > ^ cryptogtaphically signed > > can you say "name spoofing" The ICMP name lookup tells you who a node pretends to be, not what its globally unique assigned name has been cryptographically verified You may or may not trust this information. For local debuging purpose, it is valuable information, but it would certainly raises major concerns if it were to be applied on the Internet. - Alain. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 11 12:13:30 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BJDUk7011451; Tue, 11 Jun 2002 12:13:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5BJDURM011450; Tue, 11 Jun 2002 12:13:30 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BJDPk7011443 for ; Tue, 11 Jun 2002 12:13:26 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA11791 for ; Tue, 11 Jun 2002 12:13:29 -0700 (PDT) Received: from esunmail ([129.147.58.121]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA19045 for ; Tue, 11 Jun 2002 13:13:28 -0600 (MDT) Received: from xpa-fe1 (esunmail-ge1 [129.147.58.122]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 0.3 (built May 13 2002)) with ESMTP id <0GXK003WR2QFT4@edgemail1.Central.Sun.COM> for ipng@sunroof.eng.sun.com; Tue, 11 Jun 2002 13:13:28 -0600 (MDT) Received: from localhost ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 0.2 (built Apr 26 2002)) with ESMTPSA id <0GXK000012QERC@mail.sun.net> for ipng@sunroof.eng.sun.com; Tue, 11 Jun 2002 13:13:27 -0600 (MDT) Date: Tue, 11 Jun 2002 12:13:20 -0700 From: Alain Durand Subject: Re: IPv6 Scoped Addresses and Routing Protocols In-reply-to: To: Randy Bush Cc: Keith Moore , Markku Savela , ipng@sunroof.eng.sun.com Message-id: <4AC15B0C-7D6F-11D6-A58E-00039376A6AA@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.482) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tuesday, June 11, 2002, at 12:02 PM, Randy Bush wrote: >> it seems obvious in hindsight that private addresses were a mistake >> in IPv4. so the fact that they exist, and that we now find it >> necessary >> to warn people to not advertise them in DNS, shouldn't be cited as >> a justification to make further mistakes which will then necessitate >> further kludges to DNS. > > agree. so let's get rid of these kinky scoped addresses in v6 That would certainly make life in v6 land much simpler. And anything that makes it simpler ease transition worries. - Alain. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 11 12:21:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BJL9k7011497; Tue, 11 Jun 2002 12:21:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5BJL8jG011496; Tue, 11 Jun 2002 12:21:08 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BJL5k7011489 for ; Tue, 11 Jun 2002 12:21:05 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA16065 for ; Tue, 11 Jun 2002 12:21:08 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA06947 for ; Tue, 11 Jun 2002 13:21:07 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g5BJKmR25142; Tue, 11 Jun 2002 22:20:48 +0300 Date: Tue, 11 Jun 2002 22:20:48 +0300 (EEST) From: Pekka Savola To: Keith Moore cc: Thomas Narten , Subject: Re: IESG comments on draft-ietf-ipngwg-default-addr-select-06.txt In-Reply-To: <200206111704.g5BH4rn23548@astro.cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 11 Jun 2002, Keith Moore wrote: > I believe that temporary addresses should be available, but they > should NOT be enabled by default. Many applications will fail in > odd ways if assigned a temporary address. Temporary addresses are > best viewed as a tool which may enhance privacy but are not applicable > to all situations. The best default for the API is to assign a > stable address, and let those apps which can benefit from temporary > addresses request them specifically. > > I respect the desire for temporary addresses (and AFAIK I was one of > the first people to raise concerns about embedding tracable information > in an IPv6 address) but I don't think it's a good idea to effectively > change the API in a way that would break apps at this late date. The idea behind temporary addresses is IMO flawed (see draft-dupont-ipv6-rfc3041harmful-00.txt, there are some other issues too). They provide extra privacy in some cases, but are not a magic bullet. On the other hand, they make the others' life quite conflict. Therefore, I'm strongly against preferring temporary addresses. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 11 14:54:59 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BLsxk7012048; Tue, 11 Jun 2002 14:54:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5BLsxMh012047; Tue, 11 Jun 2002 14:54:59 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BLsuk7012040 for ; Tue, 11 Jun 2002 14:54:56 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA10703 for ; Tue, 11 Jun 2002 14:54:59 -0700 (PDT) Received: from drugs.dv.isc.org (drugs.dv.isc.org [130.155.191.236]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA10147 for ; Tue, 11 Jun 2002 15:54:57 -0600 (MDT) Received: from drugs.dv.isc.org (localhost.dv.isc.org [127.0.0.1]) by drugs.dv.isc.org (8.12.3/8.12.3) with ESMTP id g5BLsnm0007978; Wed, 12 Jun 2002 07:54:50 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200206112154.g5BLsnm0007978@drugs.dv.isc.org> To: "Steven M. Bellovin" Cc: rbrabson@us.ibm.com, ipng@sunroof.eng.sun.com From: Mark.Andrews@isc.org Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-reply-to: Your message of "Tue, 11 Jun 2002 11:05:25 -0400." <20020611150526.F31F77B53@berkshire.research.att.com> Date: Wed, 12 Jun 2002 07:54:49 +1000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > In message , rbrabson@us. > ib > m.com writes: > > > >So, to make SL work, we need changes to the DNS name server, changes > >to the resolver, routers to advertise the scope zones, hosts to > >learn the scope zones from routers and include them on DDNS > >registrations and use them in making routing decisions, updates to > >routing protocols, IANA needs to manage a new zone scope naming > >space, and who knows what else. > > > >Wouldn't it make sense to hold off on SL until we at least have > >some proposals on the table which describe the changes necessary to > >make SL work, at which time we could have a discussion on the > >technical merits of the proposal(s)? Until that time, though, the > >SL unicast address space should either be reserved or moved to > >experimental. > > > > I think this is the key point. Regardless of the possible benefits of > site-local addresses -- and I'm willing to withhold judgment on that > point -- we don't know in detail how to make them work. At a minimum, > we need changes in routing and the DNS. We may need new global > namespaces as well, with all that implies for co-ordination and > administrative overhead. Well we already have a global managed namespace. The scopename would be just be a name within the namespace already delegated to you. host1.example.com. SA site1.example.com. host1.example.com. SA site2.example.com. host1.example.com. SA . host2.example.com. SA site2.example.com. host2.example.com. SA . host3.example.com. SA site1.example.com. host3.example.com. SA . Here host2.example.com and host3.example.com would have to communicate using global addresses while host1.example.com and host2.example.com could choose to use there site2.example.com SL address and host1.example.com and host3.example.com could choose to use there site1.example.com SL address. Mark > --Steve Bellovin, http://www.research.att.com/~smb (me) > http://www.wilyhacker.com ("Firewalls" book) > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@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 Tue Jun 11 15:18:54 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BMIrk7012088; Tue, 11 Jun 2002 15:18:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5BMIrFY012087; Tue, 11 Jun 2002 15:18:53 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BMInk7012080 for ; Tue, 11 Jun 2002 15:18:49 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA18970 for ; Tue, 11 Jun 2002 15:18:52 -0700 (PDT) Received: from mail-green.research.att.com (mail-green.research.att.com [135.207.30.103]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA26913 for ; Tue, 11 Jun 2002 16:18:51 -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 C9D411E03C; Tue, 11 Jun 2002 18:18:48 -0400 (EDT) Received: from berkshire.research.att.com (postal.research.att.com [135.207.23.30]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id SAA17499; Tue, 11 Jun 2002 18:13:29 -0400 (EDT) Received: from research.att.com (localhost [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id 9A0CF7B4B; Tue, 11 Jun 2002 18:18:46 -0400 (EDT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: "Steven M. Bellovin" To: Mark.Andrews@isc.org Cc: rbrabson@us.ibm.com, ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 11 Jun 2002 18:18:46 -0400 Message-Id: <20020611221846.9A0CF7B4B@berkshire.research.att.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <200206112154.g5BLsnm0007978@drugs.dv.isc.org>, Mark.Andrews@isc.org writes: > >> >> I think this is the key point. Regardless of the possible benefits of >> site-local addresses -- and I'm willing to withhold judgment on that >> point -- we don't know in detail how to make them work. At a minimum, >> we need changes in routing and the DNS. We may need new global >> namespaces as well, with all that implies for co-ordination and >> administrative overhead. > > Well we already have a global managed namespace. The > scopename would be just be a name within the namespace > already delegated to you. > > host1.example.com. SA site1.example.com. > host1.example.com. SA site2.example.com. > host1.example.com. SA . > > host2.example.com. SA site2.example.com. > host2.example.com. SA . > > host3.example.com. SA site1.example.com. > host3.example.com. SA . > > Here host2.example.com and host3.example.com would have to > communicate using global addresses while host1.example.com > and host2.example.com could choose to use there site2.example.com > SL address and host1.example.com and host3.example.com could > choose to use there site1.example.com SL address. But some people have suggested that the main benefit of site-local addresses is for disconnected sites, which presumably don't have domain names... --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com ("Firewalls" book) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 11 15:30:36 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BMUak7012107; Tue, 11 Jun 2002 15:30:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5BMUZKk012106; Tue, 11 Jun 2002 15:30:35 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BMUVk7012099 for ; Tue, 11 Jun 2002 15:30:32 -0700 (PDT) Received: from lillen ([192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g5BMUSK01024; Wed, 12 Jun 2002 00:30:29 +0200 (MEST) Date: Wed, 12 Jun 2002 00:29:14 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: IESG comments on draft-ietf-ipngwg-default-addr-select-06.txt To: Keith Moore Cc: Thomas Narten , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <200206111704.g5BH4rn23548@astro.cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I respect the desire for temporary addresses (and AFAIK I was one of > the first people to raise concerns about embedding tracable information > in an IPv6 address) but I don't think it's a good idea to effectively > change the API in a way that would break apps at this late date. The proposed text is trying to say that temporary addresses are preferable but that there might be issues (such as applications having problems) which consistitute a good enough reason to not follow the default. Thus there is significant freedom for implementors to use their best judgement based on their knowledge about the applications. Do you see a problem with this approach? 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 Jun 11 16:20:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BNKbk7012178; Tue, 11 Jun 2002 16:20:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5BNKbnf012177; Tue, 11 Jun 2002 16:20:37 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BNKXk7012170 for ; Tue, 11 Jun 2002 16:20:33 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA10057 for ; Tue, 11 Jun 2002 16:20:36 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA26494; Tue, 11 Jun 2002 17:20:36 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5BNKZn27758; Tue, 11 Jun 2002 19:20:35 -0400 (EDT) Message-Id: <200206112320.g5BNKZn27758@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Erik Nordmark cc: Keith Moore , Thomas Narten , ipng@sunroof.eng.sun.com Subject: Re: IESG comments on draft-ietf-ipngwg-default-addr-select-06.txt In-reply-to: (Your message of "Wed, 12 Jun 2002 00:29:14 +0200.") Date: Tue, 11 Jun 2002 19:20:35 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > I respect the desire for temporary addresses (and AFAIK I was one of > > the first people to raise concerns about embedding tracable information > > in an IPv6 address) but I don't think it's a good idea to effectively > > change the API in a way that would break apps at this late date. > > The proposed text is trying to say that temporary addresses are preferable > but that there might be issues (such as applications having problems) > which consistitute a good enough reason to not follow the default. > Thus there is significant freedom for implementors to use their best > judgement based on their knowledge about the applications. > > Do you see a problem with this approach? absolutely. it encourages the API to deviate from one vendor to another, and from one installation to another. application coders thus can't count on predictable behavior from one platform to another - if they care at all what kind of address they want, they always have to do explicit binds of both source and destination addresses. worse, it introduces subtle failure modes where an application that works fine in one environment will fail in a different but apparently similar environment, even though the network seems to be working find otherwise. The idea that hosts, or administrators, can make reasonable address selections without input from the application is just wrong. The application, no the host, knows what kinds of addresses it needs - for some, temporary addresses will do just fine, but others needs stable, public, globally-scoped addresses. If this is not communicated explicitly then every application will have to do its own address selection in order to work reliably. Being able to alter the policy on a per-host basis is not a good solution, because it makes the platform less predictable (see above), and because multiple applications needing different policies will often run on the same host. I'd far rather see an approach like the following: 1. the API default is to use stable addresses 2. to request a temporary address, do it this way 3. applicatons that don't need stable addresses SHOULD request temporary addresses I've got some other problems with the document also - specifically the idea that link-local addresses are preferable to global addresses. Global addresses are always preferable because all applications can tolerate them. At most, LL addresses should be used only when there is no other alternative, because some applications need to treat them specially (this isn't as bad in v6 as in v4) But LL addresses should probably be used only when they are explicitly specified. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 11 16:28:22 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BNSLk7012210; Tue, 11 Jun 2002 16:28:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5BNSLQY012209; Tue, 11 Jun 2002 16:28:21 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BNSHk7012202 for ; Tue, 11 Jun 2002 16:28:17 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA13979 for ; Tue, 11 Jun 2002 16:28:21 -0700 (PDT) Received: from esunmail ([129.147.58.122]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA21177 for ; Tue, 11 Jun 2002 17:28:21 -0600 (MDT) Received: from xpa-fe2 (esunmail-ge0 [129.147.58.121]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 0.3 (built May 13 2002)) with ESMTP id <0GXK00KUWEJ7C6@edgemail1.Central.Sun.COM> for ipng@sunroof.eng.sun.com; Tue, 11 Jun 2002 17:28:20 -0600 (MDT) Received: from localhost ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 0.2 (built Apr 26 2002)) with ESMTPSA id <0GXK00F32EJ6H5@mail.sun.net> for ipng@sunroof.eng.sun.com; Tue, 11 Jun 2002 17:28:19 -0600 (MDT) Date: Tue, 11 Jun 2002 16:28:11 -0700 From: Alain Durand Subject: Re: IESG comments on draft-ietf-ipngwg-default-addr-select-06.txt In-reply-to: To: Erik Nordmark Cc: Keith Moore , Thomas Narten , ipng@sunroof.eng.sun.com Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.482) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tuesday, June 11, 2002, at 03:29 PM, Erik Nordmark wrote: > > The proposed text is trying to say that temporary addresses are > preferable > but that there might be issues (such as applications having problems) > which consistitute a good enough reason to not follow the default. > Thus there is significant freedom for implementors to use their best > judgement based on their knowledge about the applications. > > Do you see a problem with this approach? > If SA is a temporary address and SB is a public address, then prefer > SA. Similarly, if SB is a temporary address and SA is a public > address, then prefer SB. > An implementation MUST support a per-connection configuration > mechanism (for example, an API extension) to reverse the sense of > this preference and prefer public addresses over public > addresses. This proposed text means that all the existing clients that talks to server that uses reverse DNS lookup will need to be modified to use this new API extension to re-establish an existing behavior that would otherwise be broken. Until such an API is standardized and implemented, this seems to me an hazardous path. Also, this is asking exiting application who do not care about privacy to pay for the benefits of the new ones who desire privacy. I would be convinced this is worth doing if the number of applications that need to change is limited, and I'm afraid it is not. Does the IESG have data about this? And, last but not least, is having most of the traffic sent by client using this privacy extension such a good thing? Although I understand the desire from some applications for privacy, I'm afraid it would create network management nightmares when doing traffic analysis. Can you imagine a large site trying to do snoop/tcpdump when most of the traffic is RFC3041? - Alain. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 11 16:34:52 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BNYqk7012278; Tue, 11 Jun 2002 16:34:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5BNYqVr012277; Tue, 11 Jun 2002 16:34:52 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BNYok7012270 for ; Tue, 11 Jun 2002 16:34:50 -0700 (PDT) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g5BNYnoR003902 for ; Tue, 11 Jun 2002 16:34:49 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g5BNYmKe003901 for ipng@sunroof.eng.sun.com; Tue, 11 Jun 2002 16:34:48 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BKa1k7011630 for ; Tue, 11 Jun 2002 13:36:01 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA26099 for ; Tue, 11 Jun 2002 13:36:05 -0700 (PDT) Received: from cisco.com (edinburgh.cisco.com [144.254.112.76]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA01203 for ; Tue, 11 Jun 2002 13:36:04 -0700 (PDT) Received: (from dfawcus@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id VAA16377 for ipng@sunroof.eng.sun.com; Tue, 11 Jun 2002 21:36:03 +0100 (BST) Date: Tue, 11 Jun 2002 21:36:03 +0100 From: Derek Fawcus To: ipng@sunroof.eng.sun.com Subject: Re: IPv6 Scoped Addresses and Routing Protocols Message-ID: <20020611213603.A11532@edinburgh.cisco.com> Mail-Followup-To: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk My view on site local addresses is a bit split. >From a personal point of view I like them. I can use them in my home network, together with global addresses (6to4 at the moment), and even store them in my local DNS server. None of this causes me any problems, it all works and means if/when an ISP in the UK is able to supply me with real IPv6 global addresses I'll not have to alter much. As things stand if someone was to query my DNS server from the outside world (assuming the domain I'm using delegated to me), they'd not see any SL addresses - split DNS. This is the simple scenario of SL enabled globally at home, and having a couple of (site) border routers, both of which have some global interfaces and some site interfaces. Both routers only know about the one site - the same site. However as an router implementor - they're a right royal pain. One major issue being the possibility of having more than one site cutting through the router. For a single CPU router this is not too bad, for a multi CPU router it is awkward. Now even if we were to simplify things so that a node (router) could not attach to more than one site at a time (i.e. the case of site links, and non-site (global) links), things'd not stay simple for long. I say this 'cause I'd anticipate that someone would want to supply outsourced managed 'Site' networks in the same fashion as ISPs offer managed VPNs at the moment. This would effectively collapse things back into the situation we have at the moment with multi-site routers. -- Overrall I guess I'd say keep them, then hope they never get deployed at anything other than the sort of use I personally have for them. This basically means that they'd not be of much use for anything other than small scale use, and (as someone else pointed out) are of no use to large organisations with geographically diverse facilities. What does worry me though is if customers (ISPs) want to have the same sort of VPN facility I've mentioned above - this seems to naturally coincide with the v6 view of SL addresses, and raises very similar issues to be solved. The real answer to the underlying problem here is a lot harder to solve. It all seems to mainly be about security, and it would seem that IPsec should be used to address it. However the issue of having keys distributed, and prooving identity still needs to be rolled out. DF -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 11 16:35:18 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BNZIk7012288; Tue, 11 Jun 2002 16:35:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5BNZIB6012287; Tue, 11 Jun 2002 16:35:18 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BNZGk7012280 for ; Tue, 11 Jun 2002 16:35:16 -0700 (PDT) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g5BNZFoR003910 for ; Tue, 11 Jun 2002 16:35:15 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g5BNZExJ003909 for ipng@sunroof.eng.sun.com; Tue, 11 Jun 2002 16:35:14 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BKcEk7011644 for ; Tue, 11 Jun 2002 13:38:14 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA12237 for ; Tue, 11 Jun 2002 13:38:19 -0700 (PDT) Received: from cisco.com (edinburgh.cisco.com [144.254.112.76]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA04566 for ; Tue, 11 Jun 2002 14:38:18 -0600 (MDT) Received: (from dfawcus@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id VAA16442; Tue, 11 Jun 2002 21:38:05 +0100 (BST) Date: Tue, 11 Jun 2002 21:38:05 +0100 From: Derek Fawcus To: Alain Durand Cc: Randy Bush , Keith Moore , ipng@sunroof.eng.sun.com Subject: Re: IPv6 Scoped Addresses and Routing Protocols Message-ID: <20020611213805.B11532@edinburgh.cisco.com> Mail-Followup-To: Alain Durand , Randy Bush , Keith Moore , ipng@sunroof.eng.sun.com References: <761B0259-7D6E-11D6-A58E-00039376A6AA@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <761B0259-7D6E-11D6-A58E-00039376A6AA@sun.com>; from Alain.Durand@Sun.COM on Tue, Jun 11, 2002 at 12:07:23PM -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, Jun 11, 2002 at 12:07:23PM -0700, Alain Durand wrote: > > The ICMP name lookup tells you who a node pretends to be, > not what its globally unique assigned name has been cryptographically > verified > You may or may not trust this information. > For local debuging purpose, it is valuable information, but it would > certainly raises major concerns if it were to be applied on the Internet. But surely you simply use the name retrned to do a forward lookup and verify that the original address is one of those returned? DF -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 11 16:38:40 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BNcek7012344; Tue, 11 Jun 2002 16:38:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5BNcect012343; Tue, 11 Jun 2002 16:38:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BNcLk7012336 for ; Tue, 11 Jun 2002 16:38:36 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA12749 for ; Tue, 11 Jun 2002 16:38:17 -0700 (PDT) Received: from esunmail ([129.147.58.122]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA04252 for ; Tue, 11 Jun 2002 17:38:16 -0600 (MDT) Received: from xpa-fe1 (esunmail-ge1 [129.147.58.122]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 0.3 (built May 13 2002)) with ESMTP id <0GXK0033QEZRT4@edgemail1.Central.Sun.COM> for ipng@sunroof.eng.sun.com; Tue, 11 Jun 2002 17:38:16 -0600 (MDT) Received: from localhost ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 0.2 (built Apr 26 2002)) with ESMTPSA id <0GXK00016EZQRC@mail.sun.net> for ipng@sunroof.eng.sun.com; Tue, 11 Jun 2002 17:38:15 -0600 (MDT) Date: Tue, 11 Jun 2002 16:38:07 -0700 From: Alain Durand Subject: Re: IESG comments on draft-ietf-ipngwg-default-addr-select-06.txt In-reply-to: <200206112320.g5BNKZn27758@astro.cs.utk.edu> To: Keith Moore Cc: Erik Nordmark , Thomas Narten , ipng@sunroof.eng.sun.com Message-id: <480BE094-7D94-11D6-9BDA-00039376A6AA@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.482) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tuesday, June 11, 2002, at 04:20 PM, Keith Moore wrote: > I've got some other problems with the document also - specifically > the idea that link-local addresses are preferable to global addresses. > Global addresses are always preferable because all applications > can tolerate them. At most, LL addresses should be used only > when there is no other alternative, because some applications > need to treat them specially (this isn't as bad in v6 as in v4) > But LL addresses should probably be used only when they are > explicitly specified. I would agree there. If an application stores the IP address of its peer for future use, on a multi-interface node, if link-local addresses are used and the application did not kept track of the incoming interface, there would be some issues when it would like to reconnect to its peer. - Alain. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 11 16:39:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BNdlk7012361; Tue, 11 Jun 2002 16:39:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5BNdl3c012360; Tue, 11 Jun 2002 16:39:47 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BNdhk7012353 for ; Tue, 11 Jun 2002 16:39:43 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA17933 for ; Tue, 11 Jun 2002 16:39:47 -0700 (PDT) Received: from esunmail ([129.147.58.121]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA25620 for ; Tue, 11 Jun 2002 17:39:47 -0600 (MDT) Received: from xpa-fe1 (esunmail-ge1 [129.147.58.122]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 0.3 (built May 13 2002)) with ESMTP id <0GXK00KMAF2AC6@edgemail1.Central.Sun.COM> for ipng@sunroof.eng.sun.com; Tue, 11 Jun 2002 17:39:47 -0600 (MDT) Received: from localhost ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 0.2 (built Apr 26 2002)) with ESMTPSA id <0GXK000UOF29T0@mail.sun.net> for ipng@sunroof.eng.sun.com; Tue, 11 Jun 2002 17:39:46 -0600 (MDT) Date: Tue, 11 Jun 2002 16:39:37 -0700 From: Alain Durand Subject: Re: IPv6 Scoped Addresses and Routing Protocols In-reply-to: <20020611213805.B11532@edinburgh.cisco.com> To: Derek Fawcus Cc: ipng@sunroof.eng.sun.com Message-id: <7E04A3FE-7D94-11D6-9BDA-00039376A6AA@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.482) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tuesday, June 11, 2002, at 01:38 PM, Derek Fawcus wrote: > On Tue, Jun 11, 2002 at 12:07:23PM -0700, Alain Durand wrote: >> >> The ICMP name lookup tells you who a node pretends to be, >> not what its globally unique assigned name has been cryptographically >> verified >> You may or may not trust this information. >> For local debuging purpose, it is valuable information, but it would >> certainly raises major concerns if it were to be applied on the >> Internet. > > But surely you simply use the name retrned to do a forward lookup and > verify that the original address is one of those returned? .. assuming the name returned is in the global name space. - Alain. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 11 16:45:17 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BNjHk7012389; Tue, 11 Jun 2002 16:45:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5BNjHFE012388; Tue, 11 Jun 2002 16:45:17 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BNjEk7012381 for ; Tue, 11 Jun 2002 16:45:14 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA19522 for ; Tue, 11 Jun 2002 16:45:18 -0700 (PDT) Received: from drugs.dv.isc.org (drugs.dv.isc.org [130.155.191.236]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA29938 for ; Tue, 11 Jun 2002 16:45:17 -0700 (PDT) Received: from drugs.dv.isc.org (localhost.dv.isc.org [127.0.0.1]) by drugs.dv.isc.org (8.12.3/8.12.3) with ESMTP id g5BNj9m0008631; Wed, 12 Jun 2002 09:45:10 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200206112345.g5BNj9m0008631@drugs.dv.isc.org> To: "Steven M. Bellovin" Cc: rbrabson@us.ibm.com, ipng@sunroof.eng.sun.com From: Mark.Andrews@isc.org Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-reply-to: Your message of "Tue, 11 Jun 2002 18:18:46 -0400." <20020611221846.9A0CF7B4B@berkshire.research.att.com> Date: Wed, 12 Jun 2002 09:45:09 +1000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > In message <200206112154.g5BLsnm0007978@drugs.dv.isc.org>, Mark.Andrews@isc.o > rg > writes: > > > > >> > >> I think this is the key point. Regardless of the possible benefits of > >> site-local addresses -- and I'm willing to withhold judgment on that > >> point -- we don't know in detail how to make them work. At a minimum, > >> we need changes in routing and the DNS. We may need new global > >> namespaces as well, with all that implies for co-ordination and > >> administrative overhead. > > > > Well we already have a global managed namespace. The > > scopename would be just be a name within the namespace > > already delegated to you. > > > > host1.example.com. SA site1.example.com. > > host1.example.com. SA site2.example.com. > > host1.example.com. SA . > > > > host2.example.com. SA site2.example.com. > > host2.example.com. SA . > > > > host3.example.com. SA site1.example.com. > > host3.example.com. SA . > > > > Here host2.example.com and host3.example.com would have to > > communicate using global addresses while host1.example.com > > and host2.example.com could choose to use there site2.example.com > > SL address and host1.example.com and host3.example.com could > > choose to use there site1.example.com SL address. > > But some people have suggested that the main benefit of site-local > addresses is for disconnected sites, which presumably don't have domain > names... If they are using the DNS to publish the addresses they *have* a domainname. You can't use the DNS to do this without having a domainname. > --Steve Bellovin, http://www.research.att.com/~smb (me) > http://www.wilyhacker.com ("Firewalls" book) > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@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 Tue Jun 11 16:47:01 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BNl1k7012406; Tue, 11 Jun 2002 16:47:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5BNl1tv012405; Tue, 11 Jun 2002 16:47:01 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BNkuk7012398 for ; Tue, 11 Jun 2002 16:46:56 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA20066 for ; Tue, 11 Jun 2002 16:47:00 -0700 (PDT) Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA00631 for ; Tue, 11 Jun 2002 16:47:00 -0700 (PDT) Received: from postal.research.att.com (postal.research.att.com [135.207.23.30]) by mail-green.research.att.com (Postfix) with ESMTP id 9E4671E024; Tue, 11 Jun 2002 19:46:59 -0400 (EDT) Received: from berkshire.research.att.com (postal.research.att.com [135.207.23.30]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id TAA18920; Tue, 11 Jun 2002 19:41:28 -0400 (EDT) Received: from research.att.com (localhost [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id 9FF0D7B4B; Tue, 11 Jun 2002 19:46:46 -0400 (EDT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: "Steven M. Bellovin" To: Derek Fawcus Cc: Alain Durand , Randy Bush , Keith Moore , ipng@sunroof.eng.sun.com Subject: Re: IPv6 Scoped Addresses and Routing Protocols Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 11 Jun 2002 19:46:46 -0400 Message-Id: <20020611234646.9FF0D7B4B@berkshire.research.att.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <20020611213805.B11532@edinburgh.cisco.com>, Derek Fawcus writes: >On Tue, Jun 11, 2002 at 12:07:23PM -0700, Alain Durand wrote: >> >> The ICMP name lookup tells you who a node pretends to be, >> not what its globally unique assigned name has been cryptographically >> verified >> You may or may not trust this information. >> For local debuging purpose, it is valuable information, but it would >> certainly raises major concerns if it were to be applied on the Internet. > >But surely you simply use the name retrned to do a forward lookup and >verify that the original address is one of those returned? > Precisely. The cryptographic signature is not magic; it's the assertion of validity by the owner of the address space. How do you know the owner is telling the truth? --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com ("Firewalls" book) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 11 16:50:53 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BNoqk7012426; Tue, 11 Jun 2002 16:50:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5BNoqBp012425; Tue, 11 Jun 2002 16:50:52 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BNomk7012418 for ; Tue, 11 Jun 2002 16:50:48 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA18888 for ; Tue, 11 Jun 2002 16:50:52 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA05071; Tue, 11 Jun 2002 17:50:51 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5BNoon28264; Tue, 11 Jun 2002 19:50:50 -0400 (EDT) Message-Id: <200206112350.g5BNoon28264@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Alain Durand cc: Keith Moore , Erik Nordmark , Thomas Narten , ipng@sunroof.eng.sun.com Subject: Re: IESG comments on draft-ietf-ipngwg-default-addr-select-06.txt In-reply-to: (Your message of "Tue, 11 Jun 2002 16:38:07 PDT.") <480BE094-7D94-11D6-9BDA-00039376A6AA@sun.com> Date: Tue, 11 Jun 2002 19:50:49 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I would agree there. If an application stores the IP address of its peer > for future use, on a multi-interface node, if link-local addresses are > used and the application did not kept track of the incoming interface, > there would be some issues when it would like to reconnect to its peer. that, and any kind of limited-scope addresses are a pain for apps for which any of the components of that app are not in the same scope as all of the others. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 11 19:01:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5C21fk7012599; Tue, 11 Jun 2002 19:01:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5C21eYe012598; Tue, 11 Jun 2002 19:01:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5C21bk7012591 for ; Tue, 11 Jun 2002 19:01:37 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA27971 for ; Tue, 11 Jun 2002 19:01:40 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA27272 for ; Tue, 11 Jun 2002 19:01:39 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 3C08A4B2A; Wed, 12 Jun 2002 11:01:35 +0900 (JST) To: sommerfeld@east.sun.com Cc: ipng@sunroof.eng.sun.com In-reply-to: sommerfeld's message of Tue, 11 Jun 2002 14:02:42 -0400. <200206111802.g5BI2gZs003734@thunk.east.sun.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols From: itojun@iijlab.net Date: Wed, 12 Jun 2002 11:01:35 +0900 Message-ID: <21314.1023847295@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> faithd does NAT while changing the address family at the same time, doesn't >> it? >No doubt one of the KAME folks will correct me but my impression was >that it was more of a TCP-layer proxy rather than a layer-3 NAT. exactly, it is a TCP-layer proxy with specific address handling (lowermost 32bit used to relay IPv6 TCP session to IPv4 TCp session). >Regardless of how it works, it's one of many ways for a >site-local-addresses-only node to get external connectivity. yes. 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 Jun 11 22:49:36 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5C5nak7012932; Tue, 11 Jun 2002 22:49:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5C5nZWS012931; Tue, 11 Jun 2002 22:49:35 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5C5nWk7012924 for ; Tue, 11 Jun 2002 22:49:32 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA29534 for ; Tue, 11 Jun 2002 22:49:36 -0700 (PDT) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA27959 for ; Tue, 11 Jun 2002 22:49:36 -0700 (PDT) Subject: RE: Review of "Use of /127 Prefix Length Between Routers Considered Harmful" Date: Tue, 11 Jun 2002 22:49:35 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046406C802@server2000.arneill-py.sacramento.ca.us> X-MS-Has-Attach: X-MS-TNEF-Correlator: X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Topic: Review of "Use of /127 Prefix Length Between Routers Considered Harmful" Thread-Index: AcIOd/KrlXQQU9ymQvuImfBeLhS8AQDXKXeA content-class: urn:content-classes:message From: "Michel Py" To: "Bob Hinden" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5C5nXk7012925 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I would say "Should become a working group draft and receive formal review by the w.g.". I agree with the draft, but it has not been debated much and deserves some review before giving it a nod. Michel. A request has been made by the author to the RFC editor to publish the following draft as an Informational RFC: Title : Use of /127 Prefix Length Between Routers Considered Harmful Author(s) : P. Savola Filename : draft-savola-ipv6-127-prefixlen-03.txt Pages : 5 Date : 20-May-02 Earlier versions of this draft have been discussed on the mailing list, but it is not a working group draft. The IESG has requested that the IPv6 working group review the draft. Possible outcomes of the review are: - OK to publish as is - Needs to have a few issues fixed before publication - Should become a working group draft and receive formal review by the w.g. - Incorporate into another IPv6 w.g. document with broader scope. - Harmful, should not be published. Please send comments to the list. Thanks, Bob Hinden, Steve Deering, Margaret Wasserman IPv6 w.g. Co-Chairs -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 11 23:40:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5C6e8k7013119; Tue, 11 Jun 2002 23:40:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5C6e83f013118; Tue, 11 Jun 2002 23:40:08 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5C6e5k7013111 for ; Tue, 11 Jun 2002 23:40:05 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA27556 for ; Tue, 11 Jun 2002 23:40:06 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA21519 for ; Wed, 12 Jun 2002 00:41:46 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g5C6dpB30224; Wed, 12 Jun 2002 09:39:51 +0300 Date: Wed, 12 Jun 2002 09:39:50 +0300 (EEST) From: Pekka Savola To: Michel Py cc: Bob Hinden , Subject: RE: Review of "Use of /127 Prefix Length Between Routers Considered Harmful" In-Reply-To: <2B81403386729140A3A899A8B39B046406C802@server2000.arneill-py.sacramento.ca.us> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 11 Jun 2002, Michel Py wrote: > I would say "Should become a working group draft and receive > formal review by the w.g.". I agree with the draft, but it has not been > debated much and deserves some review before giving it a nod. This was discussed quite extensively back in Nov 2001 or so. Afterwards when first drafts were produced, there was some additional discussion too (as you know :-). Unfortunately my requests for comments, how to proceed etc. have received little response and I cannot generate discussion by myself :-). I must only gather that there is not much to discuss anymore. If people have have specific issues -- please, always, bring them up! -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 11 23:58:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5C6wNk7013147; Tue, 11 Jun 2002 23:58:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5C6wNg1013146; Tue, 11 Jun 2002 23:58:23 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5C6wJk7013139 for ; Tue, 11 Jun 2002 23:58:19 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA10070 for ; Tue, 11 Jun 2002 23:58:21 -0700 (PDT) Received: from esunmail ([129.147.58.122]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA27624 for ; Wed, 12 Jun 2002 01:00:01 -0600 (MDT) Received: from xpa-fe1 (esunmail-ge1 [129.147.58.122]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 0.3 (built May 13 2002)) with ESMTP id <0GXK00K3NZD6C6@edgemail1.Central.Sun.COM> for ipng@sunroof.eng.sun.com; Wed, 12 Jun 2002 00:58:20 -0600 (MDT) Received: from localhost ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 0.2 (built Apr 26 2002)) with ESMTPSA id <0GXK000S9ZD4RC@mail.sun.net> for ipng@sunroof.eng.sun.com; Wed, 12 Jun 2002 00:58:17 -0600 (MDT) Date: Tue, 11 Jun 2002 23:58:06 -0700 From: Alain Durand Subject: Re: Review of "Use of /127 Prefix Length Between Routers Considered Harmful" In-reply-to: To: Pekka Savola Cc: Michel Py , Bob Hinden , ipng@sunroof.eng.sun.com Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.482) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tuesday, June 11, 2002, at 11:39 PM, Pekka Savola wrote: > > If people have have specific issues -- please, always, bring them up! I still do not understand why this draft does not simply advocate using 2 /128. - 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 Jun 12 01:09:15 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5C89Ek7013233; Wed, 12 Jun 2002 01:09:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5C894cL013232; Wed, 12 Jun 2002 01:09:04 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5C88wk7013225 for ; Wed, 12 Jun 2002 01:08:58 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA23049 for ; Wed, 12 Jun 2002 01:09:00 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA25067 for ; Wed, 12 Jun 2002 02:10:40 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g5C88pW31091; Wed, 12 Jun 2002 11:08:51 +0300 Date: Wed, 12 Jun 2002 11:08:51 +0300 (EEST) From: Pekka Savola To: Alain Durand cc: Michel Py , Bob Hinden , Subject: Re: Review of "Use of /127 Prefix Length Between Routers Considered Harmful" In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 11 Jun 2002, Alain Durand wrote: > On Tuesday, June 11, 2002, at 11:39 PM, Pekka Savola wrote: > > > > If people have have specific issues -- please, always, bring them up! > > I still do not understand why this draft does not simply advocate using > 2 /128. I think we agree that the "first suggestion" would be to use /64 instead as required by addr-arch, right? As for 2 /128's, I thought I had listed in the possible solutions section, but it seems it's only in the discussion part. I'll add it to section two with /126: --8<-- 2. Failing that, /126 does not have this problem, and it can be used safely on a point-to-point link (e.g. using the 2nd and the 3rd address for unicast). This is analogous to using /30 for IPv4. Naturally, not much would be lost if even a shorter prefix was used, e.g. /112 or /120. Of course, 2 /128's could also be used. This seems like an elegant solution, but may be operationally more cumbersome with some implementations (e.g. requiring to set a static route). The author feels that if /64 cannot be used, /112, reserving the last 16 bits for node identifiers, has probably the least amount of drawbacks (also see section 3). --8<-- Does this seem adequate? As for the reasoning.. 2 /128's work (internally) differently than e.g. /127, /126 or /64. It's often more complex to use them (e.g. with Juniper and Cisco you have to use manually configured static routes), but sometimes not (e.g. KAME). To remember the focus, we're talking about a link between two routers. In addition, as 2 /128's work differently (the other end is reachable via a static rather than connected route), it's something that will often face problems (not so vigorously tested as it's not as generic code path, implementation problems, ...). For example, I noticed a bug in pim6sd RPF validation using 2 /128's that didn't exist with "normal" prefix lengths. So in conclusion, why not..? But I'm not sure if it operationally (which this draft was about) the simplest and the most robust course of action. Other opinions on this? -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 12 01:21:15 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5C8LFk7013266; Wed, 12 Jun 2002 01:21:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5C8LFqU013265; Wed, 12 Jun 2002 01:21:15 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5C8LCk7013258 for ; Wed, 12 Jun 2002 01:21:12 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA23768 for ; Wed, 12 Jun 2002 01:21:14 -0700 (PDT) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA29377 for ; Wed, 12 Jun 2002 02:22:54 -0600 (MDT) Subject: RE: Review of"Use of /127 Prefix Length Between Routers Considered Harmful" Date: Wed, 12 Jun 2002 01:21:12 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046405E0F8@server2000.arneill-py.sacramento.ca.us> X-MS-Has-Attach: X-MS-TNEF-Correlator: X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Topic: Review of"Use of /127 Prefix Length Between Routers Considered Harmful" Thread-Index: AcIR3rVSz1Q623yrQjKqbdgDeclMkgACtMjg From: "Michel Py" content-class: urn:content-classes:message To: "Alain Durand" , "Pekka Savola" Cc: "Bob Hinden" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5C8LCk7013259 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Alain Durand wrote: > I still do not understand why this draft does not simply advocate > using 2 /128. There is something that makes me scream at the thought of not having both ends in the same subnet and/or not having a route for that subnet. Possibly some frame-relay flashback? Anyway, this sounds to me as bad as using unnumbered. B.A.D. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 12 01:37:07 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5C8b7k7013288; Wed, 12 Jun 2002 01:37:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5C8b6gD013287; Wed, 12 Jun 2002 01:37:06 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5C8b2k7013280 for ; Wed, 12 Jun 2002 01:37:02 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA27063 for ; Wed, 12 Jun 2002 01:37:05 -0700 (PDT) Received: from esunmail ([129.147.58.122]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA03876 for ; Wed, 12 Jun 2002 02:37:05 -0600 (MDT) Received: from xpa-fe2 (esunmail-ge0 [129.147.58.121]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 0.3 (built May 13 2002)) with ESMTP id <0GXL00KD93XQC4@edgemail1.Central.Sun.COM> for ipng@sunroof.eng.sun.com; Wed, 12 Jun 2002 02:37:04 -0600 (MDT) Received: from localhost ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 0.2 (built Apr 26 2002)) with ESMTPSA id <0GXL00FLB3XPHL@mail.sun.net> for ipng@sunroof.eng.sun.com; Wed, 12 Jun 2002 02:37:02 -0600 (MDT) Date: Wed, 12 Jun 2002 01:36:51 -0700 From: Alain Durand Subject: Re: Review of"Use of /127 Prefix Length Between Routers Considered Harmful" In-reply-to: <2B81403386729140A3A899A8B39B046405E0F8@server2000.arneill-py.sacramento.ca.us> To: Michel Py Cc: ipng@sunroof.eng.sun.com Message-id: <8AFF725B-7DDF-11D6-A8D7-00039376A6AA@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.482) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wednesday, June 12, 2002, at 01:21 AM, Michel Py wrote: >> Alain Durand wrote: >> I still do not understand why this draft does not simply advocate >> using 2 /128. > > There is something that makes me scream at the thought of not having > both ends in the same subnet and/or not having a route for that subnet. > Possibly some frame-relay flashback? Anyway, this sounds to me as bad as > using unnumbered. B.A.D. This sounds like F.U.D. to me. Why do you think it is B.A.D.? - 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 Jun 12 01:40:04 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5C8e4k7013305; Wed, 12 Jun 2002 01:40:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5C8e4xZ013304; Wed, 12 Jun 2002 01:40:04 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5C8e0k7013297 for ; Wed, 12 Jun 2002 01:40:00 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA27490 for ; Wed, 12 Jun 2002 01:40:02 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA07081 for ; Wed, 12 Jun 2002 02:41:43 -0600 (MDT) Received: from localhost ([3ffe:501:100f:1048:200:39ff:fe10:85d7]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g5C8do892287; Wed, 12 Jun 2002 17:39:50 +0900 (JST) Date: Wed, 12 Jun 2002 17:39:54 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Keith Moore Cc: Erik Nordmark , Thomas Narten , ipng@sunroof.eng.sun.com Subject: Re: IESG comments on draft-ietf-ipngwg-default-addr-select-06.txt In-Reply-To: <200206112320.g5BNKZn27758@astro.cs.utk.edu> References: <200206112320.g5BNKZn27758@astro.cs.utk.edu> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 23 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Tue, 11 Jun 2002 19:20:35 -0400, >>>>> Keith Moore said: > I've got some other problems with the document also - specifically > the idea that link-local addresses are preferable to global addresses. Please let me confirm: are you referring to Rule 2 of source address selection? Rule 2: Prefer appropriate scope. If Scope(SA) < Scope(SB): If Scope(SA) < Scope(D), then prefer SB and otherwise prefer SA. Similarly, if Scope(SB) < Scope(SA): If Scope(SB) < Scope(D), then prefer SA and otherwise prefer SB. According to this rule, a link-local source address will be preferred to a global source address for a link-local destination. I think the rule is quite reasonable. 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 Jun 12 01:57:19 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5C8vIk7013335; Wed, 12 Jun 2002 01:57:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5C8vINh013334; Wed, 12 Jun 2002 01:57:18 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5C8vEk7013327 for ; Wed, 12 Jun 2002 01:57:14 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA28842 for ; Wed, 12 Jun 2002 01:57:16 -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 CAA00878 for ; Wed, 12 Jun 2002 02:57:15 -0600 (MDT) Received: from localhost ([3ffe:501:100f:1048:200:39ff:fe10:85d7]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g5C8v2892499; Wed, 12 Jun 2002 17:57:05 +0900 (JST) Date: Wed, 12 Jun 2002 17:57:06 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Alain Durand Cc: Keith Moore , Erik Nordmark , Thomas Narten , ipng@sunroof.eng.sun.com Subject: Re: IESG comments on draft-ietf-ipngwg-default-addr-select-06.txt In-Reply-To: <480BE094-7D94-11D6-9BDA-00039376A6AA@sun.com> References: <200206112320.g5BNKZn27758@astro.cs.utk.edu> <480BE094-7D94-11D6-9BDA-00039376A6AA@sun.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 31 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Tue, 11 Jun 2002 16:38:07 -0700, >>>>> Alain Durand said: > I would agree there. If an application stores the IP address of its peer > for future use, > on a multi-interface node, if link-local addresses are used and the > application (in theory, the "multi-interface node" should be "multi-link node". but anyway) > did not kept track of the incoming interface, there would be some issues > when > it would like to reconnect to its peer. That's true, but IMO this is a bit different issue from address selection, particularly the issue of source address selection. Even if an application avoids using link-local addresses as source address, it cannot assume the source address of an incoming packet is always a non-link-local address. And, if such an application needs to keep the peer's address of an incoming packet, it will definitely need to keep the corresponding scope zone. This is irrelevant to how the application chooses the source address for outgoing packets. I agree that scoped addresses introduce additional costs to application in general, though. 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 Jun 12 02:07:51 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5C97ok7013354; Wed, 12 Jun 2002 02:07:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5C97o4e013353; Wed, 12 Jun 2002 02:07:50 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5C97lk7013346 for ; Wed, 12 Jun 2002 02:07:47 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA00936 for ; Wed, 12 Jun 2002 02:07:50 -0700 (PDT) Received: from gau.lava.net (gau.lava.net [64.65.64.28]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA24367 for ; Wed, 12 Jun 2002 03:07:49 -0600 (MDT) Received: from malasada.lava.net ([64.65.64.17]) (1456 bytes) by gau.lava.net; Tue, 11 Jun 2002 23:07:33 -1000 (HST) via sendmail [esmtp] id for Date: Tue, 11 Jun 2002 23:07:32 -1000 (HST) From: Antonio Querubin To: Michel Py cc: Alain Durand , Pekka Savola , Bob Hinden , Subject: RE: Review of"Use of /127 Prefix Length Between Routers Considered Harmful" In-Reply-To: <2B81403386729140A3A899A8B39B046405E0F8@server2000.arneill-py.sacramento.ca.us> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 12 Jun 2002, Michel Py wrote: > There is something that makes me scream at the thought of not having > both ends in the same subnet and/or not having a route for that subnet. > Possibly some frame-relay flashback? Anyway, this sounds to me as bad as > using unnumbered. B.A.D. Why? Using unnumbered on point to point links works quite well. The only place where I've found a numbered link to be more useful on a point to point link is when BGP peering needs to be established across the link and the numbered link will prevent the need to create a static route to the remote neighbor address. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 12 02:09:17 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5C99Hk7013371; Wed, 12 Jun 2002 02:09:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5C99Hs3013370; Wed, 12 Jun 2002 02:09:17 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5C99Dk7013363 for ; Wed, 12 Jun 2002 02:09:13 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA02287 for ; Wed, 12 Jun 2002 02:09:16 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.96.5]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA17382 for ; Wed, 12 Jun 2002 03:09:02 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g5C98AM19017; Wed, 12 Jun 2002 16:08:10 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g5C95gs19550; Wed, 12 Jun 2002 16:05:42 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: "Steven M. Bellovin" cc: rbrabson@us.ibm.com, ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-Reply-To: <20020611150526.F31F77B53@berkshire.research.att.com> References: <20020611150526.F31F77B53@berkshire.research.att.com> Date: Wed, 12 Jun 2002 16:05:42 +0700 Message-ID: <19548.1023872742@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 11 Jun 2002 11:05:25 -0400 From: "Steven M. Bellovin" Message-ID: <20020611150526.F31F77B53@berkshire.research.att.com> | I think this is the key point. Regardless of the possible benefits of | site-local addresses -- and I'm willing to withhold judgment on that | point -- we don't know in detail how to make them work. That's true. Te question is really should we go ahead and figure out the answer, or should be just decide that we don't know the answer today, and consequently, we will delete the mechanism, so even if someone does work out the answer tomorrow, it is all irrelevant, because there's no way to use it left in the protocols any more. There is way too much of the latter in all areas of the IETF these days. I don't know the answer to this today, so I will forbid it forever. | At a minimum, we need changes in routing and the DNS. No. At a minimum we need changes to nothing at all. Not changing routing might alter the way SL addresses get used - effectively imposing DMZ's between sites. With that, a SL address (to routing) is simply the same as any other address, scopes are irrelevant (as there's never two different ones touching any node). The most we need is a way to filter routing information passed around - and that we already have. The DNS needs no changes whatever we do. We simply never put SL addresses in the DNS, no matter what. There seems to be this fixation that the DNS is the only thing that can ever be used to translate between names and addresses (some of the side discussion on addr->name translations is showing that). People, the DNS didn't always exist, and we still managed name to address translations! While I wouldn't advocate going back to host tables as a translation method - the fact that there was once a world with no DNS shows that it is possible to do things other ways. I still believe that the right way to use SL addresses (other than in disconnected sites, where SL is all that exists, and they can go in the local private disconnected DNS with no problems at all), is for an app for which use of a SL address makes sense, to indicate that to the resolver when it does its name lookup. The resolver then looks up the DNS (the normal way) and gets back global addresses (and only global addresses). Then using (one of the) node's local site local addresses, the resolver sends a packet to the global address(es) received - a ICMP node information, asking for the node's site local addresses (on the interface the packet arrives). If there is no site border in the way it will get a reply with the relevant site local addresses included. It then simply places those addresses in the information it returns to the application (most likely inserting them ahead of the globals in the list returned, but an API option could indicate to return only the site locals when any are available, suppressing global addreses). >From this we get site local addresses to use, and there's none of them at all in the DNS - the cost is a couple of extra packets when the application translates its names. And only for applications that have indicated that using SL addresses makes sense. That really means only for long lived apps, as the main reason for using SL addresses (disconnected sites aside) is so a renumbering event wouldn't affect the connection. If the connection isn't likely to last longer than old addresses would be in deprecated state, then using SL addresses instead of globals makes no sense. Hence apps that have short lived connections typically (which means less than multiple hours - perhaps even mode) would never do this. No extra overhead at all for http, smtp, ... The other implication from this, of course, is that all nodes on the global internet (that are ever to be reached based upon their names) would be required to have global addresses, as that's all the DNS ever returns. That's fine - let's get rid of the absurd notions that having only a private address (1918, SL, anything else) has any benefits at all - they don't - all they do is provide restrictions (not beneficial ones, they can't be relied upon). Nodes that are never to be named could have SL addresses only, though personally I don't see the point. | We may need new global | namespaces as well, with all that implies for co-ordination and | administrative overhead. Not for SL addresses as defined now. Some proposed modifications of SL addresses might need such things (or might not, NUSLA's didn't), but this part is certainly irrelevant for now. SL addresses are just fine. More work is needed on them for sure, to make them even more useful, and suggesting to people that until the implementations better support them, they should consider very carefully before enabling the things, is all just fine. But there's no reason at all to be even considering deleting them. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 12 03:06:03 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5CA63k7013421; Wed, 12 Jun 2002 03:06:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5CA62Q2013420; Wed, 12 Jun 2002 03:06:02 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5CA5xk7013413 for ; Wed, 12 Jun 2002 03:05:59 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA09972 for ; Wed, 12 Jun 2002 03:06:01 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.96.5]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA26829; Wed, 12 Jun 2002 04:05:49 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g5CA58M00019; Wed, 12 Jun 2002 17:05:09 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g5CA2Zs19616; Wed, 12 Jun 2002 17:02:37 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Alain Durand cc: Michel Py , ipng@sunroof.eng.sun.com Subject: Re: Review of"Use of /127 Prefix Length Between Routers Considered Harmful" In-Reply-To: <8AFF725B-7DDF-11D6-A8D7-00039376A6AA@sun.com> References: <8AFF725B-7DDF-11D6-A8D7-00039376A6AA@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 12 Jun 2002 17:02:35 +0700 Message-ID: <19614.1023876155@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 12 Jun 2002 01:36:51 -0700 From: Alain Durand Message-ID: <8AFF725B-7DDF-11D6-A8D7-00039376A6AA@sun.com> | This sounds like F.U.D. to me. Why do you think it is B.A.D.? Why are we even having this discussion (at this level)? Different people like to number p2p links different ways, and there's no reason to prohibit, or insist on, any of them. Which is the best is very much a matter of opinion, they all have some advantages and some drawbacks. Personally, I don't see nearly as many problems with /127 as the draft seems to - but on the other hand, I also see no possible potential drawbacks from just using /112 instead - it is just absurd to imagine that the difference in address space to number all the p2p's between /112 and /127 is ever going to matter to anyone. I have been using /112 on these things for a while now (I used to use /127). The draft is just fine, with or without the extra mention of 2 * /128 as yet another way to "number" a p2p link (a link numbered that way is generally just the same as a unnumbered link - the link itself has no prefix assigned). Let's just agree to ship it. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 12 03:31:05 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5CAV5k7013507; Wed, 12 Jun 2002 03:31:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5CAV5gE013506; Wed, 12 Jun 2002 03:31:05 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5CAV1k7013499 for ; Wed, 12 Jun 2002 03:31:01 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA15755 for ; Wed, 12 Jun 2002 03:31:03 -0700 (PDT) Received: from starfruit.itojun.org (ny-ppp009.iij-us.net [216.98.99.9]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA23729 for ; Wed, 12 Jun 2002 04:32:42 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id B847D7B9; Wed, 12 Jun 2002 19:29:31 +0900 (JST) To: Antonio Querubin Cc: ipng@sunroof.eng.sun.com In-reply-to: tony's message of Tue, 11 Jun 2002 23:07:32 -1000. 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: Review of"Use of /127 Prefix Length Between Routers Considered Harmful" From: Jun-ichiro itojun Hagino Date: Wed, 12 Jun 2002 19:29:31 +0900 Message-Id: <20020612102931.B847D7B9@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Why? Using unnumbered on point to point links works quite well. The only >place where I've found a numbered link to be more useful on a point to >point link is when BGP peering needs to be established across the link and >the numbered link will prevent the need to create a static route to the >remote neighbor address. checking - "unnumbered" meaning "link-local address only", am I correct? yes, p2p link without global address works just fine. 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 Jun 12 03:42:25 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5CAgPk7013551; Wed, 12 Jun 2002 03:42:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5CAgOKm013549; Wed, 12 Jun 2002 03:42:24 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5CAgJk7013534 for ; Wed, 12 Jun 2002 03:42:19 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA16002 for ; Wed, 12 Jun 2002 03:42:21 -0700 (PDT) Received: from gau.lava.net (gau.lava.net [64.65.64.28]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA23561 for ; Wed, 12 Jun 2002 03:42:21 -0700 (PDT) Received: from malasada.lava.net ([64.65.64.17]) (1321 bytes) by gau.lava.net; Wed, 12 Jun 2002 00:42:16 -1000 (HST) via sendmail [esmtp] id for Date: Wed, 12 Jun 2002 00:42:16 -1000 (HST) From: Antonio Querubin To: Jun-ichiro itojun Hagino cc: ipng@sunroof.eng.sun.com Subject: Re: Review of"Use of /127 Prefix Length Between Routers Considered Harmful" In-Reply-To: <20020612102931.B847D7B9@starfruit.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 12 Jun 2002, Jun-ichiro itojun Hagino wrote: > >Why? Using unnumbered on point to point links works quite well. The only > >place where I've found a numbered link to be more useful on a point to > >point link is when BGP peering needs to be established across the link and > >the numbered link will prevent the need to create a static route to the > >remote neighbor address. > > checking - "unnumbered" meaning "link-local address only", am I > correct? yes, p2p link without global address works just fine. No, I meant unnumbered which has no requirement on the scope. In either case though you're correct in that a point to point link doesn't really need a global address in many cases. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 12 03:42:25 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5CAgOk7013548; Wed, 12 Jun 2002 03:42:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5CAgO3h013547; Wed, 12 Jun 2002 03:42:24 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5CAgIk7013533 for ; Wed, 12 Jun 2002 03:42:19 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA15998 for ; Wed, 12 Jun 2002 03:42:20 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.96.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA28295 for ; Wed, 12 Jun 2002 04:43:56 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g5CAfaM25193; Wed, 12 Jun 2002 17:41:36 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g5CAd3s19854; Wed, 12 Jun 2002 17:39:06 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Jun-ichiro itojun Hagino cc: Antonio Querubin , ipng@sunroof.eng.sun.com Subject: Re: Review of"Use of /127 Prefix Length Between Routers Considered Harmful" In-Reply-To: <20020612102931.B847D7B9@starfruit.itojun.org> References: <20020612102931.B847D7B9@starfruit.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 12 Jun 2002 17:39:03 +0700 Message-ID: <19852.1023878343@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 12 Jun 2002 19:29:31 +0900 From: Jun-ichiro itojun Hagino Message-ID: <20020612102931.B847D7B9@starfruit.itojun.org> | checking - "unnumbered" meaning "link-local address only", am I | correct? yes, p2p link without global address works just fine. As I just said, I don't really think we need to be having this discussion. But a question for those who like unnumbered links - do they work if a host (not being a router) that has a p2p link implements the "strong" model of addressing? If so, how? (Assuming the host wants to be reached via a global address of course, and assuming it desires to be reached using the p2p link - that being the purpose of installing it). kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 12 03:47:58 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5CAlwk7013575; Wed, 12 Jun 2002 03:47:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5CAlwT7013574; Wed, 12 Jun 2002 03:47:58 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5CAltk7013567 for ; Wed, 12 Jun 2002 03:47:55 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA27604 for ; Wed, 12 Jun 2002 03:47:57 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA25879 for ; Wed, 12 Jun 2002 03:47:56 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g5CAltb32577 for ; Wed, 12 Jun 2002 13:47:55 +0300 Date: Wed, 12 Jun 2002 13:47:54 +0300 (EEST) From: Pekka Savola To: ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-ietf-ipv6-router-selection-02.txt In-Reply-To: <200206111105.HAA17778@ietf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Just a few comments: 3.4. Router Reachability Probing When a host avoids using a non-reachable router X and instead uses another router Y, and the host would have used router X if router X were reachable, then the host SHOULD probe router X's reachability by sending a Neighbor Solicitation. A host MUST NOT probe a router's reachability in the absence of useful traffic that the host would have sent to the router if it were reachable. [...] ==> I think 'MUST NOT' there is very strict wording. Is it really necessary to be so? Would SHOULD NOT be sufficient? We probably agree that it shouldn't be done because it just wastes bandwidth but I don't think nodes doing it would actually break anything. ND is being performed in the presence of real traffic anyway (at least my KAME box does so).. When a host chooses from multiple equivalent routers, it MUST choose randomly. ==> Did we settle this SHOULD/MUST debate? I'm not sure if MUST is best, but I can deal with that. Routers SHOULD NOT include in a Router Advertisement two Route Information Options with the same Prefix and Prefix Length ==> s/in a Router Advertisement two Route Information Options/ two Route Information Options in a Router Advertisement/ ? On Tue, 11 Jun 2002 Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. > > Title : Default Router Preferences, More-Specific Routes and > Load Sharing > Author(s) : R. Draves, B. Hinden > Filename : draft-ietf-ipv6-router-selection-02.txt > Pages : 13 > Date : 10-Jun-02 > > This document describes two changes to Neighbor Discovery. The first > change is an optional extension to Router Advertisement messages for > communicating default router preferences and more-specific routes > from routers to hosts. This improves the ability of hosts to pick an > appropriate router, especially when the host is multi-homed and the > routers are on different links. The preference values and specific > routes advertised to hosts require administrative configuration; > they are not automatically derived from routing tables. The second > change is a mandatory modification of the conceptual sending > algorithm to support load-sharing among equivalent routers. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipv6-router-selection-02.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the message. > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-ipv6-router-selection-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-ipv6-router-selection-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. > -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 12 04:00:58 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5CB0wk7013596; Wed, 12 Jun 2002 04:00:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5CB0wSS013595; Wed, 12 Jun 2002 04:00:58 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5CB0tk7013588 for ; Wed, 12 Jun 2002 04:00:55 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA20311 for ; Wed, 12 Jun 2002 04:00:57 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.96.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA05457 for ; Wed, 12 Jun 2002 05:02:28 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g5CB09M06865; Wed, 12 Jun 2002 18:00:10 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g5CAvfs19944; Wed, 12 Jun 2002 17:57:41 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Antonio Querubin cc: Jun-ichiro itojun Hagino , ipng@sunroof.eng.sun.com Subject: Re: Review of"Use of /127 Prefix Length Between Routers Considered Harmful" In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 12 Jun 2002 17:57:41 +0700 Message-ID: <19942.1023879461@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 12 Jun 2002 00:42:16 -1000 (HST) From: Antonio Querubin Message-ID: | a point to point link doesn't really | need a global address in many cases. Assuming this is true, the inference is that there are some cases where a global address is required. That's true: I know of one - munnari.oz.au has a P2P link for IPv6, and that's its only IPv6 connectivity. Assuming that it is to have a global v6 address (and it does) it has to be assigned to the P2P link, there is nothing else to assign it to (it isn't a router, just a host, and the p2p link is a tunnel, of course, not that that matters). Given that, the question is how the global address space should be used on P2P links when addresses are required, surely? The question of what to do when they're not required (and not wanted either) is not relevant, is it? So, can we please get off the rat hole issue of whether or not p2p links should be numbered, and return to discussing the draft, which gives some guidelines on how to number them (and how not to) when they are being numbered? (With, as I recall, though it has been a while since I looked, no statements at all saying that p2p links actually should be numbered). kre ps: there's no v6 DNS entry for munnari yet, so don't bother looking. Its v6 connectivity is weird, and I don't want to subject that path to the kind of traffic volumes that munnari tends to attract - and perhaps would, even over the 6bone. Its A6 record will appear once I get better connectivity, which means when the local academic network people manage to get themselves connected (they have the APNIC prefix ready...) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 12 05:30:54 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5CCUsk7013748; Wed, 12 Jun 2002 05:30:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5CCUsOH013747; Wed, 12 Jun 2002 05:30:54 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5CCUok7013740 for ; Wed, 12 Jun 2002 05:30:50 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA01338 for ; Wed, 12 Jun 2002 05:30:53 -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 GAA19917 for ; Wed, 12 Jun 2002 06:30:51 -0600 (MDT) Received: from localhost ([3ffe:501:100f:1048:fd5e:6e52:ab0f:8f5d]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g5CCUY894087; Wed, 12 Jun 2002 21:30:34 +0900 (JST) Date: Wed, 12 Jun 2002 21:30:37 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Thomas Narten Cc: ipng@sunroof.eng.sun.com Subject: Re: IESG comments on draft-ietf-ipngwg-default-addr-select-06.txt In-Reply-To: <200206111619.g5BGJGv08724@rotala.raleigh.ibm.com> References: <200206111619.g5BGJGv08724@rotala.raleigh.ibm.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 54 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Tue, 11 Jun 2002 12:19:16 -0400, >>>>> Thomas Narten said: > Is the above a reasonable way forward? (Individual responses, even if > they are along the lines of "fine with me" would be appreciated, as > this document is needed soon to meet a 3GPP deadline). I'm personally okay with the change, but my honest impression is that preferring temporary addresses is overkill. Some detailed, random thoughts: It may be true that there are people who are concerned about privacy leakage due to fixed interface IDs. But is the group really large that can affect all other's behavior? I implemented RFC 3041 on the KAME stack over a year ago and FreeBSD 4.4 shipped with the implementation last summar, but I've never heard of a user who is actually using it for daily use. Of course, the fact I've never seen such a user does not necessarily mean there is actually no user. But I'm quite confident there are only few real requirements for the privacy extension at this moment. So, we do not have to be in a hurry to prefer the temporary address by default. As for the impacts on the applications' behavior, I don't worry so much. I've configured my laptop to prefer temporary addresses over a year (for experiences - I'm not a privacy-conscious guy), and I've never seen a trouble with the environment. I admit I'm only using a limited type of applications (and we cannot be sure about future applications), but I believe it covers a certain amount of today's major applications, including pop client, smtp client, www client, ftp client, ssh client, and DNS resolver. In particular, I don't worry about the "relatively short lifetime" through the experience. The lack of reverse lookups may be a bit more serious, but, IMO, this issue is not necessarily specific to the temporary vs public issue and should be discussed in a wider framework. BTW: even if we go with the change, I think the following part should be revised. > One possible heuristic > for distinguishing these cases is to assume that an application > that invokes a passive open (as its first network usage) is a > server, while an application that first invokes an active open be > assumed to be a client. As some other guy pointed out, real world examples are not that simple. 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 Jun 12 05:40:57 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5CCevk7013772; Wed, 12 Jun 2002 05:40:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5CCevUC013771; Wed, 12 Jun 2002 05:40:57 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5CCerk7013764 for ; Wed, 12 Jun 2002 05:40:53 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA21189 for ; Wed, 12 Jun 2002 05:40:55 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA16064; Wed, 12 Jun 2002 06:40:51 -0600 (MDT) Received: from localhost ([3ffe:501:100f:1048:fd5e:6e52:ab0f:8f5d]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g5CCek894158; Wed, 12 Jun 2002 21:40:46 +0900 (JST) Date: Wed, 12 Jun 2002 21:40:50 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Keith Moore Cc: Erik Nordmark , Thomas Narten , ipng@sunroof.eng.sun.com Subject: Re: IESG comments on draft-ietf-ipngwg-default-addr-select-06.txt In-Reply-To: References: <200206112320.g5BNKZn27758@astro.cs.utk.edu> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 24 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Wed, 12 Jun 2002 17:39:54 +0900, >>>>> JINMEI Tatuya said: >> I've got some other problems with the document also - specifically >> the idea that link-local addresses are preferable to global addresses. > Please let me confirm: are you referring to Rule 2 of source address > selection? Perhaps you are talking about Rule 8 of destination address selection: Rule 8: Prefer smaller scope. If Scope(DA) < Scope(DB), then prefer DA. Similarly, if Scope(DA) > Scope(DB), then prefer DB. This rule may be sometimes controversial, but I personally think it is reasonable, because we can (in theory) expect better reachability for a smaller scope of destinations. This is especially true for a link-local destination where we don't need L3 routing. 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 Jun 12 05:51:18 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5CCpIk7013850; Wed, 12 Jun 2002 05:51:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5CCpHtM013849; Wed, 12 Jun 2002 05:51:17 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5CCpDk7013842 for ; Wed, 12 Jun 2002 05:51:14 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA04532 for ; Wed, 12 Jun 2002 05:51:17 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA20864 for ; Wed, 12 Jun 2002 06:51:16 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5CCp2n20237; Wed, 12 Jun 2002 08:51:02 -0400 (EDT) Message-Id: <200206121251.g5CCp2n20237@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: Keith Moore , Erik Nordmark , Thomas Narten , ipng@sunroof.eng.sun.com Subject: Re: IESG comments on draft-ietf-ipngwg-default-addr-select-06.txt In-reply-to: (Your message of "Wed, 12 Jun 2002 21:40:50 +0900.") Date: Wed, 12 Jun 2002 08:51:02 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >> I've got some other problems with the document also - specifically > >> the idea that link-local addresses are preferable to global addresses. > > > Please let me confirm: are you referring to Rule 2 of source address > > selection? > > Perhaps you are talking about Rule 8 of destination address selection: > > Rule 8: Prefer smaller scope. > If Scope(DA) < Scope(DB), then prefer DA. Similarly, if Scope(DA) > > Scope(DB), then prefer DB. > > This rule may be sometimes controversial, but I personally think it is > reasonable, because we can (in theory) expect better reachability for > a smaller scope of destinations. This is especially true for a > link-local destination where we don't need L3 routing. Rule #2 is not a problem, rule #8 is. The problem is that the address selected for one connection pair may end up getting reused in other scope. So if rule 8 results in an LL or SL address being used, there might be an attempt to reuse that address (perhaps by another application component) in a different scope. There really should be a rule to the effect "avoid scoped addresses if at all possible". Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 12 05:51:51 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5CCppk7013860; Wed, 12 Jun 2002 05:51:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5CCpo8F013859; Wed, 12 Jun 2002 05:51:50 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5CCpjk7013852 for ; Wed, 12 Jun 2002 05:51:45 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA23945 for ; Wed, 12 Jun 2002 05:51:48 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA18649 for ; Wed, 12 Jun 2002 06:53:29 -0600 (MDT) Received: from localhost ([3ffe:501:100f:1048:fd5e:6e52:ab0f:8f5d]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g5CCpd894254; Wed, 12 Jun 2002 21:51:39 +0900 (JST) Date: Wed, 12 Jun 2002 21:51:42 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Dave Thaler" Cc: "Pekka Savola" , "Alain Durand" , Subject: Re: IPv6 Scoped Addresses and Routing Protocols In-Reply-To: <2E33960095B58E40A4D3345AB9F65EC1047CF203@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> References: <2E33960095B58E40A4D3345AB9F65EC1047CF203@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 21 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Tue, 11 Jun 2002 10:43:13 -0700, >>>>> "Dave Thaler" said: > Personally I think DNS reverse lookups should go away, not > site-locals. In my opinion, using ICMP name lookups to the > node itself is a much better solution to making reverse > lookups work, and they would work fine for scoped addresses. > (Yes it would only work when the node is reachable, but I > don't consider that a problem, whereas DNS has bigger problems.) Personally I agree with you, and the issue of DNS reverse lookup vs ICMP name lookup (or whatever possible) is important. However, I'm afraid this can make the site-local discussion too complicated. Also, the reverse lookup issue is not only related to site-locals but to link-locals or temporary addresses, so we should discuss this at a separate, generic thread. 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 Jun 12 06:06:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5CD6jk7013903; Wed, 12 Jun 2002 06:06:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5CD6jmY013902; Wed, 12 Jun 2002 06:06:45 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5CD6ek7013888 for ; Wed, 12 Jun 2002 06:06:41 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA07517 for ; Wed, 12 Jun 2002 06:06:44 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA18709 for ; Wed, 12 Jun 2002 06:06:43 -0700 (PDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5CD6bn22980; Wed, 12 Jun 2002 09:06:37 -0400 (EDT) Message-Id: <200206121306.g5CD6bn22980@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: Thomas Narten , ipng@sunroof.eng.sun.com Subject: Re: IESG comments on draft-ietf-ipngwg-default-addr-select-06.txt In-reply-to: (Your message of "Wed, 12 Jun 2002 21:30:37 +0900.") Date: Wed, 12 Jun 2002 09:06:37 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > As for the impacts on the applications' behavior, I don't worry so > much. I've configured my laptop to prefer temporary addresses over a > year (for experiences - I'm not a privacy-conscious guy), and I've > never seen a trouble with the environment. I admit I'm only using a > limited type of applications (and we cannot be sure about future > applications), but I believe it covers a certain amount of today's > major applications, including pop client, smtp client, www client, ftp > client, ssh client, and DNS resolver. In particular, I don't worry > about the "relatively short lifetime" through the experience. I don't think it's reasonable to allow "today's major applications" to constrain the behavior of all present and future applications. I work with p2p and distributed systems every day, and trying to deal with temporary and scoped addresses really is very difficult for them. If we are not careful we will end up imposing NAT-like restrictions in IPv6 even if IPv6 does not have NATs. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 12 06:15:12 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5CDFBk7013932; Wed, 12 Jun 2002 06:15:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5CDFBlq013931; Wed, 12 Jun 2002 06:15:11 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5CDF5k7013924 for ; Wed, 12 Jun 2002 06:15:05 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA00251 for ; Wed, 12 Jun 2002 06:15:08 -0700 (PDT) Received: from mail5.nc.rr.com (fe5.southeast.rr.com [24.93.67.52]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA03444 for ; Wed, 12 Jun 2002 07:15:07 -0600 (MDT) Received: from mail pickup service by mail5.nc.rr.com with Microsoft SMTPSVC; Tue, 11 Jun 2002 15:25:02 -0400 Received: from ncmx01.mgw.rr.com ([24.93.67.251]) by mail5.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Mon, 10 Jun 2002 14:33:47 -0400 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ncmx01.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5AIXltH007518 for ; Mon, 10 Jun 2002 14:33:47 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA26665; Mon, 10 Jun 2002 12:32:01 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA17006; Mon, 10 Jun 2002 11:31:53 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5AITok7007885; Mon, 10 Jun 2002 11:29:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5AIToRA007884; Mon, 10 Jun 2002 11:29:50 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5AITmk7007876 for ; Mon, 10 Jun 2002 11:29:48 -0700 (PDT) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g5AITloR003234 for ; Mon, 10 Jun 2002 11:29:47 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g5AITlg8003233 for ipng@sunroof.eng.sun.com; Mon, 10 Jun 2002 11:29:47 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g59JBik7004915 for ; Sun, 9 Jun 2002 12:11:44 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA22182 for ; Sun, 9 Jun 2002 12:11:47 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA01200 for ; Sun, 9 Jun 2002 13:11:47 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id 452AE6A907; Sun, 9 Jun 2002 22:11:46 +0300 (EEST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id E2B796A901; Sun, 9 Jun 2002 22:11:37 +0300 (EEST) Message-ID: <3D03A8B3.1020309@piuha.net> Date: Sun, 09 Jun 2002 22:12:51 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: James Kempf Cc: Pekka Savola , ipng@sunroof.eng.sun.com Subject: Re: Securing Neighbor Discovery BOF References: <003401c20f81$27268970$1e6015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk James Kempf wrote: > Pekka, > > We will shortly be releasing the ABK draft with a statement like the > Photuris statement, which was included in IKE. Sounds interesting! > Also, some people believe that IPsec will work. If some way can be found > around the keying problem, it could be a viable alternative. There may be ways around some of the problems, in the way that my previous e-mail outlined. However, generally speaking you will end up with a solution that separates good guys from the bad guys. But it isn't necessarily going to be able to indicate which ones of the "good guys" can use which IP addresses. This may or may not be sufficient, depending on who you ask. Jari P.S. There's also a separate e-mail list set up for the discussions. Send e-mail to ietf-send-request@standards.ericsson.net with the text "subscribe" in the body to join. The name of the list is "SEND" for Secure Neighbour Discovery. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Jun 12 06:21:40 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5CDLek7014870; Wed, 12 Jun 2002 06:21:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5CDLeev014869; Wed, 12 Jun 2002 06:21:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5CDLZk7014856 for ; Wed, 12 Jun 2002 06:21:35 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA02233 for ; Wed, 12 Jun 2002 06:21:38 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA25829 for ; Wed, 12 Jun 2002 06:21:38 -0700 (PDT) Received: from localhost ([3ffe:501:100f:1048:fd5e:6e52:ab0f:8f5d]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g5CDKg894462; Wed, 12 Jun 2002 22:20:42 +0900 (JST) Date: Wed, 12 Jun 2002 22:20:46 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Keith Moore Cc: Thomas Narten , ipng@sunroof.eng.sun.com Subject: Re: IESG comments on draft-ietf-ipngwg-default-addr-select-06.txt In-Reply-To: <200206121306.g5CD6bn22980@astro.cs.utk.edu> References: <200206121306.g5CD6bn22980@astro.cs.utk.edu> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 28 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Wed, 12 Jun 2002 09:06:37 -0400, >>>>> Keith Moore said: >> As for the impacts on the applications' behavior, I don't worry so >> much. I've configured my laptop to prefer temporary addresses over a >> year (for experiences - I'm not a privacy-conscious guy), and I've >> never seen a trouble with the environment. I admit I'm only using a >> limited type of applications (and we cannot be sure about future >> applications), but I believe it covers a certain amount of today's >> major applications, including pop client, smtp client, www client, ftp >> client, ssh client, and DNS resolver. In particular, I don't worry >> about the "relatively short lifetime" through the experience. > I don't think it's reasonable to allow "today's major applications" > to constrain the behavior of all present and future applications. Okay, perhaps I was not very good about the wording, but my intention was to make the discussion more concrete; it seems to me that the discussion in this thread so far was too abstract (just saying "applications", "servers" or "clients" are not so meaningful). I wanted to provide concrete examples based on real experiences. I fully understand that we cannot make a decision just because of limited and personal experiences at this moment. 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 Jun 12 06:30:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5CDUak7015070; Wed, 12 Jun 2002 06:30:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5CDUaJx015069; Wed, 12 Jun 2002 06:30: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.12.4/8.12.4) with ESMTP id g5CDUWk7015062 for ; Wed, 12 Jun 2002 06:30:32 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA15552 for ; Wed, 12 Jun 2002 06:30:36 -0700 (PDT) Received: from mail5.nc.rr.com (fe5.southeast.rr.com [24.93.67.52]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA29813 for ; Wed, 12 Jun 2002 06:30:35 -0700 (PDT) Received: from mail pickup service by mail5.nc.rr.com with Microsoft SMTPSVC; Tue, 11 Jun 2002 15:25:26 -0400 Received: from ncmx02.mgw.rr.com ([24.93.67.222]) by mail5.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Mon, 10 Jun 2002 14:34:36 -0400 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ncmx02.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5AIYaIa005251 for ; Mon, 10 Jun 2002 14:34:37 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA07562; Mon, 10 Jun 2002 12:34:31 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA28640; Mon, 10 Jun 2002 11:32:47 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5AIUXk7007901; Mon, 10 Jun 2002 11:30:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5AIUXpq007900; Mon, 10 Jun 2002 11:30:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5AIUVk7007893 for ; Mon, 10 Jun 2002 11:30:32 -0700 (PDT) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g5AIUUoR003242 for ; Mon, 10 Jun 2002 11:30:30 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g5AIUU3c003241 for ipng@sunroof.eng.sun.com; Mon, 10 Jun 2002 11:30:30 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5AFxJk7007439 for ; Mon, 10 Jun 2002 08:59:19 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA19210 for ; Mon, 10 Jun 2002 08:58:07 -0700 (PDT) Received: from cisco.com (edinburgh.cisco.com [144.254.112.76]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA10786 for ; Mon, 10 Jun 2002 09:58:06 -0600 (MDT) Received: (from dfawcus@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id QAA18465; Mon, 10 Jun 2002 16:57:57 +0100 (BST) Date: Mon, 10 Jun 2002 16:57:57 +0100 From: Derek Fawcus To: "Steven M. Bellovin" Cc: Hiroki Ishibashi , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols Message-ID: <20020610165757.E7031@edinburgh.cisco.com> Mail-Followup-To: "Steven M. Bellovin" , Hiroki Ishibashi , ipng@sunroof.eng.sun.com References: <20020610114319.F12237B4B@berkshire.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20020610114319.F12237B4B@berkshire.research.att.com>; from smb@research.att.com on Mon, Jun 10, 2002 at 07:43:18AM -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, Jun 10, 2002 at 07:43:18AM -0400, Steven M. Bellovin wrote: > In message <6EC21033B3E449bashi@ipv6.nec.co.jp>, Hiroki Ishibashi writes: > >Steven M. Bellovin wrote: > > > > >>I'm still confused. If a packet arrives on a site-enabled interface, > >>addressed to multicast address AllSPFRouters, and with protocol number > >>89 (OSPF), to which process is it delivered? Does something actually > >>peek inside the packet to see if it's advertising global or site-local > >>addresses when making the dispatching decision? > > > >"2.4. Explicit support for multiple instances per link" in RFC2740 > >is the one to be used to identify a process (instance) to which packet > >are delivered. Not necessary to peek into LSAs for the dispatching > >decision. > > > > I must be missing something; I still don't understand. > > Let's look at a simple case, a router with two physical interfaces with > one attached to the site backbone, and one feeding a departmental LAN. > I'm perfectly willing to assume multiple logical interfaces on either > physical interface. > > Let's consider the backbone interface. It's going to be seeing two > types of routing advertisement, site-local and global. When an > incoming OSPF packet arrives, it's addressed to the same multicast > address in either case. To which logical interface does it belong? It looks as if the intended use of this Instance ID is to have multiple groups of OSPF routers running on the same link, _which know nothing about each other_. It doesn't look as if it's intended that any particular router would ever have a given interface assigned more than one Instance ID. Mind that said, it would be possible to do this, with one instance ID for globals and one for site locals, but it would require some form of receive demultiplexing to deliver the appropriate packets to the appropriate 'instance' of OSPF running locally. This would obviouly require peeking into the OSPF header, but not into the LSAs. e.g. a unix method - have a listener process on protocol 89, it peeks at the instance ID, and demuxes the packets to the appropriate local OSPF process. For Tx the OSPF process can send direct to the interface. DF -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Jun 12 07:41:27 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5CEfRk7015976; Wed, 12 Jun 2002 07:41:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5CEfRiL015975; Wed, 12 Jun 2002 07:41:27 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5CEfNk7015968 for ; Wed, 12 Jun 2002 07:41:23 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA29067 for ; Wed, 12 Jun 2002 07:41:25 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA16272; Wed, 12 Jun 2002 08:43:06 -0600 (MDT) Received: from kenawang ([147.11.72.26]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id HAA29911; Wed, 12 Jun 2002 07:39:49 -0700 (PDT) Message-Id: <4.2.2.20020612103350.022dca80@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 12 Jun 2002 10:38:24 -0400 To: Erik Nordmark From: Margaret Wasserman Subject: Re: IESG comments on draft-ietf-ipngwg-default-addr-select-06.txt Cc: Keith Moore , Thomas Narten , ipng@sunroof.eng.sun.com In-Reply-To: References: <"Your message with ID" <200206111704.g5BH4rn23548@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi All, >The proposed text is trying to say that temporary addresses are preferable >but that there might be issues (such as applications having problems) >which consistitute a good enough reason to not follow the default. >Thus there is significant freedom for implementors to use their best >judgement based on their knowledge about the applications. Is it optional for a vendor to implement temporary addresses? Is it optional for a user to configure site-local addresses on a box (or perhaps even for a vendor to support them)? One reason that has been put forth for having a fixed set of address selection rules is that it will be possible for implementations to know what addresses will be preferred, and override that behaviour if desired. I'm not quite sure how this works when it isn't clear that all vendors will implement all address types (temporary, site-local, etc.), or that all address types will be configured for a given system. This particularly becomes problematic when optional address types (temporary, perhaps site-local) are preferred over required address types (link-local and global). Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 12 08:04:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5CF4Nk7016018; Wed, 12 Jun 2002 08:04:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5CF4N5c016017; Wed, 12 Jun 2002 08:04:23 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5CF4Kk7016010 for ; Wed, 12 Jun 2002 08:04:20 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA07882 for ; Wed, 12 Jun 2002 08:04:23 -0700 (PDT) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA22836 for ; Wed, 12 Jun 2002 08:04:23 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.04) id 17I9fT-000CIw-00; Wed, 12 Jun 2002 08:04:15 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Pekka Savola Cc: Alain Durand , Michel Py , Bob Hinden , Subject: Re: Review of "Use of /127 Prefix Length Between Routers Considered Harmful" References: Message-Id: Date: Wed, 12 Jun 2002 08:04:15 -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Of course, 2 /128's could also be used. This seems like an > elegant solution, but may be operationally more cumbersome with > some implementations (e.g. requiring to set a static route). yuck! -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 12 08:24:15 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5CFOFk7016067; Wed, 12 Jun 2002 08:24:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5CFOFq6016066; Wed, 12 Jun 2002 08:24:15 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5CFOBk7016059 for ; Wed, 12 Jun 2002 08:24:11 -0700 (PDT) Received: from lillen ([192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g5CFO5K13233; Wed, 12 Jun 2002 17:24:05 +0200 (MEST) Date: Wed, 12 Jun 2002 17:22:49 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: IESG comments on draft-ietf-ipngwg-default-addr-select-06.txt To: Keith Moore Cc: Erik Nordmark , Thomas Narten , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <200206112320.g5BNKZn27758@astro.cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I've got some other problems with the document also - specifically > the idea that link-local addresses are preferable to global addresses. > Global addresses are always preferable because all applications > can tolerate them. At most, LL addresses should be used only > when there is no other alternative, because some applications > need to treat them specially (this isn't as bad in v6 as in v4) > But LL addresses should probably be used only when they are > explicitly specified. Part of the issue here depends on how the application finds out addresses of scope less than global. Link-local addresses don't make sense in the DNS (and site-local don't make sense in the DNS except when a site is running a two-faced DNS). Thus if the application is going to explicitly be configured to use a less-than global address, or explicitly use some link-local name resolution protocol, this isn't likely to cause a problem in practise. And for the applications, such as routing daemons, that communicate using link-local (multicast) addresses the specification causes the right behavior - a link-local source address will be used when the destination is link local. 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 Jun 12 08:50:29 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5CFoSk7016146; Wed, 12 Jun 2002 08:50:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5CFoSMS016145; Wed, 12 Jun 2002 08:50:28 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5CFoOk7016138 for ; Wed, 12 Jun 2002 08:50:24 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA23176 for ; Wed, 12 Jun 2002 08:50:27 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA07501 for ; Wed, 12 Jun 2002 09:50:26 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5CFoIn16696; Wed, 12 Jun 2002 11:50:18 -0400 (EDT) Message-Id: <200206121550.g5CFoIn16696@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Erik Nordmark cc: Keith Moore , Thomas Narten , ipng@sunroof.eng.sun.com Subject: Re: IESG comments on draft-ietf-ipngwg-default-addr-select-06.txt In-reply-to: (Your message of "Wed, 12 Jun 2002 17:22:49 +0200.") Date: Wed, 12 Jun 2002 11:50:18 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Part of the issue here depends on how the application finds out addresses > of scope less than global. Link-local addresses don't make sense in > the DNS (and site-local don't make sense in the DNS except when a site > is running a two-faced DNS). > Thus if the application is going to explicitly be configured to use > a less-than global address, or explicitly use some link-local name resolution > protocol, this isn't likely to cause a problem in practise. I can sort of accept that if you explicitly configure an app to use a limited-scope address, they you deserve whatever you get. however I somehow doubt that the vast majority of Internet users will understand the difference and why choosing an LL or SL address might cause their app to break. also, there are other ways to discover an address besides DNS and explicit configuration - for instance, by looking at a source address of a received message. > And for the applications, such as routing daemons, that communicate using > link-local (multicast) addresses the specification causes the right behavior - > a link-local source address will be used when the destination is link local. I'd certainly consider it acceptable for routing daemons and diagnostic tools to have to explicitly bind to an LL address. But I don't see that as a justification for having the default rules employ limited-scope addresses when a global address is available. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 12 08:50:47 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5CFolk7016156; Wed, 12 Jun 2002 08:50:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5CFokSp016155; Wed, 12 Jun 2002 08:50:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5CFogk7016148 for ; Wed, 12 Jun 2002 08:50:42 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA23266 for ; Wed, 12 Jun 2002 08:50:45 -0700 (PDT) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA26627 for ; Wed, 12 Jun 2002 09:50:44 -0600 (MDT) Subject: RE: Reviewof"Use of /127 Prefix Length Between Routers Considered Harmful" Date: Wed, 12 Jun 2002 08:50:43 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046405E0F9@server2000.arneill-py.sacramento.ca.us> X-MS-Has-Attach: X-MS-TNEF-Correlator: X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Topic: Reviewof"Use of /127 Prefix Length Between Routers Considered Harmful" Thread-Index: AcIR7GoB4OC6+yspQ+mxGSyB6dxTjgAOpYAA content-class: urn:content-classes:message From: "Michel Py" To: "Alain Durand" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5CFohk7016149 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>> Alain Durand wrote: >>> I still do not understand why this draft does not simply advocate >>> using 2 /128. >> >> There is something that makes me scream at the thought of not having >> both ends in the same subnet and/or not having a route for that subnet. >> Possibly some frame-relay flashback? Anyway, this sounds to me as bad as >> using unnumbered. B.A.D. > This sounds like F.U.D. to me. Why do you think it is B.A.D.? It's a matter of operational practice. Same idea as having a routable loopback interface, for example. There are no addressing architecture requirements that says you need a routable loopback, but lots of people have them anyway. Place this in context: what we are talking about here is either a router-to-router tunnel or a router-to-router link. Guess what: there is likely to be a routing protocol there. Could you explain me how you configure RIP when the other router is not on the same subnet? Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 12 10:12:55 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5CHCtk7016286; Wed, 12 Jun 2002 10:12:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5CHCso5016285; Wed, 12 Jun 2002 10:12:54 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5CHCpk7016278 for ; Wed, 12 Jun 2002 10:12:51 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA29209 for ; Wed, 12 Jun 2002 10:12:55 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA18173 for ; Wed, 12 Jun 2002 11:12:54 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g5CHCdN03593; Wed, 12 Jun 2002 20:12:39 +0300 Date: Wed, 12 Jun 2002 20:12:39 +0300 (EEST) From: Pekka Savola To: Randy Bush cc: Alain Durand , Michel Py , Bob Hinden , Subject: Re: Review of "Use of /127 Prefix Length Between Routers Considered Harmful" 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 Wed, 12 Jun 2002, Randy Bush wrote: > > Of course, 2 /128's could also be used. This seems like an > > elegant solution, but may be operationally more cumbersome with > > some implementations (e.g. requiring to set a static route). As several people have expressed their dislike on this approach I propose either: a) remove the above section altogether (restore what it was), b) replace it with something like: In addition to using a different prefix length, one could use two /128's or avoid using global addresses altogether. Further discussion on the benefits and drawbacks of different solutions is out of the scope, as it is not the goal of this memo to try to find "best" prefix length for everyone. c) suggest your own! -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 12 10:40:31 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5CHeVk7016400; Wed, 12 Jun 2002 10:40:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5CHeVQ8016399; Wed, 12 Jun 2002 10:40:31 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5CHePk7016389 for ; Wed, 12 Jun 2002 10:40:25 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA11856 for ; Wed, 12 Jun 2002 10:40:26 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA17514; Wed, 12 Jun 2002 11:40:25 -0600 (MDT) Received: from localhost ([3ffe:501:100f:1041::6]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g5CHeH895677; Thu, 13 Jun 2002 02:40:17 +0900 (JST) Date: Thu, 13 Jun 2002 02:25:21 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Margaret Wasserman Cc: Erik Nordmark , Keith Moore , Thomas Narten , ipng@sunroof.eng.sun.com Subject: Re: IESG comments on draft-ietf-ipngwg-default-addr-select-06.txt In-Reply-To: <4.2.2.20020612103350.022dca80@mail.windriver.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. References: <4.2.2.20020612103350.022dca80@mail.windriver.com> MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 37 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Wed, 12 Jun 2002 10:38:24 -0400, >>>>> Margaret Wasserman said: >> The proposed text is trying to say that temporary addresses are preferable >> but that there might be issues (such as applications having problems) >> which consistitute a good enough reason to not follow the default. >> Thus there is significant freedom for implementors to use their best >> judgement based on their knowledge about the applications. > Is it optional for a vendor to implement temporary addresses? Is it optional > for a user to configure site-local addresses on a box (or perhaps even for > a vendor to support them)? Good point...I thought in this context we assume vendors implement temporary addresses and users configure temporary addresses by default. Otherwise, the original concern: "The IESG is concerned that if temporary addresses are not enabled by default, they won't see widespread use in practice." would not make sense. If, for example, the premise is implementing and configuring temporary addresses are both optional, I'll be just okay with the proposed change. Users (or administrators) who dare to configure temporary addresses under such an environments should have a strong desire for privacy. So, even if the source address selection prefers public address by default, such users will explicitly (try to) reverse the logic for every communication. This makes the default meaningless, and thus preferring temporary address should make much sense. (though the premise would be meaningless according to the original motivation; widespread use of temporary addresses) 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 Jun 12 10:40:29 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5CHeSk7016397; Wed, 12 Jun 2002 10:40:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5CHeS47016396; Wed, 12 Jun 2002 10:40:28 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5CHeMk7016382 for ; Wed, 12 Jun 2002 10:40:22 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA11825 for ; Wed, 12 Jun 2002 10:40:24 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA04827 for ; Wed, 12 Jun 2002 11:40:23 -0600 (MDT) Received: from localhost ([3ffe:501:100f:1041::6]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g5CHe6895670; Thu, 13 Jun 2002 02:40:08 +0900 (JST) Date: Thu, 13 Jun 2002 02:40:07 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Keith Moore Cc: Erik Nordmark , Thomas Narten , ipng@sunroof.eng.sun.com Subject: Re: IESG comments on draft-ietf-ipngwg-default-addr-select-06.txt In-Reply-To: <200206121251.g5CCp2n20237@astro.cs.utk.edu> References: <200206121251.g5CCp2n20237@astro.cs.utk.edu> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 27 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Wed, 12 Jun 2002 08:51:02 -0400, >>>>> Keith Moore said: >> This rule may be sometimes controversial, but I personally think it is >> reasonable, because we can (in theory) expect better reachability for >> a smaller scope of destinations. This is especially true for a >> link-local destination where we don't need L3 routing. > Rule #2 is not a problem, rule #8 is. The problem is that the address > selected for one connection pair may end up getting reused in other > scope. So if rule 8 results in an LL or SL address being used, there > might be an attempt to reuse that address (perhaps by another application > component) in a different scope. (I'm not sure what "reuse" exactly means here, but) It seems to me that the issue you raised up is how an application treats (i.e. disambiguates) scoped addresses, rather than (destination) address selection. As long as the application may take a particular numeric address as the destination and the address may be a scoped one, the application should deal with the weirdness of scoping. Just preferring global addresses (when available) does not help the application. 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 Jun 12 12:22:58 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5CJMwk7016661; Wed, 12 Jun 2002 12:22:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5CJMvaT016660; Wed, 12 Jun 2002 12:22:57 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5CJMsk7016653 for ; Wed, 12 Jun 2002 12:22:54 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA20415 for ; Wed, 12 Jun 2002 12:22:57 -0700 (PDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA16221 for ; Wed, 12 Jun 2002 13:22:57 -0600 (MDT) Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.194.24]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g5CJMpg5078716; Wed, 12 Jun 2002 15:22:52 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.9.21]) by westrelay03.boulder.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5CJMoX109898; Wed, 12 Jun 2002 13:22:51 -0600 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id g5CJKsH01684; Wed, 12 Jun 2002 15:20:54 -0400 Message-Id: <200206121920.g5CJKsH01684@rotala.raleigh.ibm.com> To: Keith Moore cc: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= , ipng@sunroof.eng.sun.com Subject: Re: IESG comments on draft-ietf-ipngwg-default-addr-select-06.txt In-Reply-To: Message from "Wed, 12 Jun 2002 09:06:37 EDT." <200206121306.g5CD6bn22980@astro.cs.utk.edu> Date: Wed, 12 Jun 2002 15:20:54 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith, > > As for the impacts on the applications' behavior, I don't worry so > > much. I've configured my laptop to prefer temporary addresses over a > > year (for experiences - I'm not a privacy-conscious guy), and I've > > never seen a trouble with the environment. I admit I'm only using a > > limited type of applications (and we cannot be sure about future > > applications), but I believe it covers a certain amount of today's > > major applications, including pop client, smtp client, www client, ftp > > client, ssh client, and DNS resolver. In particular, I don't worry > > about the "relatively short lifetime" through the experience. > I don't think it's reasonable to allow "today's major applications" > to constrain the behavior of all present and future applications. I don't quite follow the logic here. Having the stack, by default, give preference to temporary over public addresses only means that they will be used without applications having explicitely asked for their use. For existing applications, that might cause surprise/problems in some cases. Future applications, on the other hand, still need to be written, and one could argue they will need to make intelligent choices about whether the use of temporary addresses will cause problems, and code accordingly. I doesn't strike me that giving preference to temporary adddress "constrains the behavior of future applications". > I work with p2p and distributed systems every day, and trying to > deal with temporary and scoped addresses really is very difficult > for them. If we are not careful we will end up imposing NAT-like > restrictions in IPv6 even if IPv6 does not have NATs. This would seem to follow only if temporary addresses were the only addresses available. No one seems to be suggesting that and it wouldn't make sense anyway. Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 12 12:34:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5CJYYk7016690; Wed, 12 Jun 2002 12:34:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5CJYYvF016689; Wed, 12 Jun 2002 12:34:34 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5CJXVk7016682 for ; Wed, 12 Jun 2002 12:33:42 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA23751 for ; Wed, 12 Jun 2002 12:33:16 -0700 (PDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA19163 for ; Wed, 12 Jun 2002 13:33:15 -0600 (MDT) Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.194.24]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g5CJXCg5274316; Wed, 12 Jun 2002 15:33:12 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.9.21]) by westrelay03.boulder.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5CJXBX96844; Wed, 12 Jun 2002 13:33:11 -0600 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id g5CJVHS01755; Wed, 12 Jun 2002 15:31:17 -0400 Message-Id: <200206121931.g5CJVHS01755@rotala.raleigh.ibm.com> To: Margaret Wasserman cc: Erik Nordmark , Keith Moore , ipng@sunroof.eng.sun.com Subject: Re: IESG comments on draft-ietf-ipngwg-default-addr-select-06.txt In-Reply-To: Message from "Wed, 12 Jun 2002 10:38:24 EDT." <4.2.2.20020612103350.022dca80@mail.windriver.com> Date: Wed, 12 Jun 2002 15:31:17 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Margaret. > Is it optional for a vendor to implement temporary addresses? That is my understanding, and I'm sure the topic will come up in the context of the general node requirements document. Note that the cellular requirements document we have been working on has wording now that says "should". > Is it optional for a user to configure site-local addresses on a box I'd say yes. There certainly can be no requirement to use them... > (or perhaps even for a vendor to support them)? What does it mean to not implement site-local addresses? Would an implementation reject any packet with a site-local prefix in it? For a host, I think you'd be hard pressed to not support them. For a router, I'd assume one has to implement configuration stuff to enforce boundaries. > One reason that has been put forth for having a fixed set of address > selection rules is that it will be possible for implementations to > know what addresses will be preferred, and override that behaviour > if desired. > I'm not quite sure how this works when it isn't clear that all > vendors will implement all address types (temporary, site-local, > etc.), or that all address types will be configured for a given > system. This particularly becomes problematic when optional address > types (temporary, perhaps site-local) are preferred over required > address types (link-local and global). Addresses can only be preferred if they actually are candidates for use (e.g, were returned by the DNS, are assigned to an interface, etc.) Individual rules aren't used unless they apply to the addresses being considered. So I don't see any immediate problem if a particular address type isn't used or implemented. Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 12 13:16:05 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5CKG5k7016802; Wed, 12 Jun 2002 13:16:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5CKG5Ae016799; Wed, 12 Jun 2002 13:16:05 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5CKFek7016779 for ; Wed, 12 Jun 2002 13:16:00 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA19336 for ; Wed, 12 Jun 2002 13:15:36 -0700 (PDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA25733 for ; Wed, 12 Jun 2002 13:15:36 -0700 (PDT) Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.194.24]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g5CKFXg5119694; Wed, 12 Jun 2002 16:15:33 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.9.21]) by westrelay03.boulder.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5CKFVX125802; Wed, 12 Jun 2002 14:15:32 -0600 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id g5CKDba02101; Wed, 12 Jun 2002 16:13:37 -0400 Message-Id: <200206122013.g5CKDba02101@rotala.raleigh.ibm.com> To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: ipng@sunroof.eng.sun.com Subject: Re: IESG comments on draft-ietf-ipngwg-default-addr-select-06.txt In-Reply-To: Message from "Thu, 13 Jun 2002 02:25:21 +0900." Date: Wed, 12 Jun 2002 16:13:37 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= writes: > Good point...I thought in this context we assume vendors implement > temporary addresses and users configure temporary addresses by > default. Otherwise, the original concern: > "The IESG is concerned that if temporary addresses are not enabled by > default, they won't see widespread use in practice." The logic is roughly as follows. The more barriers that exist w.r.t. the usage of temporary addresses, the less likely we'll see widespread usage. Today, they are optional. It's certainly a barrier that they have to be implemented to be used. :-) But even if they are implemented (say in typical OSes), but not used by default, who will actually use them? We would have to wait for individual appications to enable their use. We seem to have experience in other spaces that getting lots of applications to implement a desired capability can take a very long time... > If, for example, the premise is implementing and configuring temporary > addresses are both optional, I'll be just okay with the proposed > change. Today, implementation is optional. I think the document assumes if you implemente, you want to enable, but can't find exact words on this right off. 3041 does say, howoever: Finally, this document assumes that when a node initiates outgoing communication, temporary addresses can be given preference over public addresses. This can mean that all connections initiated by the node use temporary addresses by default, or that applications individually indicate whether they prefer to use temporary or public addresses. Giving preference to temporary address is consistent with on-going work that addresses the topic of source-address selection in the more general case [ADDR_SELECT]. An implementation may make it a policy that it does not select a public address in the event that no temporary address is available (e.g., if generation of a useable temporary address fails). > Users (or administrators) who dare to configure temporary > addresses under such an environments should have a strong desire for > privacy. So, even if the source address selection prefers public > address by default, such users will explicitly (try to) reverse the > logic for every communication. This makes the default meaningless, > and thus preferring temporary address should make much sense. > (though the premise would be meaningless according to the original > motivation; widespread use of temporary addresses) The default-addr-select document isn't mandating the use of temporary addresses. So what is being requested here is that *if* temporary addresses have been implemented and are being used, *then* give them preference over public addresses. Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 12 13:33:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5CKXmk7016839; Wed, 12 Jun 2002 13:33:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5CKXmdk016838; Wed, 12 Jun 2002 13:33:48 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5CKXik7016831 for ; Wed, 12 Jun 2002 13:33:44 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA16179 for ; Wed, 12 Jun 2002 13:33:48 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA04340 for ; Wed, 12 Jun 2002 14:33:47 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5CKXZn02520; Wed, 12 Jun 2002 16:33:35 -0400 (EDT) Message-Id: <200206122033.g5CKXZn02520@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: Keith Moore , Erik Nordmark , Thomas Narten , ipng@sunroof.eng.sun.com Subject: Re: IESG comments on draft-ietf-ipngwg-default-addr-select-06.txt In-reply-to: (Your message of "Thu, 13 Jun 2002 02:40:07 +0900.") Date: Wed, 12 Jun 2002 16:33:35 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > (I'm not sure what "reuse" exactly means here, but) It seems to me > that the issue you raised up is how an application treats > (i.e. disambiguates) scoped addresses, rather than (destination) > address selection. As long as the application may take a particular > numeric address as the destination and the address may be a scoped > one, the application should deal with the weirdness of scoping. I agree with that statement. But we need to arrange things so that (outside of things like routing protocols, RD/ND, diagnostics etc.) having a SL or LL destination is a rare occurance, so that most apps don't have to deal with them at all. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 12 13:35:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5CKZNk7016869; Wed, 12 Jun 2002 13:35:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5CKZN4x016868; Wed, 12 Jun 2002 13:35:23 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5CKZLk7016861 for ; Wed, 12 Jun 2002 13:35:21 -0700 (PDT) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g5CKZJoR004305 for ; Wed, 12 Jun 2002 13:35:19 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g5CKZI7N004304 for ipng@sunroof.eng.sun.com; Wed, 12 Jun 2002 13:35:18 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5CF9jk7016031 for ; Wed, 12 Jun 2002 08:09:45 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA06233 for ; Wed, 12 Jun 2002 08:09:48 -0700 (PDT) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA25967 for ; Wed, 12 Jun 2002 08:09:47 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.04) id 17I9kp-000CTX-00; Wed, 12 Jun 2002 08:09:47 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: Robert Elz Cc: ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols References: <20020611150526.F31F77B53@berkshire.research.att.com> <19548.1023872742@munnari.OZ.AU> Message-Id: Date: Wed, 12 Jun 2002 08:09:47 -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > That's true. Te question is really should we go ahead and figure > out the answer, or should be just decide that we don't know the answer > today, and consequently, we will delete the mechanism, so even if someone > does work out the answer tomorrow, it is all irrelevant, because there's > no way to use it left in the protocols any more. yes, otherwise we would have a mocha (my favorite flavor) ice cream mechanism with no currently known way to use it to make ice cream. but some day, we might know how, and who knows, this mechanism might be a good way to implement it. see http://xp.c2.com/DoTheSimplestThingThatCouldPossiblyWork.html and http://xp.c2.com/YouArentGonnaNeedIt.html randy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 12 14:06:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5CL6ak7016974; Wed, 12 Jun 2002 14:06:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5CL6aMf016973; Wed, 12 Jun 2002 14:06: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.12.4/8.12.4) with ESMTP id g5CL6Xk7016966 for ; Wed, 12 Jun 2002 14:06:33 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA29144 for ; Wed, 12 Jun 2002 14:06:35 -0700 (PDT) From: rbrabson@us.ibm.com Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA20265 for ; Wed, 12 Jun 2002 15:06:34 -0600 (MDT) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.us.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.12.2/8.12.2) with ESMTP id g5CL6URY033360; Wed, 12 Jun 2002 17:06:30 -0400 Received: from d04nm200.raleigh.ibm.com (d04nm200.raleigh.ibm.com [9.67.226.57]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5CL6T2123354; Wed, 12 Jun 2002 17:06:29 -0400 Subject: Re: IESG comments on draft-ietf-ipngwg-default-addr-select-06.txt To: narten@rotala.raleigh.ibm.com Cc: ipng@sunroof.eng.sun.com, jinmei@isl.rdc.toshiba.co.jp, Keith Moore X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Wed, 12 Jun 2002 17:06:15 -0400 X-MIMETrack: Serialize by Router on D04NM200/04/M/IBM(Build M13TT_05222002 Pre-release 2|May 22, 2002) at 06/12/2002 17:06:29 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=0ABBE145DFE291538f9e8a93df938690918c0ABBE145DFE29153" Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --0__=0ABBE145DFE291538f9e8a93df938690918c0ABBE145DFE29153 Content-type: text/plain; charset=US-ASCII On Wednesday, 06/12/2002 at 03:20 AST, narten@rotala.raleigh.ibm.com wrote: > I don't quite follow the logic here. Having the stack, by default, > give preference to temporary over public addresses only means that > they will be used without applications having explicitely asked for > their use. For existing applications, that might cause > surprise/problems in some cases. Yes, but it is even worse than that. The same application may run perfectly fine on one host, but fail on another, if only some of the hosts support temporary addresses. And when upgrading an OS from a level which doesn't support temporary addresses to one which does, applications may suddenly begin to fail. And there is absolutely nothing a user can do to fix it, short of changing their OS to one which does not support temporary addresses. These are the types of things which drive users, system programmers, and call centers crazy. I know on the product on which I work, we wouldn't even begin to consider making a change like this to our external behavior - our customers simply wouldn't let us get away with it. > Future applications, on the other hand, still need to be written, and > one could argue they will need to make intelligent choices about > whether the use of temporary addresses will cause problems, and code > accordingly. So, how exactly does the application know if temporary addresses will cause problems? Do they need to first try connecting using a temporary address and, if this fails, try to connect using public address? Do they need to support configuration on a per-destination basis so some poor end user can try to configure the application properly when trying to access sites which require public addresses? And will the typical application programmer even know (s)he needs to include such logic when converting their application from AF_INET sockets to AF_INET6 sockets? If we know that applications need code to support temporary addresses in order for them to work properly in certain cases, wouldn't it make sense to have the application indicate it has the necessary support before using them? Roy --0__=0ABBE145DFE291538f9e8a93df938690918c0ABBE145DFE29153 Content-type: text/html; charset=US-ASCII Content-Disposition: inline On Wednesday, 06/12/2002 at 03:20 AST, narten@rotala.raleigh.ibm.com wrote:
> I don't quite follow the logic here. Having the stack, by default,
> give preference to temporary over public addresses only means that
> they will be used without applications having explicitely asked for
> their use. For existing applications, that might cause
> surprise/problems in some cases.

Yes, but it is even worse than that.  The same application may run
perfectly fine on one host, but fail on another, if only some of
the hosts support temporary addresses.  And when upgrading an OS from
a level which doesn't support temporary addresses to one which does,
applications may suddenly begin to fail.  And there is absolutely
nothing a user can do to fix it, short of changing their OS to
one which does not support temporary addresses.  These are the types
of things which drive users, system programmers, and call centers crazy.
I know on the product on which I work, we wouldn't even begin to
consider making a change like this to our external behavior - our
customers simply wouldn't let us get away with it.

> Future applications, on the other hand, still need to be written, and
> one could argue they will need to make intelligent choices about
> whether the use of temporary addresses will cause problems, and code
> accordingly.

So, how exactly does the application know if temporary addresses will
cause problems?  Do they need to first try connecting using a temporary
address and, if this fails, try to connect using public address?  Do
they need to support configuration on a per-destination basis so some
poor end user can try to configure the application properly when trying
to access sites which require public addresses?  And will the typical
application programmer even know (s)he needs to include such logic when
converting their application from AF_INET sockets to AF_INET6 sockets?

If we know that applications need code to support temporary addresses
in order for them to work properly in certain cases, wouldn't it make
sense to have the application indicate it has the necessary support
before using them?

Roy --0__=0ABBE145DFE291538f9e8a93df938690918c0ABBE145DFE29153-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 12 14:09:22 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5CL9Lk7016994; Wed, 12 Jun 2002 14:09:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5CL9LCD016993; Wed, 12 Jun 2002 14:09:21 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5CL9Hk7016986 for ; Wed, 12 Jun 2002 14:09:17 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA11511 for ; Wed, 12 Jun 2002 14:09:19 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA20572 for ; Wed, 12 Jun 2002 14:09:19 -0700 (PDT) Received: from kenawang ([147.11.13.172]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id OAA10664; Wed, 12 Jun 2002 14:07:52 -0700 (PDT) Message-Id: <4.2.2.20020612170451.0220e970@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 12 Jun 2002 17:06:35 -0400 To: Thomas Narten From: Margaret Wasserman Subject: Re: IESG comments on draft-ietf-ipngwg-default-addr-select-06.txt Cc: Erik Nordmark , Keith Moore , ipng@sunroof.eng.sun.com In-Reply-To: <200206121931.g5CJVHS01755@rotala.raleigh.ibm.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > (or perhaps even for a vendor to support them)? > >What does it mean to not implement site-local addresses? Would an >implementation reject any packet with a site-local prefix in it? For a >host, I think you'd be hard pressed to not support them. For a router, >I'd assume one has to implement configuration stuff to enforce >boundaries. For a host, not implementing site-local addresses is approximately equivalent to treating them exactly like global addresses -- what many of us do now. So, never mind :-). >Addresses can only be preferred if they actually are candidates for >use (e.g, were returned by the DNS, are assigned to an interface, >etc.) Individual rules aren't used unless they apply to the addresses >being considered. So I don't see any immediate problem if a particular >address type isn't used or implemented. Makes sense. Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 12 14:15:47 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5CLFlk7017025; Wed, 12 Jun 2002 14:15:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5CLFlJ5017024; Wed, 12 Jun 2002 14:15:47 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5CLFhk7017017 for ; Wed, 12 Jun 2002 14:15:43 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA02367 for ; Wed, 12 Jun 2002 14:15:25 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA06729 for ; Wed, 12 Jun 2002 15:15:24 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5CLFHn02818; Wed, 12 Jun 2002 17:15:17 -0400 (EDT) Message-Id: <200206122115.g5CLFHn02818@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Thomas Narten cc: Keith Moore , JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= , ipng@sunroof.eng.sun.com Subject: Re: IESG comments on draft-ietf-ipngwg-default-addr-select-06.txt In-reply-to: (Your message of "Wed, 12 Jun 2002 15:20:54 EDT.") <200206121920.g5CJKsH01684@rotala.raleigh.ibm.com> Date: Wed, 12 Jun 2002 17:15:17 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > As for the impacts on the applications' behavior, I don't worry so > > > much. I've configured my laptop to prefer temporary addresses over a > > > year (for experiences - I'm not a privacy-conscious guy), and I've > > > never seen a trouble with the environment. I admit I'm only using a > > > limited type of applications (and we cannot be sure about future > > > applications), but I believe it covers a certain amount of today's > > > major applications, including pop client, smtp client, www client, ftp > > > client, ssh client, and DNS resolver. In particular, I don't worry > > > about the "relatively short lifetime" through the experience. > > > I don't think it's reasonable to allow "today's major applications" > > to constrain the behavior of all present and future applications. > > I don't quite follow the logic here. Having the stack, by default, > give preference to temporary over public addresses only means that > they will be used without applications having explicitely asked for > their use. For existing applications, that might cause > surprise/problems in some cases. > > Future applications, on the other hand, still need to be written, and > one could argue they will need to make intelligent choices about > whether the use of temporary addresses will cause problems, and code > accordingly. it still strikes me as the wrong default - it's choosing an option that will cause some apps to fail over one which will not cause those apps to fail. I don't think the privacy issues associated with public addresses are so bad that it's worth the cost of having apps fail mysteriously. and I don't think it's a good idea to have a 'default' that varies from one platform to another either. > I doesn't strike me that giving preference to temporary adddress > "constrains the behavior of future applications". > > > I work with p2p and distributed systems every day, and trying to > > deal with temporary and scoped addresses really is very difficult > > for them. If we are not careful we will end up imposing NAT-like > > restrictions in IPv6 even if IPv6 does not have NATs. > > This would seem to follow only if temporary addresses were the only > addresses available. No one seems to be suggesting that and it > wouldn't make sense anyway. here I'm talking about not just temp addresses but the idea that getting your app to work right might require second-guessing the default address selection mechanisms. i.e. the idea that scoped addresses might be widely used causes us to try to design a heuristic that guesses which address is the right one in each case - one that often prevents the app from working rather than helping it. and encouraging use of scoped addresses might end up imposing restrictions similar to those imposed by NATs. I'm trying to find time to write up an I-D that explains this better. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 12 14:39:26 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5CLdPk7017085; Wed, 12 Jun 2002 14:39:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5CLdPjP017084; Wed, 12 Jun 2002 14:39:25 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5CLdMk7017077 for ; Wed, 12 Jun 2002 14:39:22 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA28210 for ; Wed, 12 Jun 2002 14:39:24 -0700 (PDT) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA17614 for ; Wed, 12 Jun 2002 15:39:23 -0600 (MDT) Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols Date: Wed, 12 Jun 2002 14:39:21 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046405E100@server2000.arneill-py.sacramento.ca.us> X-MS-Has-Attach: X-MS-TNEF-Correlator: X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Topic: Fwd: IPv6 Scoped Addresses and Routing Protocols Thread-Index: AcIR8d+oTXSrOVhhQ8ub4chm9X9mNAAZznEg content-class: urn:content-classes:message From: "Michel Py" To: "Robert Elz" , "Steven M. Bellovin" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5CLdMk7017078 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > kre wrote: > There is way too much of the latter in all areas of the IETF these > days. I don't know the answer to this today, so I will forbid it > forever. Yep. I will write a requirements draft that is impossible to meet so it will be forbidden for ever. > SL addresses are just fine. More work is needed on them for sure, > to make them even more useful, and suggesting to people that until > the implementations better support them, they should consider very > carefully before enabling the things, is all just fine. But > there's no reason at all to be even considering deleting them. I agree. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 12 14:56:29 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5CLuTk7017113; Wed, 12 Jun 2002 14:56:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5CLuTIS017112; Wed, 12 Jun 2002 14:56:29 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5CLuPk7017105 for ; Wed, 12 Jun 2002 14:56:25 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA01867 for ; Wed, 12 Jun 2002 14:56:27 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA19028 for ; Wed, 12 Jun 2002 14:56:27 -0700 (PDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5CLuMn03457; Wed, 12 Jun 2002 17:56:22 -0400 (EDT) Message-Id: <200206122156.g5CLuMn03457@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Thomas Narten cc: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= , ipng@sunroof.eng.sun.com Subject: Re: IESG comments on draft-ietf-ipngwg-default-addr-select-06.txt In-reply-to: (Your message of "Wed, 12 Jun 2002 16:13:37 EDT.") <200206122013.g5CKDba02101@rotala.raleigh.ibm.com> Date: Wed, 12 Jun 2002 17:56:22 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The default-addr-select document isn't mandating the use of temporary > addresses. So what is being requested here is that *if* temporary > addresses have been implemented and are being used, *then* give them > preference over public addresses. and I think it would be better to say - allow apps that only need temporary addresses to request them. - if they're not supported, no harm has been done - the app can make do with public addresses. rather than placing the burden on apps to explicitly request public addresses and changing the present behavior. address selection is just the wrong place to encourage use of temp addresses - the address selection code doesn't know the app's needs and can't reliably guess them from the information at hand. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 12 19:24:05 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5D2O5k7017696; Wed, 12 Jun 2002 19:24:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5D2O4PN017695; Wed, 12 Jun 2002 19:24:04 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5D2O0k7017688 for ; Wed, 12 Jun 2002 19:24:00 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA17647 for ; Wed, 12 Jun 2002 19:24:04 -0700 (PDT) From: Internet-Drafts@ietf.org Received: from mail7.nc.rr.com (mail7.southeast.rr.com [24.93.67.54]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA26569 for ; Wed, 12 Jun 2002 19:24:03 -0700 (PDT) Received: from mail pickup service by mail7.nc.rr.com with Microsoft SMTPSVC; Wed, 12 Jun 2002 22:23:42 -0400 Received: from ncmx01.mgw.rr.com ([24.93.67.251]) by mail7.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Tue, 11 Jun 2002 08:24:37 -0400 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ncmx01.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5BB9d3o022538 for ; Tue, 11 Jun 2002 07:09:40 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA29420; Tue, 11 Jun 2002 05:09:16 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA18514; Tue, 11 Jun 2002 04:09:11 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BB6Tk7009792; Tue, 11 Jun 2002 04:06:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5BB6TNo009791; Tue, 11 Jun 2002 04:06:29 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BB6Pk7009784 for ; Tue, 11 Jun 2002 04:06:25 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA06688 for ; Tue, 11 Jun 2002 04:06:27 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA19229 for ; Tue, 11 Jun 2002 04:06:26 -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 HAA17778; Tue, 11 Jun 2002 07:05:51 -0400 (EDT) Message-Id: <200206111105.HAA17778@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-router-selection-02.txt Date: Tue, 11 Jun 2002 07:05:50 -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 IP Version 6 Working Group Working Group of the IETF. Title : Default Router Preferences, More-Specific Routes and Load Sharing Author(s) : R. Draves, B. Hinden Filename : draft-ietf-ipv6-router-selection-02.txt Pages : 13 Date : 10-Jun-02 This document describes two changes to Neighbor Discovery. The first change is an optional extension to Router Advertisement messages for communicating default router preferences and more-specific routes from routers to hosts. This improves the ability of hosts to pick an appropriate router, especially when the host is multi-homed and the routers are on different links. The preference values and specific routes advertised to hosts require administrative configuration; they are not automatically derived from routing tables. The second change is a mandatory modification of the conceptual sending algorithm to support load-sharing among equivalent routers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-router-selection-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipv6-router-selection-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-ipv6-router-selection-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: <20020610143015.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-router-selection-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-router-selection-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020610143015.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 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 12 21:26:20 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5D4QKk7018361; Wed, 12 Jun 2002 21:26:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5D4QJis018360; Wed, 12 Jun 2002 21:26:19 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5D4QGk7018353 for ; Wed, 12 Jun 2002 21:26:16 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA25121 for ; Wed, 12 Jun 2002 21:26:19 -0700 (PDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA01340 for ; Wed, 12 Jun 2002 21:26:14 -0700 (PDT) Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 12 Jun 2002 21:26:13 -0700 Received: from 157.54.6.150 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 12 Jun 2002 21:26:13 -0700 Received: from red-msg-06.redmond.corp.microsoft.com ([157.54.12.71]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 12 Jun 2002 21:26:13 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: I-D ACTION:draft-ietf-ipv6-router-selection-02.txt Date: Wed, 12 Jun 2002 21:26:12 -0700 Message-ID: <7695E2F6903F7A41961F8CF888D87EA804BC4D70@red-msg-06.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-ietf-ipv6-router-selection-02.txt Thread-Index: AcIR/t4wwlx3PO9nR424WxV5Kxs4TgAkm64Q From: "Richard Draves" To: "Pekka Savola" Cc: X-OriginalArrivalTime: 13 Jun 2002 04:26:13.0310 (UTC) FILETIME=[738F6DE0:01C21292] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5D4QGk7018354 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > 3.4. Router Reachability Probing > > When a host avoids using a non-reachable router X and instead uses > another router Y, and the host would have used router X if router X > were reachable, then the host SHOULD probe router X's reachability > by sending a Neighbor Solicitation. A host MUST NOT probe > a router's > reachability in the absence of useful traffic that the host would > have sent to the router if it were reachable. [...] > > ==> I think 'MUST NOT' there is very strict wording. Is it really > necessary to be so? Would SHOULD NOT be sufficient? Perhaps. I added this in response to the feedback at Minneapolis, where it was clear the earlier wording was misunderstood to mean that probing would happen in the absence of useful traffic; perhaps I over-reacted. Any other opinions on MUST NOT vs SHOULD NOT here? > When a host chooses from multiple equivalent routers, it > MUST choose > randomly. > > ==> Did we settle this SHOULD/MUST debate? I'm not sure if > MUST is best, > but I can deal with that. I would be OK with SHOULD here, but I believe my newly added co-author prefers MUST. > > Routers SHOULD NOT include in a Router Advertisement two Route > Information Options with the same Prefix and Prefix Length > > ==> > s/in a Router Advertisement two Route Information Options/ > two Route Information Options in a Router Advertisement/ ? Then "with the same Prefix and Prefix Length" would be misplaced modifier, no? 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 Jun 12 21:33:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5D4XXk7018390; Wed, 12 Jun 2002 21:33:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5D4XXqk018389; Wed, 12 Jun 2002 21:33:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5D4XTk7018382 for ; Wed, 12 Jun 2002 21:33:30 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA28091 for ; Wed, 12 Jun 2002 21:33:16 -0700 (PDT) Received: from mail7.nc.rr.com (fe7.southeast.rr.com [24.93.67.54]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA20254 for ; Wed, 12 Jun 2002 22:34:55 -0600 (MDT) Received: from mail pickup service by mail7.nc.rr.com with Microsoft SMTPSVC; Wed, 12 Jun 2002 23:33:10 -0400 Received: from ncmx02.mgw.rr.com ([24.93.67.222]) by mail7.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Tue, 11 Jun 2002 07:02:20 -0400 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ncmx02.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5B9D3od000820 for ; Tue, 11 Jun 2002 05:13:04 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA04579; Tue, 11 Jun 2002 02:12:12 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA13321; Tue, 11 Jun 2002 02:12:06 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5B9Aak7009662; Tue, 11 Jun 2002 02:10:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5B9AZSm009661; Tue, 11 Jun 2002 02:10:35 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5B9AWk7009654 for ; Tue, 11 Jun 2002 02:10:32 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA28324 for ; Tue, 11 Jun 2002 02:10:36 -0700 (PDT) Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.211]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA04764 for ; Tue, 11 Jun 2002 03:12:13 -0600 (MDT) Received: from tarski.cs.uni-bonn.de (tarski.cs.uni-bonn.de [131.220.4.200]) by theory.cs.uni-bonn.de (8.9.1a/8.9.1) with ESMTP id LAA23701 for ; Tue, 11 Jun 2002 11:10:34 +0200 (MET DST) Received: (from ignatios@localhost) by tarski.cs.uni-bonn.de (8.9.1a/8.9.1) id LAA21615 for ipng@sunroof.eng.sun.com; Tue, 11 Jun 2002 11:09:57 +0200 (CEST) Date: Tue, 11 Jun 2002 11:09:57 +0200 From: Ignatios Souvatzis Cc: ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols Message-ID: <20020611110957.A21584@tarski.cs.uni-bonn.de> References: <20020610105501.E17133@tarski.cs.uni-bonn.de> <200206101745.g5AHjHZs022737@thunk.east.sun.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="7JfCtLOvnd9MIVvH" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200206101745.g5AHjHZs022737@thunk.east.sun.com>; from sommerfeld@east.sun.com on Mon, Jun 10, 2002 at 01:45:16PM -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --7JfCtLOvnd9MIVvH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jun 10, 2002 at 01:45:16PM -0400, Bill Sommerfeld wrote: > It's also worth pointing out that NAT is not the only way a > site-local-only system could get external connectivity. >=20 > A transport-layer gateway/relay like a socks implementation for v6 or > the KAME "faithd" would be another way.. faithd does NAT while changing the address family at the same time, doesn't= =20 it? -is --7JfCtLOvnd9MIVvH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: 2.6.i iQEVAgUBPQW+YjCn4om+4LhpAQEG3gf/ViZNSBjS8ToRc27/LkFb+D9WYX12+vjg fnH7ljXHKvIN4KXqzKRhacV55jFu3xi1KxkpH1+chuQqwH3il4vM6kCATgjfpxqn 290heb9X0tm8FceDRmZphvnKuLYxrnhs+oDDiQi2MZH+KQKItX+gZ/MA6Mru3G2H E3A51L3LXvcS1uhya1RAgNv/vwVQhyHGnOcp4xgmFpND2Cy/ffjtXhlxb7ecuB1/ YWTyvHCM9AgoLgu7L/rZFA4l5K67ElDRbwOg9SLmZcCW2sBjcjwoqyezT4E1OWmE QL/fenfx5ae4Knwf/h7VMvN7bTtskxQcU9jACEF/jeU9IqwlPB+xyw== =+5GR -----END PGP SIGNATURE----- --7JfCtLOvnd9MIVvH-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Jun 12 22:11:57 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5D5Bvk7019016; Wed, 12 Jun 2002 22:11:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5D5Bvo7019015; Wed, 12 Jun 2002 22:11:57 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5D5Brk7019008 for ; Wed, 12 Jun 2002 22:11:53 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA08863 for ; Wed, 12 Jun 2002 22:11:56 -0700 (PDT) Received: from starfruit.itojun.org (dialup0.itojun.org [210.160.95.108]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA08290 for ; Wed, 12 Jun 2002 23:11:51 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id E9D027C4; Thu, 13 Jun 2002 13:04:57 +0900 (JST) To: Robert Elz Cc: ipng@sunroof.eng.sun.com In-reply-to: kre's message of Wed, 12 Jun 2002 17:57:41 +0700. <19942.1023879461@munnari.OZ.AU> 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: Review of"Use of /127 Prefix Length Between Routers Considered Harmful" From: Jun-ichiro itojun Hagino Date: Thu, 13 Jun 2002 13:04:57 +0900 Message-Id: <20020613040457.E9D027C4@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >That's true: I know of one - munnari.oz.au has a P2P link for IPv6, >and that's its only IPv6 connectivity. Assuming that it is to have >a global v6 address (and it does) it has to be assigned to the P2P >link, there is nothing else to assign it to (it isn't a router, just >a host, and the p2p link is a tunnel, of course, not that that matters). > >Given that, the question is how the global address space should be >used on P2P links when addresses are required, surely? The question >of what to do when they're not required (and not wanted either) is >not relevant, is it? i usually use /64 for p2p link. it works just fine, it supports temporary address (RFC3041) if you desire, i can think of no reason to use somethiing other than /64. 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 Jun 12 22:33:38 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5D5Xbk7019063; Wed, 12 Jun 2002 22:33:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5D5Xb2v019062; Wed, 12 Jun 2002 22:33:37 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5D5XYk7019055 for ; Wed, 12 Jun 2002 22:33:34 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA12760 for ; Wed, 12 Jun 2002 22:33:37 -0700 (PDT) Received: from mail7.nc.rr.com (fe7.southeast.rr.com [24.93.67.54]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA24925 for ; Wed, 12 Jun 2002 23:33:35 -0600 (MDT) Received: from mail pickup service by mail7.nc.rr.com with Microsoft SMTPSVC; Thu, 13 Jun 2002 00:07:44 -0400 Received: from ncmx01.mgw.rr.com ([24.93.67.251]) by mail7.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Mon, 10 Jun 2002 14:56:34 -0400 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ncmx01.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5AIuXtH007602 for ; Mon, 10 Jun 2002 14:56:33 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA07295; Mon, 10 Jun 2002 11:55:36 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA07062; Mon, 10 Jun 2002 11:55:30 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5AIrYk7008046; Mon, 10 Jun 2002 11:53:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5AIrXha008045; Mon, 10 Jun 2002 11:53:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5AIrUk7008038 for ; Mon, 10 Jun 2002 11:53:30 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA27713 for ; Mon, 10 Jun 2002 11:53:34 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA21056 for ; Mon, 10 Jun 2002 12:53:33 -0600 (MDT) Message-ID: <002f01c210af$df9ec240$246015ac@T23KEMPF> From: "James Kempf" To: "Steven M. Bellovin" Cc: "Jari Arkko" , "Pekka Savola" , References: <20020609141117.0B9717B4B@berkshire.research.att.com> Subject: Re: Securing Neighbor Discovery BOF Date: Mon, 10 Jun 2002 11:51:43 -0700 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 Hi Steve, > >Key distribution could be done via Layer 2 AAA or using the roaming > >consortia idea we had in the ABK draft. However, I think that might > >require some change in IPsec policy, because I believe the policy only > >allows IKE or manual keying for key distribution. > > That's not correct. In fact, there's another working group, KINK, > whose goal is Kerberos key management for IPsec. > Thanx for the correction. So is it the case then that there would be no change in IPsec policy required for doing AAA-based or roaming consortia-based key management? Is so, then perhaps this problem is fairly straightforward to solve. jak -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Jun 12 22:56:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5D5uXk7019443; Wed, 12 Jun 2002 22:56:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5D5uX89019442; Wed, 12 Jun 2002 22:56:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5D5uUk7019435 for ; Wed, 12 Jun 2002 22:56:30 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA16190 for ; Wed, 12 Jun 2002 22:56:33 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA27942 for ; Wed, 12 Jun 2002 22:56:32 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g5D5uOA09597; Thu, 13 Jun 2002 08:56:24 +0300 Date: Thu, 13 Jun 2002 08:56:23 +0300 (EEST) From: Pekka Savola To: Thomas Narten cc: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= , Subject: Re: IESG comments on draft-ietf-ipngwg-default-addr-select-06.txt In-Reply-To: <200206122013.g5CKDba02101@rotala.raleigh.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 12 Jun 2002, Thomas Narten wrote: [...] > The default-addr-select document isn't mandating the use of temporary > addresses. So what is being requested here is that *if* temporary > addresses have been implemented and are being used, *then* give them > preference over public addresses. This seems strong statement, if it is put in short terms like here. >From my perspective, it is OK to prefer temporary addresses _but only if_ using them isn't enabled by default. (I think it should be easy to take temporary addresses to use if the user wishes so .. but never arbitrarily.) -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 13 02:14:42 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5D9Efk7019774; Thu, 13 Jun 2002 02:14:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5D9Efk6019773; Thu, 13 Jun 2002 02:14:41 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5D9Eck7019766 for ; Thu, 13 Jun 2002 02:14:38 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA00676 for ; Thu, 13 Jun 2002 02:14:42 -0700 (PDT) Received: from mail7.nc.rr.com (fe7.southeast.rr.com [24.93.67.54]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA07992 for ; Thu, 13 Jun 2002 03:14:42 -0600 (MDT) Received: from mail pickup service by mail7.nc.rr.com with Microsoft SMTPSVC; Thu, 13 Jun 2002 04:23:55 -0400 Received: from ncmx01.mgw.rr.com ([24.93.67.251]) by mail7.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Mon, 10 Jun 2002 16:29:41 -0400 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ncmx01.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5AKTftH005719 for ; Mon, 10 Jun 2002 16:29:41 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA15809; Mon, 10 Jun 2002 14:29:08 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA07104; Mon, 10 Jun 2002 13:28:58 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5AKQvk7008304; Mon, 10 Jun 2002 13:26:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5AKQv5q008303; Mon, 10 Jun 2002 13:26:57 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5AKQrk7008296 for ; Mon, 10 Jun 2002 13:26:53 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA02135 for ; Mon, 10 Jun 2002 13:26:57 -0700 (PDT) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA10894 for ; Mon, 10 Jun 2002 14:28:31 -0600 (MDT) Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 10 Jun 2002 13:26:56 -0700 Received: from 157.54.5.25 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 10 Jun 2002 13:26:55 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 10 Jun 2002 13:26:55 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 10 Jun 2002 13:26:55 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3590.0); Mon, 10 Jun 2002 13:26:21 -0700 Content-Class: urn:content-classes:message Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 10 Jun 2002 13:27:01 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6236.0 Message-ID: <2E33960095B58E40A4D3345AB9F65EC1047CF1F4@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Fwd: IPv6 Scoped Addresses and Routing Protocols thread-index: AcIQufTvq4+1Mp0ZQfuODqHerZ/feAAAm+hg From: "Dave Thaler" To: "Bill Fenner" Cc: X-OriginalArrivalTime: 10 Jun 2002 20:26:21.0557 (UTC) FILETIME=[15831250:01C210BD] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5AKQsk7008297 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > -----Original Message----- > From: Bill Fenner [mailto:fenner@research.att.com] [...] > It's fairly clear how to allow A and F to not advertise site-local > addresses across the boundary (at least, as long as it coincides with a > routing protocol boundary, e.g. OSPF area). However, if H1 knows that > H2 is witchin the same site, H1 is allowed to use its site-local source > address to send to H2's global address. However, along the H1-A-D-F-H2 > path, A would have to drop the packet because it has a site-local address > and is trying to cross a site boundary. Yes, scopes have to be convex. This is not new in IPv6. See section 7 of the IPv4 scoped multicast RFC (2365). -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 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 13 02:57:10 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5D9v9k7020917; Thu, 13 Jun 2002 02:57:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5D9v9US020916; Thu, 13 Jun 2002 02:57:09 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5D9v6k7020909 for ; Thu, 13 Jun 2002 02:57:06 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA04980 for ; Thu, 13 Jun 2002 02:57:11 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.96.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA13707 for ; Thu, 13 Jun 2002 03:58:50 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g5D9uCM06402; Thu, 13 Jun 2002 16:56:13 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g5D9rfs23438; Thu, 13 Jun 2002 16:53:43 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Jun-ichiro itojun Hagino cc: ipng@sunroof.eng.sun.com Subject: Re: Review of"Use of /127 Prefix Length Between Routers Considered Harmful" In-Reply-To: <20020613040457.E9D027C4@starfruit.itojun.org> References: <20020613040457.E9D027C4@starfruit.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 13 Jun 2002 16:53:41 +0700 Message-ID: <23436.1023962021@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 13 Jun 2002 13:04:57 +0900 From: Jun-ichiro itojun Hagino Message-ID: <20020613040457.E9D027C4@starfruit.itojun.org> | i usually use /64 for p2p link. it works just fine, it supports | temporary address (RFC3041) if you desire, Yes, no argument with any of that. As I recall, using /64 is one of the alternatives (to using /127 which this draft was written to discourage I believe) that is given. Of course, on a P2P link, any prefix length (< about 126) will support temporary addresses, the only difference is how many of them exist to choose between (which can't be detected from outside, which makes the problem of having a smaller set fairly irrelevant). That is, there's only one other node with which to possibly clash, and that one usually has no motivation to use temporary addresses on the P2P link. | i can think of no reason to use somethiing other than /64. The obvious one is to conserve address space. Another is to make it easier to see what are p2p links from their addresses (all of an organisation's p2p links can easily be numbered out of one /64). In any case, unless there's something that will be broken by using a longer prefix, there's no reason to forbid it, is there? 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 Jun 13 03:06:20 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DA6Kk7020957; Thu, 13 Jun 2002 03:06:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5DA6Kii020956; Thu, 13 Jun 2002 03:06:20 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DA6Hk7020949 for ; Thu, 13 Jun 2002 03:06:17 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA06909 for ; Thu, 13 Jun 2002 03:06:19 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.96.5]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA28426 for ; Thu, 13 Jun 2002 04:06:17 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g5DA5TM13274; Thu, 13 Jun 2002 17:05:29 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g5DA2ws23458; Thu, 13 Jun 2002 17:02:59 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Thomas Narten cc: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= , ipng@sunroof.eng.sun.com Subject: Re: IESG comments on draft-ietf-ipngwg-default-addr-select-06.txt In-Reply-To: <200206122013.g5CKDba02101@rotala.raleigh.ibm.com> References: <200206122013.g5CKDba02101@rotala.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 13 Jun 2002 17:02:58 +0700 Message-ID: <23456.1023962578@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 12 Jun 2002 16:13:37 -0400 From: Thomas Narten Message-ID: <200206122013.g5CKDba02101@rotala.raleigh.ibm.com> | The default-addr-select document isn't mandating the use of temporary | addresses. So what is being requested here is that *if* temporary | addresses have been implemented and are being used, *then* give them | preference over public addresses. When and why did we switch from allowing this kind of address (and specifying how to make it work) - which is all just fine for those people who desire to use them, into evangelism for their use ? In any case, surely which should be preferred needs to be a config option for the host (perhaps even for the application) which I believe the draft explicitly allows for. What we're really discussing here is what should be done when the user of the host doesn't care - and for that I see no reason at all that temporary addresses should be preferred over more stable ones. Of course, in the model we have at the minute, all addresses really are temporary - the only issue is with just how temporary they're expected to be. And to Keith - yes, apps need to get a lot smarter (or perhaps a lot dumber) about their use of addresses. That's true now with IPv4 - we've been using temporary use addresses ever since we started using dhcp for address assignment. Addresses come with a lease length, after which they might be renewed, or might not be. Applications, and application protocols simply need to deal with that. Currently we're surviving largely by blind luck - that is, the applications that most people use need an address to be valid for (at least) an order of magnitude less time than typical address validity (perhaps commonly 2 orders). So, applications are just ignoring the issue completely. To be correct, they shouldn't. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 13 03:41:01 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DAf1k7021040; Thu, 13 Jun 2002 03:41:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5DAf14E021039; Thu, 13 Jun 2002 03:41:01 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DAeuk7021032 for ; Thu, 13 Jun 2002 03:40:57 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA13896 for ; Thu, 13 Jun 2002 03:41:00 -0700 (PDT) Received: from mail5.nc.rr.com (fe5.southeast.rr.com [24.93.67.52]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA29664 for ; Thu, 13 Jun 2002 04:41:00 -0600 (MDT) Received: from mail pickup service by mail5.nc.rr.com with Microsoft SMTPSVC; Thu, 13 Jun 2002 06:38:53 -0400 Received: from mail pickup service by mail5.nc.rr.com with Microsoft SMTPSVC; Tue, 11 Jun 2002 15:34:54 -0400 Received: from ncmx01.mgw.rr.com ([24.93.67.251]) by mail5.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Mon, 10 Jun 2002 18:45:26 -0400 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ncmx01.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5ALketH016590 for ; Mon, 10 Jun 2002 17:46:40 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA24708; Mon, 10 Jun 2002 15:47:13 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA05736; Mon, 10 Jun 2002 14:45:28 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5ALhDk7008563; Mon, 10 Jun 2002 14:43:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5ALhC4f008562; Mon, 10 Jun 2002 14:43:12 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5ALh8k7008555 for ; Mon, 10 Jun 2002 14:43:09 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA04771 for ; Mon, 10 Jun 2002 14:43:11 -0700 (PDT) Received: from esunmail ([129.147.58.122]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA23111 for ; Mon, 10 Jun 2002 15:44:47 -0600 (MDT) Received: from xpa-fe2 (esunmail-ge0 [129.147.58.121]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 0.3 (built May 13 2002)) with ESMTP id <0GXI00EFMEZX4B@edgemail1.Central.Sun.COM> for ipng@sunroof.eng.sun.com; Mon, 10 Jun 2002 15:43:10 -0600 (MDT) Received: from localhost ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 0.2 (built Apr 26 2002)) with ESMTPSA id <0GXI00AYOEZW4R@mail.sun.net> for ipng@sunroof.eng.sun.com; Mon, 10 Jun 2002 15:43:09 -0600 (MDT) Date: Mon, 10 Jun 2002 14:43:08 -0700 From: Alain Durand Subject: Re: IPv6 Scoped Addresses and Routing Protocols In-reply-to: To: ipng@sunroof.eng.sun.com Message-id: <0D87F839-7CBB-11D6-AC39-00039376A6AA@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.482) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sunday, June 9, 2002, at 12:11 PM, Tony Hain wrote: > I think most of this thread is focused on what are simply implementation > details, not an issue for the standards per se. The biggest issue I saw > was related to DNS returning SL or not, and this is not an issue as long > as the DNS server is not expected to deal with multiple sites. An issue that is overlooked in this discussion is reverse path DNS lookup for site local addresses. Today, with IPv4+NAT on my home network, I simply point my stub-resolvers to my ISP DNS resolver. It's simple, and works fine, at least until I try to do reverse DNS lookup for my internal addresses. Then it just fails. Some applications that I run on my local LAN don't work well or wait forever for timeouts, because they can not resolve 1.1.168 .192.in-addr.arpa. If I had enough IPv4 address space, I could get my ISP to populate the DNS reverse maps, and my problem would be solved. I would expect that IPv6 will help me here by giving me a global prefix (although I agree that getting my ISP to populate a v6 reverse map is somehow more complex than in IPv4), but if, according to the address selection rules, my system will prefer site local addresses for internal communication, amd I'll back to square 1. - Alain. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 13 03:43:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DAhnk7021432; Thu, 13 Jun 2002 03:43:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5DAhmuG021430; Thu, 13 Jun 2002 03:43:48 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DAhhk7021414 for ; Thu, 13 Jun 2002 03:43:43 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA15875 for ; Thu, 13 Jun 2002 03:43:47 -0700 (PDT) Received: from mail5.nc.rr.com (fe5.southeast.rr.com [24.93.67.52]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA27990 for ; Thu, 13 Jun 2002 03:43:46 -0700 (PDT) Received: from mail pickup service by mail5.nc.rr.com with Microsoft SMTPSVC; Thu, 13 Jun 2002 06:39:54 -0400 Received: from mail pickup service by mail5.nc.rr.com with Microsoft SMTPSVC; Tue, 11 Jun 2002 15:35:39 -0400 Received: from flmx01.mgw.rr.com ([65.32.1.38]) by mail5.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Mon, 10 Jun 2002 15:04:34 -0400 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by flmx01.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5AJ4VUa027701 for ; Mon, 10 Jun 2002 15:04:35 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA11744; Mon, 10 Jun 2002 12:03:23 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA01171; Mon, 10 Jun 2002 12:03:20 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5AJ1nk7008071; Mon, 10 Jun 2002 12:01:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5AJ1nJ8008070; Mon, 10 Jun 2002 12:01:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5AJ1jk7008063 for ; Mon, 10 Jun 2002 12:01:45 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA00304 for ; Mon, 10 Jun 2002 12:01:49 -0700 (PDT) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA10852 for ; Mon, 10 Jun 2002 12:01:48 -0700 (PDT) Received: from postal.research.att.com (postal.research.att.com [135.207.23.30]) by mail-blue.research.att.com (Postfix) with ESMTP id 115CE4CE23; Mon, 10 Jun 2002 15:01:44 -0400 (EDT) Received: from berkshire.research.att.com (postal.research.att.com [135.207.23.30]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id OAA21719; Mon, 10 Jun 2002 14:56:26 -0400 (EDT) Received: from research.att.com (localhost [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id 4B4C17B4B; Mon, 10 Jun 2002 15:01:43 -0400 (EDT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: "Steven M. Bellovin" To: "James Kempf" Cc: "Jari Arkko" , "Pekka Savola" , ipng@sunroof.eng.sun.com Subject: Re: Securing Neighbor Discovery BOF Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 10 Jun 2002 15:01:43 -0400 Message-Id: <20020610190143.4B4C17B4B@berkshire.research.att.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <002f01c210af$df9ec240$246015ac@T23KEMPF>, "James Kempf" writes: >Hi Steve, > >> >Key distribution could be done via Layer 2 AAA or using the roaming >> >consortia idea we had in the ABK draft. However, I think that might >> >require some change in IPsec policy, because I believe the policy >only >> >allows IKE or manual keying for key distribution. >> >> That's not correct. In fact, there's another working group, KINK, >> whose goal is Kerberos key management for IPsec. >> > >Thanx for the correction. > >So is it the case then that there would be no change in IPsec policy >required for doing AAA-based or roaming consortia-based key management? >Is so, then perhaps this problem is fairly straightforward to solve. Well, as straight-forward as any key management issue... But the word "policy" is important; there's a lot more to setting up an IPsec than key exchange. Deciding exactly what to encrypt and how has to be negotiated, imposed, or otherwise agreed-upon. --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com ("Firewalls" book) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Jun 13 03:58:13 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DAwDk7022465; Thu, 13 Jun 2002 03:58:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5DAwD95022464; Thu, 13 Jun 2002 03:58:13 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DAw9k7022456; Thu, 13 Jun 2002 03:58:09 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA17567; Thu, 13 Jun 2002 03:58:13 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA20613; Thu, 13 Jun 2002 04:58:12 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g5DAwBU12387; Thu, 13 Jun 2002 13:58:11 +0300 Date: Thu, 13 Jun 2002 13:58:10 +0300 (EEST) From: Pekka Savola To: ipng@sunroof.eng.sun.com cc: ipng-owner@sunroof.eng.sun.com Subject: List loop. [Re: Securing Neighbor Discovery BOF] In-Reply-To: <20020610190143.4B4C17B4B@berkshire.research.att.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, There appears to be something/someone looping messages back to the list. I've received multiple copies of several mails, many of them with a double mailing-list advertisement below. On Mon, 10 Jun 2002, Steven M. Bellovin wrote: > In message <002f01c210af$df9ec240$246015ac@T23KEMPF>, "James Kempf" writes: > >Hi Steve, > > > >> >Key distribution could be done via Layer 2 AAA or using the roaming > >> >consortia idea we had in the ABK draft. However, I think that might > >> >require some change in IPsec policy, because I believe the policy > >only > >> >allows IKE or manual keying for key distribution. > >> > >> That's not correct. In fact, there's another working group, KINK, > >> whose goal is Kerberos key management for IPsec. > >> > > > >Thanx for the correction. > > > >So is it the case then that there would be no change in IPsec policy > >required for doing AAA-based or roaming consortia-based key management? > >Is so, then perhaps this problem is fairly straightforward to solve. > > Well, as straight-forward as any key management issue... > > But the word "policy" is important; there's a lot more to setting up an > IPsec than key exchange. Deciding exactly what to encrypt and how has > to be negotiated, imposed, or otherwise agreed-upon. > > --Steve Bellovin, http://www.research.att.com/~smb (me) > http://www.wilyhacker.com ("Firewalls" book) > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 13 04:16:26 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DBGPk7022525; Thu, 13 Jun 2002 04:16:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5DBGPSB022524; Thu, 13 Jun 2002 04:16:25 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DBGLk7022517 for ; Thu, 13 Jun 2002 04:16:21 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA21093 for ; Thu, 13 Jun 2002 04:16:25 -0700 (PDT) Received: from mail5.nc.rr.com (fe5.southeast.rr.com [24.93.67.52]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA27501 for ; Thu, 13 Jun 2002 04:16:24 -0700 (PDT) Received: from mail pickup service by mail5.nc.rr.com with Microsoft SMTPSVC; Thu, 13 Jun 2002 07:15:10 -0400 Received: from ncmx01.mgw.rr.com ([24.93.67.251]) by mail5.nc.rr.com with Microsoft SMTPSVC(5.5.1877.687.68); Wed, 12 Jun 2002 08:54:01 -0400 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ncmx01.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5CCs0bC010385 for ; Wed, 12 Jun 2002 08:54:01 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA19374; Wed, 12 Jun 2002 06:54:46 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA24343; Wed, 12 Jun 2002 05:52:59 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5CCpIk7013850; Wed, 12 Jun 2002 05:51:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5CCpHtM013849; Wed, 12 Jun 2002 05:51:17 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5CCpDk7013842 for ; Wed, 12 Jun 2002 05:51:14 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA04532 for ; Wed, 12 Jun 2002 05:51:17 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA20864 for ; Wed, 12 Jun 2002 06:51:16 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5CCp2n20237; Wed, 12 Jun 2002 08:51:02 -0400 (EDT) Message-Id: <200206121251.g5CCp2n20237@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: Keith Moore , Erik Nordmark , Thomas Narten , ipng@sunroof.eng.sun.com Subject: Re: IESG comments on draft-ietf-ipngwg-default-addr-select-06.txt In-reply-to: (Your message of "Wed, 12 Jun 2002 21:40:50 +0900.") Date: Wed, 12 Jun 2002 08:51:02 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >> I've got some other problems with the document also - specifically > >> the idea that link-local addresses are preferable to global addresses. > > > Please let me confirm: are you referring to Rule 2 of source address > > selection? > > Perhaps you are talking about Rule 8 of destination address selection: > > Rule 8: Prefer smaller scope. > If Scope(DA) < Scope(DB), then prefer DA. Similarly, if Scope(DA) > > Scope(DB), then prefer DB. > > This rule may be sometimes controversial, but I personally think it is > reasonable, because we can (in theory) expect better reachability for > a smaller scope of destinations. This is especially true for a > link-local destination where we don't need L3 routing. Rule #2 is not a problem, rule #8 is. The problem is that the address selected for one connection pair may end up getting reused in other scope. So if rule 8 results in an LL or SL address being used, there might be an attempt to reuse that address (perhaps by another application component) in a different scope. There really should be a rule to the effect "avoid scoped addresses if at all possible". Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 13 04:39:40 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DBddk7023007; Thu, 13 Jun 2002 04:39:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5DBddEj023006; Thu, 13 Jun 2002 04:39: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.12.4/8.12.4) with ESMTP id g5DBdZk7022999 for ; Thu, 13 Jun 2002 04:39:35 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA25782 for ; Thu, 13 Jun 2002 04:39:39 -0700 (PDT) Received: from mail5.nc.rr.com (fe5.southeast.rr.com [24.93.67.52]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA02373 for ; Thu, 13 Jun 2002 05:39:39 -0600 (MDT) Received: from mail pickup service by mail5.nc.rr.com with Microsoft SMTPSVC; Thu, 13 Jun 2002 07:29:19 -0400 Received: from ncmx01.mgw.rr.com ([24.93.67.251]) by mail5.nc.rr.com with Microsoft SMTPSVC(5.5.1877.687.68); Wed, 12 Jun 2002 07:34:08 -0400 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ncmx01.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5CAWubC001130 for ; Wed, 12 Jun 2002 06:32:56 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA29099; Wed, 12 Jun 2002 04:32:44 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA24163; Wed, 12 Jun 2002 03:32:34 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5CAV5k7013507; Wed, 12 Jun 2002 03:31:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5CAV5gE013506; Wed, 12 Jun 2002 03:31:05 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5CAV1k7013499 for ; Wed, 12 Jun 2002 03:31:01 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA15755 for ; Wed, 12 Jun 2002 03:31:03 -0700 (PDT) Received: from starfruit.itojun.org (ny-ppp009.iij-us.net [216.98.99.9]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA23729 for ; Wed, 12 Jun 2002 04:32:42 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id B847D7B9; Wed, 12 Jun 2002 19:29:31 +0900 (JST) To: Antonio Querubin Cc: ipng@sunroof.eng.sun.com In-reply-to: tony's message of Tue, 11 Jun 2002 23:07:32 -1000. 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: Review of"Use of /127 Prefix Length Between Routers Considered Harmful" From: Jun-ichiro itojun Hagino Date: Wed, 12 Jun 2002 19:29:31 +0900 Message-Id: <20020612102931.B847D7B9@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Why? Using unnumbered on point to point links works quite well. The only >place where I've found a numbered link to be more useful on a point to >point link is when BGP peering needs to be established across the link and >the numbered link will prevent the need to create a static route to the >remote neighbor address. checking - "unnumbered" meaning "link-local address only", am I correct? yes, p2p link without global address works just fine. 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 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 13 04:41:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DBf9k7023045; Thu, 13 Jun 2002 04:41:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5DBf9UN023042; Thu, 13 Jun 2002 04:41:09 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DBf3k7023028 for ; Thu, 13 Jun 2002 04:41:04 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA25922 for ; Thu, 13 Jun 2002 04:41:08 -0700 (PDT) Received: from mail5.nc.rr.com (fe5.southeast.rr.com [24.93.67.52]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA18433 for ; Thu, 13 Jun 2002 04:41:07 -0700 (PDT) Received: from mail pickup service by mail5.nc.rr.com with Microsoft SMTPSVC; Thu, 13 Jun 2002 07:29:40 -0400 Received: from ncmx01.mgw.rr.com ([24.93.67.251]) by mail5.nc.rr.com with Microsoft SMTPSVC(5.5.1877.687.68); Wed, 12 Jun 2002 09:09:58 -0400 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ncmx01.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5CD9wbC003338 for ; Wed, 12 Jun 2002 09:09:58 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA27009; Wed, 12 Jun 2002 07:10:06 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA10587; Wed, 12 Jun 2002 06:08:18 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5CD6jk7013903; Wed, 12 Jun 2002 06:06:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5CD6jmY013902; Wed, 12 Jun 2002 06:06:45 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5CD6ek7013888 for ; Wed, 12 Jun 2002 06:06:41 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA07517 for ; Wed, 12 Jun 2002 06:06:44 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA18709 for ; Wed, 12 Jun 2002 06:06:43 -0700 (PDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5CD6bn22980; Wed, 12 Jun 2002 09:06:37 -0400 (EDT) Message-Id: <200206121306.g5CD6bn22980@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: Thomas Narten , ipng@sunroof.eng.sun.com Subject: Re: IESG comments on draft-ietf-ipngwg-default-addr-select-06.txt In-reply-to: (Your message of "Wed, 12 Jun 2002 21:30:37 +0900.") Date: Wed, 12 Jun 2002 09:06:37 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > As for the impacts on the applications' behavior, I don't worry so > much. I've configured my laptop to prefer temporary addresses over a > year (for experiences - I'm not a privacy-conscious guy), and I've > never seen a trouble with the environment. I admit I'm only using a > limited type of applications (and we cannot be sure about future > applications), but I believe it covers a certain amount of today's > major applications, including pop client, smtp client, www client, ftp > client, ssh client, and DNS resolver. In particular, I don't worry > about the "relatively short lifetime" through the experience. I don't think it's reasonable to allow "today's major applications" to constrain the behavior of all present and future applications. I work with p2p and distributed systems every day, and trying to deal with temporary and scoped addresses really is very difficult for them. If we are not careful we will end up imposing NAT-like restrictions in IPv6 even if IPv6 does not have NATs. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Jun 13 05:26:52 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DCQqk7023977; Thu, 13 Jun 2002 05:26:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5DCQqUI023975; Thu, 13 Jun 2002 05:26:52 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DCQkk7023956 for ; Thu, 13 Jun 2002 05:26:47 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA07223 for ; Thu, 13 Jun 2002 05:26:51 -0700 (PDT) Received: from mail5.nc.rr.com (fe5.southeast.rr.com [24.93.67.52]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA06215 for ; Thu, 13 Jun 2002 05:26:43 -0700 (PDT) Received: from mail pickup service by mail5.nc.rr.com with Microsoft SMTPSVC; Thu, 13 Jun 2002 08:01:12 -0400 Received: from mail pickup service by mail5.nc.rr.com with Microsoft SMTPSVC; Tue, 11 Jun 2002 15:52:46 -0400 Received: from ncmx01.mgw.rr.com ([24.93.67.251]) by mail5.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Mon, 10 Jun 2002 16:40:01 -0400 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ncmx01.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5AKe1tH020070 for ; Mon, 10 Jun 2002 16:40:02 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA07291; Mon, 10 Jun 2002 13:38:59 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA08900; Mon, 10 Jun 2002 13:38:56 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5AKbFk7008367; Mon, 10 Jun 2002 13:37:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5AKbFOC008366; Mon, 10 Jun 2002 13:37:15 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5AKbBk7008359 for ; Mon, 10 Jun 2002 13:37:12 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA05537 for ; Mon, 10 Jun 2002 13:37:16 -0700 (PDT) Received: from mail-blue.research.att.com (H-135-207-30-102.research.att.com [135.207.30.102]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA04259 for ; Mon, 10 Jun 2002 14:37:11 -0600 (MDT) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id D3D6E4CEBC; Mon, 10 Jun 2002 16:37:06 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id QAA11248; Mon, 10 Jun 2002 16:37:05 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id NAA25889; Mon, 10 Jun 2002 13:37:05 -0700 (PDT) Message-Id: <200206102037.NAA25889@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: dthaler@windows.microsoft.com Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols Cc: ipng@sunroof.eng.sun.com Date: Mon, 10 Jun 2002 13:37:05 -0700 Versions: dmail (solaris) 2.4c/makemail 2.9d Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Yes, scopes have to be convex. This is not new in IPv6. >See section 7 of the IPv4 scoped multicast RFC (2365). The worry is that people might look at routing protocols mechanisms that keep the site convex wrt site-local addresses and consider that sufficient. draft-ietf-ipngwg-scoping-arch-03.txt only says: o Each zone is required to be "convex" from a routing perspective, i.e., packets sent from one interterface to any other interface in the same zone are never routed outside the zone. which does not seem to preclude my example topology, since the routing protocol causes the site-local scope zone to be convex. 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 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 13 05:36:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DCadk7024814; Thu, 13 Jun 2002 05:36:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5DCadYZ024813; Thu, 13 Jun 2002 05:36:39 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DCaZk7024806 for ; Thu, 13 Jun 2002 05:36:35 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA09816 for ; Thu, 13 Jun 2002 05:36:40 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA25397 for ; Thu, 13 Jun 2002 06:36:39 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5DCaVY00878; Thu, 13 Jun 2002 08:36:33 -0400 (EDT) Message-Id: <200206131236.g5DCaVY00878@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Bound, Jim" cc: "Keith Moore" , "Steven M. Bellovin" , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-reply-to: (Your message of "Thu, 13 Jun 2002 08:30:54 EDT.") <9C422444DE99BC46B3AD3C6EAFC9711B020B8A02@tayexc13.americas.cpqcorp.net> Date: Thu, 13 Jun 2002 08:36:31 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > link-locals are different. The reason is that link-local is a > control mechanisms in the Internet architecture and gives the > /etc/init of stateless addr-conf, whereas site-local is a carry > over of the band-aid of private addresses from IPv4 gone bad. I understand the need for LLs. But it would be a Good Idea IMHO to explain that they're not intended for general-purpose use or as a security mechanism, nor to relieve simple devices of the burden of supporting other mechanisms for acquiring addresses (and this applies to IPv4 also!) > As an implementor I would love to rip out all but global, multicast, > and link-local from the architecture it would be worth the pain and > as Margaret pointed out in her /etc/init and steve responded to they > don't work anywhere now. > Lets kill them. I'm inclined to agree, at least for SLs. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 13 05:38:43 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DCcgk7024849; Thu, 13 Jun 2002 05:38:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5DCcgok024848; Thu, 13 Jun 2002 05:38:42 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DCcck7024838 for ; Thu, 13 Jun 2002 05:38:38 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA05354 for ; Thu, 13 Jun 2002 05:38:43 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA11492 for ; Thu, 13 Jun 2002 05:38:43 -0700 (PDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5DCceY01001; Thu, 13 Jun 2002 08:38:40 -0400 (EDT) Message-Id: <200206131238.g5DCceY01001@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Bound, Jim" cc: "Keith Moore" , "R.P. Aditya" , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-reply-to: (Your message of "Thu, 13 Jun 2002 08:37:15 EDT.") <9C422444DE99BC46B3AD3C6EAFC9711B020B8A07@tayexc13.americas.cpqcorp.net> Date: Thu, 13 Jun 2002 08:38:40 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > developers who use link-local for customer apps are going to get burned. tell that to the zeroconf folks. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 13 05:46:05 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DCk5k7024932; Thu, 13 Jun 2002 05:46:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5DCk5NB024931; Thu, 13 Jun 2002 05:46:05 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DCk1k7024924 for ; Thu, 13 Jun 2002 05:46:01 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA26049 for ; Thu, 13 Jun 2002 05:46:06 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA14981 for ; Thu, 13 Jun 2002 05:46:05 -0700 (PDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5DChRY01350; Thu, 13 Jun 2002 08:43:27 -0400 (EDT) Message-Id: <200206131243.g5DChRY01350@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Bound, Jim" cc: itojun@iijlab.net, "Keith Moore" , "R.P. Aditya" , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-reply-to: (Your message of "Thu, 13 Jun 2002 08:39:31 EDT.") <9C422444DE99BC46B3AD3C6EAFC9711B020B8A08@tayexc13.americas.cpqcorp.net> Date: Thu, 13 Jun 2002 08:43:27 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Go say FTP or DNS to your private accountant, lawyer, or doctors office > they will look at us like we have two heads. yeah, but they do that no matter what I say to them, unless it's "here is your money" :) I agree that we shouldn't fall into the trap of assuming that everybody uses the same apps, or that the web and email are the only important use cases for the 'net. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 13 05:49:04 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DCn4k7024974; Thu, 13 Jun 2002 05:49:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5DCn4HY024973; Thu, 13 Jun 2002 05:49:04 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DCn0k7024966 for ; Thu, 13 Jun 2002 05:49:00 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA12297 for ; Thu, 13 Jun 2002 05:49:05 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA02846 for ; Thu, 13 Jun 2002 05:49:04 -0700 (PDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5DClhY01491; Thu, 13 Jun 2002 08:47:43 -0400 (EDT) Message-Id: <200206131247.g5DClhY01491@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Pekka Savola cc: Thomas Narten , JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= , ipng@sunroof.eng.sun.com Subject: Re: IESG comments on draft-ietf-ipngwg-default-addr-select-06.txt In-reply-to: (Your message of "Thu, 13 Jun 2002 08:56:23 +0300.") Date: Thu, 13 Jun 2002 08:47:43 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From my perspective, it is OK to prefer temporary addresses _but only if_ > using them isn't enabled by default. I guess it depends on who does the enabling. If it's the app that does the enabling, maybe that's okay. But I don't think it's reasonable to let the host or site assign private source addresses to apps if those apps aren't prepared to deal with them. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 13 06:05:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DD5ak7025142; Thu, 13 Jun 2002 06:05:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5DD5aPw025141; Thu, 13 Jun 2002 06:05: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.12.4/8.12.4) with ESMTP id g5DD5Wk7025134 for ; Thu, 13 Jun 2002 06:05:32 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA09903 for ; Thu, 13 Jun 2002 06:05:37 -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 HAA08974 for ; Thu, 13 Jun 2002 07:05:36 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 14A8A4B24; Thu, 13 Jun 2002 22:05:32 +0900 (JST) To: Robert Elz Cc: ipng@sunroof.eng.sun.com In-reply-to: kre's message of Thu, 13 Jun 2002 16:53:41 +0700. <23436.1023962021@munnari.OZ.AU> 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: Review of"Use of /127 Prefix Length Between Routers Considered Harmful" From: itojun@iijlab.net Date: Thu, 13 Jun 2002 22:05:32 +0900 Message-ID: <5459.1023973532@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > | i usually use /64 for p2p link. it works just fine, it supports > | temporary address (RFC3041) if you desire, >Yes, no argument with any of that. As I recall, using /64 is one of >the alternatives (to using /127 which this draft was written to discourage >I believe) that is given. > >Of course, on a P2P link, any prefix length (< about 126) will support >temporary addresses, the only difference is how many of them exist to >choose between (which can't be detected from outside, which makes the >problem of having a smaller set fairly irrelevant). That is, there's >only one other node with which to possibly clash, and that one usually >has no motivation to use temporary addresses on the P2P link. read RFC3041 again carefully. it assumes 64bit interface identifier, therefore it assumes /64 subnet prefix. 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 Thu Jun 13 06:07:01 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DD71k7025170; Thu, 13 Jun 2002 06:07:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5DD71d8025169; Thu, 13 Jun 2002 06:07:01 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DD6vk7025162 for ; Thu, 13 Jun 2002 06:06:57 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA29406 for ; Thu, 13 Jun 2002 06:07:02 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA09451 for ; Thu, 13 Jun 2002 07:07:01 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5DD1qY01532; Thu, 13 Jun 2002 09:01:52 -0400 (EDT) Message-Id: <200206131301.g5DD1qY01532@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Robert Elz cc: Thomas Narten , JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= , ipng@sunroof.eng.sun.com Subject: Re: IESG comments on draft-ietf-ipngwg-default-addr-select-06.txt In-reply-to: (Your message of "Thu, 13 Jun 2002 17:02:58 +0700.") <23456.1023962578@munnari.OZ.AU> Date: Thu, 13 Jun 2002 09:01:52 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > And to Keith - yes, apps need to get a lot smarter (or perhaps a lot dumber) > about their use of addresses. That's true now with IPv4 - we've been using > temporary use addresses ever since we started using dhcp for address > assignment. Addresses come with a lease length, after which they might > be renewed, or might not be. Applications, and application protocols > simply need to deal with that. Currently we're surviving largely by > blind luck - that is, the applications that most people use need an address > to be valid for (at least) an order of magnitude less time than typical > address validity (perhaps commonly 2 orders). So, applications are just > ignoring the issue completely. To be correct, they shouldn't. I've come to the opposite conclusion - that it's completely unreasonable to expect apps (or hosts) to assume the burdens of: - selecting the "right" address from several alternatives without knowledge of their own location in the network topology and that of all of their current and future peers, - dealing with multiple addressing realms (limited-scope addresses are another form of this), where the components of an app are not all in the same realm, or - expecting apps to know enough about network topology to explicitly tunnel through (or configure) NATs, and - continuing operation across address changes without either support in lower layer protocols to do this or a reliable means of propagating address change information to everyone who has an old address (they don't necessarily have an open connection) and that to the degree that apps were ever expected to do this, the folks who expected them to do those things were on drugs. it's not just that the apps are being expected to make decisions in the absence of adequate information to make those decisions (as in, which of the following N addresses is the best one to use?), it's also unreasonable to impose burdens on every app that are better handled by the network. (e.g. the routing system is having scaling problems, so we'll let hosts or apps do address selection to avoid having multihomed sites defeat provider-based addressing - never mind that they are even less prepared to do routing than the routing system.) We're not "surviving" by blind luck at all - we're "surviving" by pretending that the only apps that matter are those which only need addresses for a short time (e.g. "web and email are typical") and ignoring the apps that fail when this assumption doesn't hold. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 13 06:44:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DDiXk7025325; Thu, 13 Jun 2002 06:44:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5DDiXl5025324; Thu, 13 Jun 2002 06:44:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DDiUk7025317 for ; Thu, 13 Jun 2002 06:44:30 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA06636 for ; Thu, 13 Jun 2002 06:44:33 -0700 (PDT) Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA26110 for ; Thu, 13 Jun 2002 07:44:31 -0600 (MDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5DDiTE8066004 for ; Thu, 13 Jun 2002 15:44:29 +0200 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with SMTP id g5DDiSq124978 for ; Thu, 13 Jun 2002 15:44:28 +0200 Received: from lig32-225-250-117.us.lig-dial.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA41628 from ; Thu, 13 Jun 2002 15:44:22 +0200 Message-Id: <3D08A1ED.140FCE3@hursley.ibm.com> Date: Thu, 13 Jun 2002 15:45:17 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: ipng@sunroof.eng.sun.com Cc: Thomas Narten Subject: Re: IESG comments on draft-ietf-ipngwg-default-addr-select-06.txt References: <4.2.2.20020612103350.022dca80@mail.windriver.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk JINMEI Tatuya / $B?@L@C#:H(B wrote: > > >>>>> On Wed, 12 Jun 2002 10:38:24 -0400, > >>>>> Margaret Wasserman said: > > >> The proposed text is trying to say that temporary addresses are preferable > >> but that there might be issues (such as applications having problems) > >> which consistitute a good enough reason to not follow the default. > >> Thus there is significant freedom for implementors to use their best > >> judgement based on their knowledge about the applications. > > > Is it optional for a vendor to implement temporary addresses? Is it optional > > for a user to configure site-local addresses on a box (or perhaps even for > > a vendor to support them)? > > Good point...I thought in this context we assume vendors implement > temporary addresses and users configure temporary addresses by > default. Otherwise, the original concern: > > "The IESG is concerned that if temporary addresses are not enabled by > default, they won't see widespread use in practice." > > would not make sense. But in fact that isn't a correct assumption. It's only a certain class of systems (today's pure-client style PCs or their equivalents) for which the privacy aspect of temporary addresses makes any sense. For them, a SHOULD rule for preferring temporary addresses makes sense. But many other hosts (servers and anything that wants to break out of the client/server restriction) won't use temporary addresses and will use other privacy mechanisms; so for them it's simply irrelevant. I think that is the answer to my colleague Roy Brabson's objection to the proposed change - hosts that have the problem he describes won't be using temporary addresses anyway. And anyone who attempts to run server style apps on a host using temporary addresses will get all kinds of trouble anyway. But it should be a SHOULD. Brian - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment at the IBM Zurich Laboratory, Switzerland Board Chairman, Internet Society http://www.isoc.org INET 2002, Washington, DC, 18-21 June http://www.inet2002.org <<=== seats still available! > If, for example, the premise is implementing and configuring temporary > addresses are both optional, I'll be just okay with the proposed > change. Users (or administrators) who dare to configure temporary > addresses under such an environments should have a strong desire for > privacy. So, even if the source address selection prefers public > address by default, such users will explicitly (try to) reverse the > logic for every communication. This makes the default meaningless, > and thus preferring temporary address should make much sense. > (though the premise would be meaningless according to the original > motivation; widespread use of temporary addresses) > > X-Mozilla-Status: 0009 > 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 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 13 07:02:26 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DE2Qk7025389; Thu, 13 Jun 2002 07:02:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5DE2PYw025388; Thu, 13 Jun 2002 07:02:25 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DE2Mk7025381 for ; Thu, 13 Jun 2002 07:02:22 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA10607 for ; Thu, 13 Jun 2002 07:02:26 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA08280; Thu, 13 Jun 2002 07:02:25 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g5DE2G914004; Thu, 13 Jun 2002 17:02:16 +0300 Date: Thu, 13 Jun 2002 17:02:16 +0300 (EEST) From: Pekka Savola To: "Bound, Jim" cc: Michel Py , , Bob Hinden , "Steven M. Bellovin" , Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B020B8A0E@tayexc13.americas.cpqcorp.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 13 Jun 2002, Bound, Jim wrote: > I don't do warm and fuzzy in the IETF. [...] My point exactly. I believe site-locals as a serious security measure mainly provide a "warm fuzzy feeling" like NAT does with IPv4 today. > > -----Original Message----- > > From: Pekka Savola [mailto:pekkas@netcore.fi] > > Sent: Saturday, June 08, 2002 6:20 AM > > To: Michel Py > > Cc: sommerfeld@east.sun.com; Bob Hinden; Steven M. Bellovin; > > ipng@sunroof.eng.sun.com > > Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols > > > > > > On Fri, 7 Jun 2002, Michel Py wrote: > > > > If there is widespread deployment of systems with site-local only > > > > addresses, this will in turn drive the creation of ipv6 NAT > > > > specifically to give them external connectivity.. > > > > > > That looks like a solution without a problem. To give these hosts > > > connectivity you just have both the site-local and the > > global address. > > > Since NAT would not bring anything to the table why > > implement it in the > > > first place? > > > > To give folks that think IPv4 private addresses provide security > > (especially wrt. incoming connections) a smooth transition > > path to IPv6 > > and "warm fuzzy feeling". > > > > -- > > Pekka Savola "Tell me of difficulties surmounted, > > Netcore Oy not those you stumble over and fall" > > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > > > -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 13 08:23:03 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DFN3k7025536; Thu, 13 Jun 2002 08:23:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5DFN3TE025535; Thu, 13 Jun 2002 08:23:03 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DFMxk7025528 for ; Thu, 13 Jun 2002 08:22:59 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA01982 for ; Thu, 13 Jun 2002 08:23:00 -0700 (PDT) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA15989 for ; Thu, 13 Jun 2002 09:22:59 -0600 (MDT) Subject: RE: Review of"Use of /127 Prefix Length Between Routers Considered Harmful" Date: Thu, 13 Jun 2002 08:22:57 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046406C819@server2000.arneill-py.sacramento.ca.us> X-MS-Has-Attach: X-MS-TNEF-Correlator: X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Topic: Review of"Use of /127 Prefix Length Between Routers Considered Harmful" Thread-Index: AcISmW8sOnqHbI3BSS28OAq5gSWcxQAVKkOg content-class: urn:content-classes:message From: "Michel Py" To: "Jun-ichiro itojun Hagino" , "Robert Elz" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5DFN0k7025529 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Jun-ichiro itojun Hagino wrote: > I usually use /64 for p2p link. it works just fine, it supports > temporary address (RFC3041) if you desire, i can think of no reason to > use somethiing other than /64. I agree. I think the only option is /64. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 13 08:48:42 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DFmfk7025629; Thu, 13 Jun 2002 08:48:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5DFmfjN025628; Thu, 13 Jun 2002 08:48:41 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DFmak7025621 for ; Thu, 13 Jun 2002 08:48:36 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA11002 for ; Thu, 13 Jun 2002 08:48:40 -0700 (PDT) Received: from mail4.nc.rr.com (fe4.southeast.rr.com [24.93.67.51]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA01147 for ; Thu, 13 Jun 2002 09:50:26 -0600 (MDT) Received: from mail pickup service by mail4.nc.rr.com with Microsoft SMTPSVC; Thu, 13 Jun 2002 11:22:05 -0400 Received: from mail pickup service by mail4.nc.rr.com with Microsoft SMTPSVC; Tue, 11 Jun 2002 21:37:13 -0400 Received: from ncmx01.mgw.rr.com ([24.93.67.251]) by mail4.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Mon, 10 Jun 2002 14:32:18 -0400 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ncmx01.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5AIWItH001733 for ; Mon, 10 Jun 2002 14:32:18 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA26749; Mon, 10 Jun 2002 11:30:57 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA27665; Mon, 10 Jun 2002 11:30:48 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5AISSk7007845; Mon, 10 Jun 2002 11:28:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5AISRFL007844; Mon, 10 Jun 2002 11:28:27 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5AISQk7007837 for ; Mon, 10 Jun 2002 11:28:26 -0700 (PDT) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g5AISPoR003226 for ; Mon, 10 Jun 2002 11:28:25 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g5AISOtu003225 for ipng@sunroof.eng.sun.com; Mon, 10 Jun 2002 11:28:24 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g57DGtk7000111 for ; Fri, 7 Jun 2002 06:16:55 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA22104 for ; Fri, 7 Jun 2002 06:16:57 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA23054 for ; Fri, 7 Jun 2002 07:18:18 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id D23A36A90A; Fri, 7 Jun 2002 16:16:55 +0300 (EEST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 586BC6A907 for ; Fri, 7 Jun 2002 16:16:54 +0300 (EEST) Message-ID: <3D00B28F.1080902@piuha.net> Date: Fri, 07 Jun 2002 16:18:07 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: finalizing cellular hosts document, version -03 now out References: <3CFFD2EC.101@kolumbus.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Version -03 of the cellular host document has now been published. You can download it from http://www-nrc.nokia.com/sua/draft-ietf-ipv6-cellular-host-03.txt http://www-nrc.nokia.com/sua/draft-ietf-ipv6-cellular-host-03-pa10.doc (with edits) Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 13 08:53:17 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DFrGk7026890; Thu, 13 Jun 2002 08:53:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5DFrG4o026889; Thu, 13 Jun 2002 08:53:16 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DFrCk7026876 for ; Thu, 13 Jun 2002 08:53:12 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA13000 for ; Thu, 13 Jun 2002 08:53:17 -0700 (PDT) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA04038 for ; Thu, 13 Jun 2002 09:55:02 -0600 (MDT) Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols Date: Thu, 13 Jun 2002 08:53:15 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046405E103@server2000.arneill-py.sacramento.ca.us> X-MS-Has-Attach: X-MS-TNEF-Correlator: X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Topic: Fwd: IPv6 Scoped Addresses and Routing Protocols Thread-Index: AcIOfRN+y4xtk9PHTVuKh9jceogLnwEWz/2QAAWXooA= content-class: urn:content-classes:message From: "Michel Py" To: "Bound, Jim" , Cc: "Bob Hinden" , "Steven M. Bellovin" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5DFrDk7026878 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Jim Bound wrote: > and this is my biggest fear for the Internet with IPv6. These > site-locals could undo all we did with IPv6 to restore end-to-end > architecture for the Internet. > Trying to limit them with words or BCPs whatever will NOT prevent > the potential tragedy to our beloved Internet I share your concern, I just don't think that there are good reasons to develop IPv6 NAT. Besides, there are plenty of other things that break end-to-end and will continue to break it: Load balancers, cache engines, etc. A word about "warm an fuzzy": "warm and fuzzy" is a requirement. There will be IPv6 firewalls, I actually think there will not be any serious IPv6 setup without a firewall. What is a firewall? It's a big, bulky, very expensive rack-mounted device with the word "firewall" screened in big letters on the front. What does it do? It makes senior management feel secure. A firewall does not protect a network more than a private IP does. It can be bypassed as I explained before. I regret to report that the very existence of firewalls and load balancers is not something you and I will change. I would apply the same reasoning to site-local addresses. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 13 09:17:11 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DGHAk7027234; Thu, 13 Jun 2002 09:17:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5DGHASg027233; Thu, 13 Jun 2002 09:17:10 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DGH6k7027226 for ; Thu, 13 Jun 2002 09:17:06 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA21361 for ; Thu, 13 Jun 2002 09:17:11 -0700 (PDT) Received: from esunmail ([129.147.58.122]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA05050 for ; Thu, 13 Jun 2002 10:17:11 -0600 (MDT) Received: from xpa-fe2 (esunmail-ge1 [129.147.58.122]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 0.3 (built May 13 2002)) with ESMTP id <0GXN009U3JWK0D@edgemail1.Central.Sun.COM> for ipng@sunroof.eng.sun.com; Thu, 13 Jun 2002 10:17:10 -0600 (MDT) Received: from localhost ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 0.2 (built Apr 26 2002)) with ESMTPSA id <0GXN003C2JWJWX@mail.sun.net> for ipng@sunroof.eng.sun.com; Thu, 13 Jun 2002 10:17:08 -0600 (MDT) Date: Thu, 13 Jun 2002 09:17:09 -0700 From: Alain Durand Subject: Re: IESG comments on draft-ietf-ipngwg-default-addr-select-06.txt In-reply-to: <200206122013.g5CKDba02101@rotala.raleigh.ibm.com> To: Thomas Narten Cc: ipng@sunroof.eng.sun.com Message-id: <02D0BA0B-7EE9-11D6-A8D7-00039376A6AA@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.482) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wednesday, June 12, 2002, at 01:13 PM, Thomas Narten wrote: > The default-addr-select document isn't mandating the use of temporary > addresses. So what is being requested here is that *if* temporary > addresses have been implemented and are being used, *then* give them > preference over public addresses. The problem I have with this is, if I decide to implement temporary addresses to enable something like Netscape to use it, with the IESG suggestion, I will also have to revisit at the same time rlogin and many other applications that rather like to use permanent addresses. This would create a serious burden to first identify all those applications and second to modify them all before I can release support for temporary addresses in the OS. And as I do not control 3rd party applications, this gets even more complex. So, I'm very worried that the IESG suggestion could end up being a reason for me not to implement temporary addresses at all. - 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 Jun 13 09:32:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DGWNk7027320; Thu, 13 Jun 2002 09:32:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5DGWNqn027319; Thu, 13 Jun 2002 09:32:23 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DGWKk7027312 for ; Thu, 13 Jun 2002 09:32:20 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA00318 for ; Thu, 13 Jun 2002 09:32:25 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA23451; Thu, 13 Jun 2002 09:32:24 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g5DGWNb15267; Thu, 13 Jun 2002 19:32:23 +0300 Date: Thu, 13 Jun 2002 19:32:23 +0300 (EEST) From: Pekka Savola To: Alain Durand cc: Thomas Narten , Subject: Re: IESG comments on draft-ietf-ipngwg-default-addr-select-06.txt In-Reply-To: <02D0BA0B-7EE9-11D6-A8D7-00039376A6AA@sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 13 Jun 2002, Alain Durand wrote: > On Wednesday, June 12, 2002, at 01:13 PM, Thomas Narten wrote: > > > The default-addr-select document isn't mandating the use of temporary > > addresses. So what is being requested here is that *if* temporary > > addresses have been implemented and are being used, *then* give them > > preference over public addresses. > > The problem I have with this is, if I decide to implement temporary > addresses to enable something like Netscape to use it, with the IESG > suggestion, I will also have to revisit at the same time rlogin and many > other applications that rather like to use permanent addresses. [...] I cannot see anything application-specific at least in the above quote from Thomas. I expect using temporary addresses would be a system-level toggle which might be fine-tunable via some API. ... The user can always shoot himself in the foot. If there are concerns (most of them valid, I think) with applications not working properly with temporary addresses this should result in something equivalent to: 1) temporary addresses SHOULD(/MUST) be off by default 2) develop a better mechanism for privacy, temp-addr v2 (v3? :-) or describe the issues with applications and how to avoid them 3) revisit decision 1) when 2) is analyzed and/or implemented IMO, "temporary addresses" should only be randomized when: 1) (re)starting the OS, or 2) when there are no open sockets (basically 1), or 3) manually requested (users would be dissatisfied if they couldn't shoot themselves in the foot) In consequence, I think in many cases, a sufficient amount of privacy would be gained in client systems without all that many drawbacks. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 13 09:53:21 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DGrKk7027372; Thu, 13 Jun 2002 09:53:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5DGrKgB027371; Thu, 13 Jun 2002 09:53:20 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DGrGk7027364 for ; Thu, 13 Jun 2002 09:53:16 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA04511 for ; Thu, 13 Jun 2002 09:53:21 -0700 (PDT) Received: from esunmail ([129.147.58.121]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA12708 for ; Thu, 13 Jun 2002 10:55:07 -0600 (MDT) Received: from xpa-fe1 (esunmail-ge1 [129.147.58.122]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 0.3 (built May 13 2002)) with ESMTP id <0GXN009JDLKV0E@edgemail1.Central.Sun.COM> for ipng@sunroof.eng.sun.com; Thu, 13 Jun 2002 10:53:20 -0600 (MDT) Received: from localhost ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 0.2 (built Apr 26 2002)) with ESMTPSA id <0GXN006PDLKU1H@mail.sun.net> for ipng@sunroof.eng.sun.com; Thu, 13 Jun 2002 10:53:19 -0600 (MDT) Date: Thu, 13 Jun 2002 09:53:19 -0700 From: Alain Durand Subject: Re: IESG comments on draft-ietf-ipngwg-default-addr-select-06.txt In-reply-to: To: Pekka Savola Cc: Thomas Narten , ipng@sunroof.eng.sun.com Message-id: <105615F9-7EEE-11D6-A8D7-00039376A6AA@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.482) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thursday, June 13, 2002, at 09:32 AM, Pekka Savola wrote: > On Thu, 13 Jun 2002, Alain Durand wrote: >> On Wednesday, June 12, 2002, at 01:13 PM, Thomas Narten wrote: >> >>> The default-addr-select document isn't mandating the use of temporary >>> addresses. So what is being requested here is that *if* temporary >>> addresses have been implemented and are being used, *then* give them >>> preference over public addresses. >> >> The problem I have with this is, if I decide to implement temporary >> addresses to enable something like Netscape to use it, with the IESG >> suggestion, I will also have to revisit at the same time rlogin and >> many >> other applications that rather like to use permanent addresses. > [...] > > I cannot see anything application-specific at least in the above quote > from Thomas. > > I expect using temporary addresses would be a system-level toggle which > might be fine-tunable via some API. Great! I implement a system level switch, a user turn it on to enable 'privacy' on its browser and all the sudden rlogin & co stop working! Support people are going to be very happy. So, I _need_ to modify all the apps that operate better with stable addresses, before I release such a switch in the general public. - 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 Jun 13 10:23:01 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DHN1k7027514; Thu, 13 Jun 2002 10:23:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5DHN1Le027513; Thu, 13 Jun 2002 10:23:01 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DHMwk7027506 for ; Thu, 13 Jun 2002 10:22:58 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA16446 for ; Thu, 13 Jun 2002 10:23:01 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA16785 for ; Thu, 13 Jun 2002 11:23:00 -0600 (MDT) Message-ID: <009c01c212fe$afdf10e0$256015ac@T23KEMPF> From: "James Kempf" To: "Bound, Jim" , References: <9C422444DE99BC46B3AD3C6EAFC9711B020B8A04@tayexc13.americas.cpqcorp.net> Subject: Re: Securing Neighbor Discovery BOF Date: Thu, 13 Jun 2002 10:20:54 -0700 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 Hi Jim, > What is the point of this meeting. We have so many meetings to go to. > > Just turn on IPsec whats not in ND to support this? > > What problem are you trying to solve? > > IPsec works for ND? > We are interested in discussing how to secure IPv6 Neighbor Discovery in a way that would work well for public access networks (but not exclusively confined to that). RFC 2461 specifies that IPsec should be used to secure the signaling involved in ND, but does not provide any details about how this should be done, and, specifically, how key distribution would be done. IKE won't work because it requires ND so there is a bootstrapping problem. Manual keying would work for a small private network, and possibly even for a larger enterprise network, but it would be extremely inconvenient for public access networks. There have also been some proposals to use other security protocols rather than IPsec for ND security. The immediate need for this work comes out of plans by ISPs, especially in Asia, to deploy public access IPv6 wireless networks (NTT Communications is running a prototype deployment in Kyoto at the moment). While the problem of ND security is not, in principle, any better or worse with wireless than with wireline, current wireline links tend to have less of a problem because they typically are point to point rather than multi-access, so the issue doesn't arise, though it might also be a problem with wireline multi-access links that do not use PPPoE or other solutions to make the link look point to point. If you are interested in the potential threats, I'd suggest reading draft-kempf-netaccess-threats-01.txt, which I've just resubmitted to the Internet drafts editor (it had timed out in April), and if you have something specific you would like to speak about, please let either Pekka or myself know. jak -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 13 10:36:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DHa8k7027588; Thu, 13 Jun 2002 10:36:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5DHa8uE027587; Thu, 13 Jun 2002 10:36:08 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DHa4k7027580 for ; Thu, 13 Jun 2002 10:36:04 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA29913 for ; Thu, 13 Jun 2002 10:36:08 -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 LAA26391 for ; Thu, 13 Jun 2002 11:36:06 -0600 (MDT) Received: from localhost ([3ffe:501:100f:1041::6]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g5DHZu805446; Fri, 14 Jun 2002 02:35:56 +0900 (JST) Date: Fri, 14 Jun 2002 02:35:59 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Brian E Carpenter Cc: ipng@sunroof.eng.sun.com Subject: Re: IESG comments on draft-ietf-ipngwg-default-addr-select-06.txt In-Reply-To: <3D08A1ED.140FCE3@hursley.ibm.com> References: <4.2.2.20020612103350.022dca80@mail.windriver.com> <3D08A1ED.140FCE3@hursley.ibm.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 51 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Thu, 13 Jun 2002 15:45:17 +0200, >>>>> Brian E Carpenter said: > But in fact that isn't a correct assumption. It's only a certain class of > systems (today's pure-client style PCs or their equivalents) for which the > privacy aspect of temporary addresses makes any sense. For them, a SHOULD rule > for preferring temporary addresses makes sense. But many other hosts (servers > and anything that wants to break out of the client/server restriction) won't > use temporary addresses and will use other privacy mechanisms; so for them > it's simply irrelevant. I think that is the answer to my colleague Roy Brabson's > objection to the proposed change - hosts that have the problem he describes > won't be using temporary addresses anyway. And anyone who attempts to run server > style apps on a host using temporary addresses will get all kinds of trouble > anyway. (though I'm not making an objection to what you're sayign) let me clarify the issue (mostly for myself) once more. We're perhaps mixing up host issues and application issues. In my understanding, 1. whether or not privacy is desired is a per-host (or per-administrator) issue, not a per-application issue; if the main user (likely the administrator) of a host really wants the privacy, the user wants the privacy apply to all applications on the host, even if some of the applications do not work well due to the characteristics of temporary addresses. 2. an application may not work well with temporary addresses. 3. there are only few privacy-conscious users, and there will few too in the near future. So, the specification should be: - the privacy extension draft should clearly say that it is optional to (support and) configure temporary addresses and that the default is not configuring temporary addresses. the draft should also describe the troublesome cases with temporary addresses to communicate the risk of using them for administrators. - the address selection draft should say *if temporary addresses are configured on the host* the temporary addresses should be preferred. It should also note that whether or not configuring temporary addresses are optional and the default is not configuring them. - we'll not necessarily need a per-connection switch to change the logic of preferring temporary or public addresses, because if we want privacy or not is rather a per-host issue. we MAY add such a knob, but it does not have to be a MUST. Can this be a compromise for this issue? 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 Thu Jun 13 10:46:18 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DHkHk7027649; Thu, 13 Jun 2002 10:46:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5DHkHnh027648; Thu, 13 Jun 2002 10:46:17 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DHkEk7027639 for ; Thu, 13 Jun 2002 10:46:14 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA04407; Thu, 13 Jun 2002 13:46:17 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g5DHkHZs003644; Thu, 13 Jun 2002 13:46:17 -0400 (EDT) Message-Id: <200206131746.g5DHkHZs003644@thunk.east.sun.com> From: Bill Sommerfeld To: "James Kempf" cc: "Steven M. Bellovin" , "Jari Arkko" , "Pekka Savola" , ipng@sunroof.eng.sun.com Subject: Re: Securing Neighbor Discovery BOF In-Reply-To: Your message of "Mon, 10 Jun 2002 11:51:43 PDT." <002f01c210af$df9ec240$246015ac@T23KEMPF> Reply-to: sommerfeld@east.sun.com Date: Thu, 13 Jun 2002 13:46:17 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > So is it the case then that there would be no change in IPsec policy > required for doing AAA-based or roaming consortia-based key > management? "policy" could mean a lot of things. the overall architecture does not require change. the idea that there can be more than one way to manage keys is part of it; it's also part of many implementations. The policy model will likely need to be extended to add new selectors (for icmpv6 type/code) because ND "hides" inside icmpv6, but that's an obvious and (based on previous times when it's been brought up in the ipsec working group) apparently noncontroversial extension akin to the existing port-based selectors. - 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 Jun 13 10:57:20 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DHvKk7027768; Thu, 13 Jun 2002 10:57:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5DHvKkC027767; Thu, 13 Jun 2002 10:57:20 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DHvGk7027759 for ; Thu, 13 Jun 2002 10:57:16 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA07194 for ; Thu, 13 Jun 2002 10:57:20 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA12484 for ; Thu, 13 Jun 2002 10:57:19 -0700 (PDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5DHvGY02873; Thu, 13 Jun 2002 13:57:16 -0400 (EDT) Message-Id: <200206131757.g5DHvGY02873@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Brian E Carpenter cc: ipng@sunroof.eng.sun.com, Thomas Narten Subject: Re: IESG comments on draft-ietf-ipngwg-default-addr-select-06.txt In-reply-to: (Your message of "Thu, 13 Jun 2002 15:45:17 +0200.") <3D08A1ED.140FCE3@hursley.ibm.com> Date: Thu, 13 Jun 2002 13:57:16 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > And anyone who attempts to run server style apps on a host using temporary > addresses will get all kinds of trouble anyway. I don't believe in the client-host vs. server-host distinction. Yes, I realize that large-scape production "servers" usually need dedicated hardware. But there are lots of things that want to answer to unsolicited input that don't run on dedicated hardware. Most hosts are going to run a mixture of clients, servers, and p2p apps. A per-host "use temporary addresses by default" bit is just another bit that needs to be set to false so much of the time that you're far better off never setting it to true. The presence of this bit increases the burden for both applications (which have to work regardless of this bit setting) and sysadmins (for whom the bit creates one more obscure failure mode that they need to worry about) without any measurable benefit. You'll get far better results by not having this bit, and having apps that can use temporary addresses ask for them explicitly. The apps that can use those addresses only need to add or change one line of code; those that can't use them don't have to change at all, and sysadmins don't have to do anything. OTOH, if you do have this bit, some apps will incorporate their own address selection code (because there's no way to get the system library to do what is needed), others won't, and for the sake of those others sysadmins will have to worry about whether that bit is set correctly. This is one of those solutions that creates more problems than it solves. Life will be simpler and things will work smoother without that bit. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 13 12:03:07 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DJ37k7028074; Thu, 13 Jun 2002 12:03:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5DJ376E028073; Thu, 13 Jun 2002 12:03:07 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DJ35k7028066 for ; Thu, 13 Jun 2002 12:03:06 -0700 (PDT) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g5DJ33oR004867 for ; Thu, 13 Jun 2002 12:03:03 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g5DJ33Cu004866 for ipng@sunroof.eng.sun.com; Thu, 13 Jun 2002 12:03:03 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DCUrk7024694 for ; Thu, 13 Jun 2002 05:30:53 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA08423 for ; Thu, 13 Jun 2002 05:30:58 -0700 (PDT) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA25232 for ; Thu, 13 Jun 2002 05:30:58 -0700 (PDT) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id F2D7D6673; Thu, 13 Jun 2002 08:30:54 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 13 Jun 2002 08:30:54 -0400 x-mimeole: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols Date: Thu, 13 Jun 2002 08:30:54 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B8A02@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Fwd: IPv6 Scoped Addresses and Routing Protocols Thread-Index: AcINlAJ+6w63jHknSk+bDFGS7Y+mrgFQdFwg From: "Bound, Jim" To: "Keith Moore" , "Steven M. Bellovin" Cc: X-OriginalArrivalTime: 13 Jun 2002 12:30:54.0908 (UTC) FILETIME=[298B1FC0:01C212D6] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5DCUsk7024695 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk link-locals are different. The reason is that link-local is a control mechanisms in the Internet architecture and gives the /etc/init of stateless addr-conf, whereas site-local is a carry over of the band-aid of private addresses from IPv4 gone bad. As an implementor I would love to rip out all but global, multicast, and link-local from the architecture it would be worth the pain and as Margaret pointed out in her /etc/init and steve responded to they don't work anywhere now. Lets kill them. /jim > -----Original Message----- > From: Keith Moore [mailto:moore@cs.utk.edu] > Sent: Thursday, June 06, 2002 3:51 PM > To: Steven M. Bellovin > Cc: ipng@sunroof.eng.sun.com > Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols > > > > My strong preference would be to drop site-local addresses > completely. > > I think they're an administrative and technical nightmare. > > for that matter, so are link-local addresses. they do have some > legitimate uses, but they need to be kept to a minimum > (in both ipv6 and ipv4) > > Keith > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 13 12:03:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DJ3fk7028084; Thu, 13 Jun 2002 12:03:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5DJ3erJ028083; Thu, 13 Jun 2002 12:03:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DJ3dk7028076 for ; Thu, 13 Jun 2002 12:03:39 -0700 (PDT) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g5DJ3aoR004875 for ; Thu, 13 Jun 2002 12:03:36 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g5DJ3amk004874 for ipng@sunroof.eng.sun.com; Thu, 13 Jun 2002 12:03:36 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DCVUk7024720 for ; Thu, 13 Jun 2002 05:31:30 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA04233 for ; Thu, 13 Jun 2002 05:31:35 -0700 (PDT) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA23369 for ; Thu, 13 Jun 2002 06:31:35 -0600 (MDT) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 027331F50; Thu, 13 Jun 2002 08:31:34 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 13 Jun 2002 08:31:33 -0400 x-mimeole: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols Date: Thu, 13 Jun 2002 08:31:33 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B8A03@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Fwd: IPv6 Scoped Addresses and Routing Protocols Thread-Index: AcINtPSXDWK7rKnuTYO5CxbwzRZqnwFIT3LA From: "Bound, Jim" To: "Randy Bush" , "Steven M. Bellovin" Cc: X-OriginalArrivalTime: 13 Jun 2002 12:31:33.0861 (UTC) FILETIME=[40C2E150:01C212D6] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5DCVVk7024721 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk one of the rare times I get randy's wisdom and agree :---) /jim > -----Original Message----- > From: Randy Bush [mailto:randy@research.att.com] > Sent: Thursday, June 06, 2002 2:25 PM > To: Steven M. Bellovin > Cc: ipng@sunroof.eng.sun.com > Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols > > > > My strong preference would be to drop site-local addresses > completely. > > I think they're an administrative and technical nightmare. > > trying to solve a routing problem by an ill-understood addressing > hack. > > randy > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Jun 13 12:04:04 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DJ44k7028098; Thu, 13 Jun 2002 12:04:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5DJ44o4028097; Thu, 13 Jun 2002 12:04:04 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DJ42k7028090 for ; Thu, 13 Jun 2002 12:04:02 -0700 (PDT) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g5DJ3xoR004883 for ; Thu, 13 Jun 2002 12:03:59 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g5DJ3xTB004882 for ipng@sunroof.eng.sun.com; Thu, 13 Jun 2002 12:03:59 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DCWZk7024752 for ; Thu, 13 Jun 2002 05:32:35 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA04482 for ; Thu, 13 Jun 2002 05:32:40 -0700 (PDT) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA08805 for ; Thu, 13 Jun 2002 05:32:39 -0700 (PDT) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 1A7E5A10; Thu, 13 Jun 2002 08:32:39 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 13 Jun 2002 08:32:39 -0400 x-mimeole: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Securing Neighbor Discovery BOF Date: Thu, 13 Jun 2002 08:32:38 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B8A04@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Securing Neighbor Discovery BOF Thread-Index: AcIN/oAUkW1snc51TxKBXOwF1b6eSwE18WUA From: "Bound, Jim" To: "James Kempf" , X-OriginalArrivalTime: 13 Jun 2002 12:32:39.0087 (UTC) FILETIME=[67A393F0:01C212D6] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5DCWZk7024753 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk James, What is the point of this meeting. We have so many meetings to go to. Just turn on IPsec whats not in ND to support this? What problem are you trying to solve? IPsec works for ND? thanks /jim > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Friday, June 07, 2002 4:33 AM > To: ipng@sunroof.eng.sun.com > Subject: Securing Neighbor Discovery BOF > > > On Tues. afternoon of IETF 54 13:00-14:00, there will be a BOF held to > discuss securing Neighbor Discovery. The BOF description, along with a > suggested reading list, will appear when the agenda is posted on the > IETF 54 Web page. If you are interested in this problem, > please attend. > If you would like to speak, please send email to me or Pekka Nikkander > (Pekka.Nikander@nomadiclab.com). > > > jak > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Jun 13 12:04:19 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DJ4Ik7028115; Thu, 13 Jun 2002 12:04:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5DJ4IJg028114; Thu, 13 Jun 2002 12:04:18 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DJ4Gk7028107 for ; Thu, 13 Jun 2002 12:04:16 -0700 (PDT) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g5DJ4EoR004891 for ; Thu, 13 Jun 2002 12:04:14 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g5DJ4Du7004890 for ipng@sunroof.eng.sun.com; Thu, 13 Jun 2002 12:04:13 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DCXQk7024775 for ; Thu, 13 Jun 2002 05:33:26 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA09152 for ; Thu, 13 Jun 2002 05:33:31 -0700 (PDT) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA24146 for ; Thu, 13 Jun 2002 06:33:30 -0600 (MDT) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id E35CD5412; Thu, 13 Jun 2002 08:33:29 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 13 Jun 2002 08:33:29 -0400 x-mimeole: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Mandating Route Optimization Date: Thu, 13 Jun 2002 08:33:29 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B8A05@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Mandating Route Optimization Thread-Index: AcINheaiX9tw0vSgQRe18c5z1oXkoQAi0vOgATFRBAA= From: "Bound, Jim" To: , , X-OriginalArrivalTime: 13 Jun 2002 12:33:29.0619 (UTC) FILETIME=[85C22630:01C212D6] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5DCXQk7024776 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I agree. Its just not a good use of our time or to get this spec done. /jim > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: Friday, June 07, 2002 6:53 AM > To: dfawcus@cisco.com; ipng@sunroof.eng.sun.com > Subject: RE: Mandating Route Optimization > > > Hi Derek, > > > for routers => SHOULD > > for minimal nodes => MAY > > for other nodes => MUST > > From the entire 'Cellular Hosts' discussion, I have learned that > the concept of 'minimal nodes' is in the eye of the beholder > and quite temporal at that. > > I think we can clearly diffentiate between routers and hosts, > beyond that I am not sure it is a good idea to differentiate > further. > > John > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Jun 13 12:04:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DJ4Yk7028125; Thu, 13 Jun 2002 12:04:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5DJ4XNT028124; Thu, 13 Jun 2002 12:04:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DJ4Vk7028117 for ; Thu, 13 Jun 2002 12:04:31 -0700 (PDT) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g5DJ4ToR004899 for ; Thu, 13 Jun 2002 12:04:29 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g5DJ4S4U004898 for ipng@sunroof.eng.sun.com; Thu, 13 Jun 2002 12:04:28 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DCYmk7024792 for ; Thu, 13 Jun 2002 05:34:48 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA04767 for ; Thu, 13 Jun 2002 05:34:53 -0700 (PDT) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA26832 for ; Thu, 13 Jun 2002 05:34:52 -0700 (PDT) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id A3FDC6A00; Thu, 13 Jun 2002 08:34:51 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 13 Jun 2002 08:34:51 -0400 x-mimeole: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Securing Neighbor Discovery BOF Date: Thu, 13 Jun 2002 08:34:51 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B8A06@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Securing Neighbor Discovery BOF Thread-Index: AcIOHSoOTu8EbqB3TgmyDJqMfN2h/QEuWcgg From: "Bound, Jim" To: "Jari Arkko" , "Pekka Savola" Cc: "James Kempf" , X-OriginalArrivalTime: 13 Jun 2002 12:34:51.0594 (UTC) FILETIME=[B69E8AA0:01C212D6] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5DCYmk7024793 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jari, Can you be more clear. Customers are using IPsec for IPv4 just fine and now using IPv6 in test beds. The bake-offs work. Whats the problem. IPR is only issue for the keying. And that the IETF has punted on IMO. /jim > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@kolumbus.fi] > Sent: Friday, June 07, 2002 8:12 AM > To: Pekka Savola > Cc: James Kempf; ipng@sunroof.eng.sun.com > Subject: Re: Securing Neighbor Discovery BOF > > > > Pekka Savola wrote: > > > > Are there any non-encumbered technologies to Secure ND? > > > IP Security, for one. The current IPsec can be used, though > it's pretty cumbersome due to (a) large number of similar SAs > needed for manual keying due to destination address being a > part of SA lookup and (b) chicken-and-egg problem for IKE. > The problem (a) could be solved, and the result would be a > more easily usable IPsec for securing large private networks. > For public networks manual keying does not scale, however. > Perhaps something can be done for (b). For instance, one > possible, even if ugly, solution is to provide an ND-level > message to carry IKE-like traffic between the ND > peers until an IPsec SA can be established. Contributions > on this space are sought -- feel free to jump in here ;-) > > Then there are ABK and CGA-based techniques. > > Anyway, I'm not sure we at this point have all the solutions. > If we agree the issue is a problem, the group will figure out > the possible solutions and their pros and cons. (IPRs are > likely to be taken in account.) > > Jari > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 13 12:05:01 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DJ51k7028141; Thu, 13 Jun 2002 12:05:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5DJ50bM028140; Thu, 13 Jun 2002 12:05:00 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DJ4vk7028130 for ; Thu, 13 Jun 2002 12:04:57 -0700 (PDT) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g5DJ4toR004907 for ; Thu, 13 Jun 2002 12:04:55 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g5DJ4spA004906 for ipng@sunroof.eng.sun.com; Thu, 13 Jun 2002 12:04:54 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DCbCk7024816 for ; Thu, 13 Jun 2002 05:37:12 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA24455 for ; Thu, 13 Jun 2002 05:37:17 -0700 (PDT) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA10813 for ; Thu, 13 Jun 2002 05:37:16 -0700 (PDT) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 585EF39F8; Thu, 13 Jun 2002 08:37:16 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 13 Jun 2002 08:37:16 -0400 x-mimeole: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols Date: Thu, 13 Jun 2002 08:37:15 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B8A07@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Fwd: IPv6 Scoped Addresses and Routing Protocols Thread-Index: AcIOP/cpLJhdMfWfTlyMRFsM8AzOngEltSCw From: "Bound, Jim" To: "Keith Moore" , "R.P. Aditya" Cc: X-OriginalArrivalTime: 13 Jun 2002 12:37:16.0353 (UTC) FILETIME=[0CE70310:01C212D7] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5DCbCk7024817 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk developers who use link-local for customer apps are going to get burned. How many apps only run on a link? not many. if we kill all but global, mulicast, and link-local it will be prevented by programmer ipv6 evolution. /jim > -----Original Message----- > From: Keith Moore [mailto:moore@cs.utk.edu] > Sent: Friday, June 07, 2002 12:23 PM > To: R.P. Aditya > Cc: ipng@sunroof.eng.sun.com > Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols > > > > For link-local addresses, as long as the scope is > > well-defined, what are your objections? > > for the most part, they're only a problem if you try to use > them in applications (where zero-configuration appliances > are an important subset of applications) > > part of the problem is that the scope of link-local addresses > is *not* well-defined from an application's point of view, > since applications in general don't know, and shouldn't have > to know, about network topology. > > (scoped addresses in general are a nightmare for apps) > > so LL is fine for RD/ND etc. but the vast majority of apps > should never see them. > > unfortunately the zeroconf WG is trying to make LL addresses > be a general-purpose mechanism for internet appliances to > obtain an address - perhaps without supporting any mechanism > to get a global address, assuming (incorrectly IMHO) that the > hosts that need to access that appliance will be on the same > link anyway. > > the problem is not the fact that LL addresses exist, it's that > there are no well-defined constraints on their use. > > Keith > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 13 12:05:17 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DJ5Hk7028159; Thu, 13 Jun 2002 12:05:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5DJ5GDF028158; Thu, 13 Jun 2002 12:05:16 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DJ5Ck7028143 for ; Thu, 13 Jun 2002 12:05:12 -0700 (PDT) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g5DJ59oR004915 for ; Thu, 13 Jun 2002 12:05:09 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g5DJ595b004914 for ipng@sunroof.eng.sun.com; Thu, 13 Jun 2002 12:05:09 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DCdak7024861 for ; Thu, 13 Jun 2002 05:39:36 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA10376 for ; Thu, 13 Jun 2002 05:39:32 -0700 (PDT) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA26827 for ; Thu, 13 Jun 2002 06:39:32 -0600 (MDT) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id D60C23951; Thu, 13 Jun 2002 08:39:31 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 13 Jun 2002 08:39:31 -0400 x-mimeole: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols Date: Thu, 13 Jun 2002 08:39:31 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B8A08@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Fwd: IPv6 Scoped Addresses and Routing Protocols Thread-Index: AcIORn1zfC7JCQfWTa6ynTd78aQ+eQEkJVZA From: "Bound, Jim" To: , "Keith Moore" Cc: "R.P. Aditya" , X-OriginalArrivalTime: 13 Jun 2002 12:39:31.0795 (UTC) FILETIME=[5DA1D230:01C212D7] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5DCdak7024862 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk these are what I call "standard" Internet applications that have long lives. But a NASTRAN MCAD network app should not being using link-local. The ones people use who use networks and computers to run their business and most users dont see the standard apps anymore except net admins. Go say FTP or DNS to your private accountant, lawyer, or doctors office they will look at us like we have two heads. /jim > -----Original Message----- > From: itojun@iijlab.net [mailto:itojun@iijlab.net] > Sent: Friday, June 07, 2002 1:10 PM > To: Keith Moore > Cc: R.P. Aditya; ipng@sunroof.eng.sun.com > Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols > > > >> For link-local addresses, as long as the scope is > >> well-defined, what are your objections? > >for the most part, they're only a problem if you try to use > >them in applications (where zero-configuration appliances > >are an important subset of applications) > >part of the problem is that the scope of link-local addresses > >is *not* well-defined from an application's point of view, > >since applications in general don't know, and shouldn't have > >to know, about network topology. > > as long as the applications are properly implemented > with sockaddrs, > they are okay. the problem reside in protocols that pass IPv6 > addresses in payloads (since view of the scope is > different by nodes), > including: > - FTP (EPSV/EPRT does not help - for instance, how do you decide > the scope zone for data connection?) > - DNS (AAAA/PTR does not represent scope correctly) > - and all NAT-unfriendly protocols > > I'm okay to see site-local IPv6 address to go away, however, I'm > worried because there are more than a couple of > protocols designed with > site-local IPv6 address in mind (DHCPv6, router > renumbering, ...). > > we need to keep link-local IPv6 address at least for > ND. use of > link-locals within zeroconf environment needs further study. > > 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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 13 12:05:28 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DJ5Qk7028170; Thu, 13 Jun 2002 12:05:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5DJ5QN6028169; Thu, 13 Jun 2002 12:05:26 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DJ5Ok7028161 for ; Thu, 13 Jun 2002 12:05:24 -0700 (PDT) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g5DJ5LoR004923 for ; Thu, 13 Jun 2002 12:05:21 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g5DJ5LMx004922 for ipng@sunroof.eng.sun.com; Thu, 13 Jun 2002 12:05:21 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DCf0k7024872 for ; Thu, 13 Jun 2002 05:41:00 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA10632 for ; Thu, 13 Jun 2002 05:41:05 -0700 (PDT) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA12826 for ; Thu, 13 Jun 2002 05:41:04 -0700 (PDT) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 3A6388C53; Thu, 13 Jun 2002 08:41:04 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 13 Jun 2002 08:41:04 -0400 x-mimeole: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols Date: Thu, 13 Jun 2002 08:41:03 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B8A09@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Fwd: IPv6 Scoped Addresses and Routing Protocols Thread-Index: AcIOR2HnhUp/eh9DS1e2a/T8ds8rEQEkAWBg From: "Bound, Jim" To: "Ralph Droms" , Cc: "Keith Moore" , "R.P. Aditya" , X-OriginalArrivalTime: 13 Jun 2002 12:41:04.0107 (UTC) FILETIME=[94A783B0:01C212D7] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5DCf1k7024873 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk link-locals should live. site-local in this case can be multicast limited by scope that would be similar to site-local. that is neeeded for multicast and the scope is better than the IPv6 TTL use. But we don't need unicast site-locals is what I support. /jim > -----Original Message----- > From: Ralph Droms [mailto:rdroms@cisco.com] > Sent: Friday, June 07, 2002 1:15 PM > To: itojun@iijlab.net > Cc: Keith Moore; R.P. Aditya; ipng@sunroof.eng.sun.com > Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols > > > DHCPv6 currently uses a site-scoped multicast address as the > default for > forwarding messages from a relay agent to servers. The relay > agent can be > configured with a list of unicast addresses for servers > instead of using > the site-scoped multicast address. > > DHCPv6 also depends on link-local addresses for communication > between the > client and the on-link relay agent. > > - Ralph > > On Sat, 8 Jun 2002 itojun@iijlab.net wrote: > > > >> For link-local addresses, as long as the scope is > > >> well-defined, what are your objections? > > >for the most part, they're only a problem if you try to use > > >them in applications (where zero-configuration appliances > > >are an important subset of applications) > > >part of the problem is that the scope of link-local addresses > > >is *not* well-defined from an application's point of view, > > >since applications in general don't know, and shouldn't have > > >to know, about network topology. > > > > as long as the applications are properly implemented > with sockaddrs, > > they are okay. the problem reside in protocols that pass IPv6 > > addresses in payloads (since view of the scope is > different by nodes), > > including: > > - FTP (EPSV/EPRT does not help - for instance, how do you decide > > the scope zone for data connection?) > > - DNS (AAAA/PTR does not represent scope correctly) > > - and all NAT-unfriendly protocols > > > > I'm okay to see site-local IPv6 address to go away, however, I'm > > worried because there are more than a couple of > protocols designed with > > site-local IPv6 address in mind (DHCPv6, router > renumbering, ...). > > > > we need to keep link-local IPv6 address at least for ND. use of > > link-locals within zeroconf environment needs further study. > > > > 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 > > -------------------------------------------------------------------- > > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Jun 13 12:05:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DJ5ck7028183; Thu, 13 Jun 2002 12:05:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5DJ5cuF028182; Thu, 13 Jun 2002 12:05:38 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DJ5ak7028175 for ; Thu, 13 Jun 2002 12:05:36 -0700 (PDT) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g5DJ5XoR004931 for ; Thu, 13 Jun 2002 12:05:33 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g5DJ5XRk004930 for ipng@sunroof.eng.sun.com; Thu, 13 Jun 2002 12:05:33 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DCfgk7024894 for ; Thu, 13 Jun 2002 05:41:42 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA10751 for ; Thu, 13 Jun 2002 05:41:47 -0700 (PDT) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA13780 for ; Thu, 13 Jun 2002 06:43:32 -0600 (MDT) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 842AB3AE8; Thu, 13 Jun 2002 08:41:46 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 13 Jun 2002 08:41:46 -0400 x-mimeole: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols Date: Thu, 13 Jun 2002 08:41:46 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B8A0A@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Fwd: IPv6 Scoped Addresses and Routing Protocols Thread-Index: AcIOR/U27fAAKfMLSSyu7fCBjgYR8wEj6jXA From: "Bound, Jim" To: "Keith Moore" , Cc: "R.P. Aditya" , X-OriginalArrivalTime: 13 Jun 2002 12:41:46.0494 (UTC) FILETIME=[ADEB41E0:01C212D7] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5DCfhk7024895 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ack to keith. we had to hack this in to apis. be nice if it left the api too. /jim > -----Original Message----- > From: Keith Moore [mailto:moore@cs.utk.edu] > Sent: Friday, June 07, 2002 1:17 PM > To: itojun@iijlab.net > Cc: Keith Moore; R.P. Aditya; ipng@sunroof.eng.sun.com > Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols > > > > >for the most part, they're only a problem if you try to use > > >them in applications (where zero-configuration appliances > > >are an important subset of applications) > > >part of the problem is that the scope of link-local addresses > > >is *not* well-defined from an application's point of view, > > >since applications in general don't know, and shouldn't have > > >to know, about network topology. > > > > as long as the applications are properly > implemented with sockaddrs, > > they are okay. > > sockaddrs do not solve the problem of applications having to > figure out how > to reach a peer application in the absence of any knowledge > about network > topology. the source-selection rule isn't sufficient either. > > > the problem reside in protocols that pass IPv6 > > addresses in payloads (since view of the scope is > different by nodes), > > including: > > it's entirely appropriate for applications to pass addresses > in payloads, > and it's essential functionality for many kinds of applications > (distributed apps in particluar). > > for better or worse, the internet does not have a > location-independent namespace > that is reliable and useful for doing referrals to peer > processes. and nobody > has demonstrated an effective way to retrofit one into the > current architecture. > > > we need to keep link-local IPv6 address at least > for ND. use of > > link-locals within zeroconf environment needs further study. > > we agree about that much. but they think they're ready for > standards-track. > > Keith > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 13 12:06:12 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DJ6Ak7028203; Thu, 13 Jun 2002 12:06:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5DJ6ADu028202; Thu, 13 Jun 2002 12:06:10 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DJ66k7028195 for ; Thu, 13 Jun 2002 12:06:06 -0700 (PDT) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g5DJ63oR004947 for ; Thu, 13 Jun 2002 12:06:03 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g5DJ63N0004946 for ipng@sunroof.eng.sun.com; Thu, 13 Jun 2002 12:06:03 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DClkk7024944 for ; Thu, 13 Jun 2002 05:47:46 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA12016 for ; Thu, 13 Jun 2002 05:47:51 -0700 (PDT) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA02330 for ; Thu, 13 Jun 2002 05:47:51 -0700 (PDT) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 445CFA5ED; Thu, 13 Jun 2002 08:47:50 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 13 Jun 2002 08:47:50 -0400 x-mimeole: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols Date: Thu, 13 Jun 2002 08:47:49 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B8A0C@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Fwd: IPv6 Scoped Addresses and Routing Protocols Thread-Index: AcIOfRN+y4xtk9PHTVuKh9jceogLnwEWz/2Q From: "Bound, Jim" To: , "Michel Py" Cc: "Bob Hinden" , "Steven M. Bellovin" , X-OriginalArrivalTime: 13 Jun 2002 12:47:50.0150 (UTC) FILETIME=[86ACC260:01C212D8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5DCllk7024945 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk and this is my biggest fear for the Internet with IPv6. These site-locals could undo all we did with IPv6 to restore end-to-end architecture for the Internet. Trying to limit them with words or BCPs whatever will NOT prevent the potential tragedy to our beloved Internet as Bill points out below. /jim > -----Original Message----- > From: Bill Sommerfeld [mailto:sommerfeld@east.sun.com] > Sent: Friday, June 07, 2002 7:41 PM > To: Michel Py > Cc: Bob Hinden; Steven M. Bellovin; ipng@sunroof.eng.sun.com > Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols > > > > The outbound-only firewall is a false idea of security as well since > > 2nd generation peer-to-peer software such as Morpheus can easily > > bypass firewalls and allow ingress connections to RFC1918 hosts. > > > > On the other hand, considering that a typical IPv6 will > _not_ feature > > IPv6 NAT, an IPv6 host that has _only_ a site-local address > would have > > an extra layer of protection against external attacks as it > would not be > > reachable at all from the outside. > > I see this as a distinction without a difference -- if the site has > some systems running a global p2p network's software with external > connectivity, and that p2p network is cracked, the site will be > vulnerable to attacks relayed through the p2p network. > > if one system within the site has external connectivity and is part of > the compromised p2p network, any system at the site will now be open > to attacks from the compromised system. > > If there is widespread deployment of systems with site-local only > addresses, this will in turn drive the creation of ipv6 NAT > specifically to give them external connectivity.. > > - 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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 13 12:05:53 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DJ5qk7028193; Thu, 13 Jun 2002 12:05:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5DJ5p8w028192; Thu, 13 Jun 2002 12:05:51 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DJ5nk7028185 for ; Thu, 13 Jun 2002 12:05:49 -0700 (PDT) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g5DJ5koR004939 for ; Thu, 13 Jun 2002 12:05:46 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g5DJ5kkU004938 for ipng@sunroof.eng.sun.com; Thu, 13 Jun 2002 12:05:46 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DCjgk7024913 for ; Thu, 13 Jun 2002 05:45:42 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA06634 for ; Thu, 13 Jun 2002 05:45:47 -0700 (PDT) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA14883 for ; Thu, 13 Jun 2002 05:45:46 -0700 (PDT) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id B8F2E5875; Thu, 13 Jun 2002 08:45:44 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 13 Jun 2002 08:45:44 -0400 x-mimeole: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols Date: Thu, 13 Jun 2002 08:45:44 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B8A0B@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Fwd: IPv6 Scoped Addresses and Routing Protocols Thread-Index: AcIOdwuB7UwLloCLS36eYNQGPXuahwEYM6vw From: "Bound, Jim" To: "Bob Hinden" , "Steven M. Bellovin" Cc: X-OriginalArrivalTime: 13 Jun 2002 12:45:44.0637 (UTC) FILETIME=[3BDCFED0:01C212D8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5DCjgk7024914 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bob, As one who has worked with you a long time and always fight to not break existing implementations in this case I don't find your (and mine to some degree) abstracts for site-local compelling enough. I think they are very bad and evil for the Internet too and more importantly private enterprise. The code changes for this are quite minimal too. API tweek which can be done in follow releases, and the base IP stack has not evolved for scoping and now routing exists with this feature. I think we should kill these now. /jim > -----Original Message----- > From: Bob Hinden [mailto:hinden@iprg.nokia.com] > Sent: Friday, June 07, 2002 6:57 PM > To: Steven M. Bellovin > Cc: ipng@sunroof.eng.sun.com > Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols > > > Steve, > > Thanks for raising this issue on the list. I think it has > been lurking for > a while. > > (with no hat on) > > Here is my personal explanation about why site-local > addresses exist. My > intent of the email is to not take a strong position on either side. > > I think the important question is the one at the end of your email: > > >Finally -- and perhaps least important -- I'm not sure what problem > >they solve. I can understand site-local multicast, since (most) > >inter-site traffic traverses links that are not inherently > >multicast-capable. There is thus considerable extra > expense. But why > >do I need site-local unicast addresses? > > It may be the most important question, not the least important :-) > > One of the original reasons for site-local unicast addresses > was for sites > that were not connected to the Internet (and didn't have any global > addresses). They would allow IPv6 be used inside the site > initially. Later when the site become connected to the > Internet it would > be easy to renumber to a global prefix because the subnet part of the > addresses (/48 in current assignment practice) could be > reused without any > site subnet renumbering. This usage of site-local unicast > may still have > some value and avoids some of the complexity of using a > mixture of global > and site-local addresses. > > Later as many people came to belive that private addresses > (and NAT) in > IPv4 provide a security mechanism, Site-local addresses were > looked on as > filling that role in IPv6. I understand that the belief that private > addresses provide security is faulty and has many nasty > consequences, but > many people do believe it. I think this has evolved to where > there is a > view that using site-local unicast addresses for services > that need to be > restricted to the site is a good thing. I think there is > some value here, > but am not sure if it's benefits justify it's costs. I think > there are a > range of opinions here. > > All of the issues you point out about site-local regarding > DNS and routers > are real. However with the widespread use of IPv4 private > addresses in the > internet, that vendors have leaned how to deal with addressing domain > issues. I don't think the IETF has done very much to > "standardize" this > usage (probably a good thing). I think most vendors building these > products know how to deal with the issues and users have > learned how to > configure the products to solve their problem. The vendors built it > because their customers wanted it. It is all very ugly and > nasty. It is > hard to set up and even harder to debug problems. Perhaps > even as you say > "an administrative and technical nightmare". But as far as I > can tell it > does exist. If vendors are going to build products that want to use > site-local, then it might be best for the IETF to at least > document it's > usage to allow for interoperability. > > (with my IPv6 co-chair hat on) > > I think the w.g. has some choices to make regarding > site-local addresses. > > 1) Remove site-local from the IPv6. > > This would involve remove it from the IPv6 addressing > documents and find > all other documents that mention them and update these. Some > of these may > require significant modification if use site-local as a basic > part of their > mechanisms. There will also be an impact to shipping IPv6 > implementations. This would have to be sorted out. A good > understanding > of what different vendors plan here would be useful. > > 2) Keep site-local but limit it's scope of usage. > > This would be something like writing an applicability > document that defines > it usage and for example restricts it use to sites not > connected to the > Internet. Other usage would be for future study. This would > be consistent > with most of the current specifications. It would make > completing the > scoped address architecture document simpler. There might be other > specifications to update if they were using site-local and > didn't have any > provision to move to global addresses. > > 3) Keep site-local and allow full usage > > This would mean fully specifying how to use site-local, > documenting the > router and DNS issues, completing the scoped addressing architecture > document, perhaps enhancing IPv6 routing protocols to have > more knowledge > of site-local addresses, etc. > > The working group has been going down 3) for some time now. > I think your > email is a good start at seeing if should continue in this > direction or > change course. > > 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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 13 12:06:51 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DJ6ok7028242; Thu, 13 Jun 2002 12:06:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5DJ6nxl028241; Thu, 13 Jun 2002 12:06:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DJ6ik7028234 for ; Thu, 13 Jun 2002 12:06:44 -0700 (PDT) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g5DJ6goR004963 for ; Thu, 13 Jun 2002 12:06:42 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g5DJ6fU4004962 for ipng@sunroof.eng.sun.com; Thu, 13 Jun 2002 12:06:41 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DCoDk7025003 for ; Thu, 13 Jun 2002 05:50:13 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA07451 for ; Thu, 13 Jun 2002 05:50:18 -0700 (PDT) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA03381 for ; Thu, 13 Jun 2002 05:50:18 -0700 (PDT) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id D0927292E; Thu, 13 Jun 2002 08:50:17 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 13 Jun 2002 08:50:17 -0400 x-mimeole: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols Date: Thu, 13 Jun 2002 08:50:17 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B8A0E@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Fwd: IPv6 Scoped Addresses and Routing Protocols Thread-Index: AcIO1mcd7UkJjTTcTu+/UkwctsQnxQEAmG0Q From: "Bound, Jim" To: "Pekka Savola" , "Michel Py" Cc: , "Bob Hinden" , "Steven M. Bellovin" , X-OriginalArrivalTime: 13 Jun 2002 12:50:17.0697 (UTC) FILETIME=[DE9EA510:01C212D8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5DCoEk7025004 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I don't do warm and fuzzy in the IETF. I am an engineer and architect. I don't think this mail is even constructive below. /jim > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Saturday, June 08, 2002 6:20 AM > To: Michel Py > Cc: sommerfeld@east.sun.com; Bob Hinden; Steven M. Bellovin; > ipng@sunroof.eng.sun.com > Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols > > > On Fri, 7 Jun 2002, Michel Py wrote: > > > If there is widespread deployment of systems with site-local only > > > addresses, this will in turn drive the creation of ipv6 NAT > > > specifically to give them external connectivity.. > > > > That looks like a solution without a problem. To give these hosts > > connectivity you just have both the site-local and the > global address. > > Since NAT would not bring anything to the table why > implement it in the > > first place? > > To give folks that think IPv4 private addresses provide security > (especially wrt. incoming connections) a smooth transition > path to IPv6 > and "warm fuzzy feeling". > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 13 12:06:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DJ6bk7028228; Thu, 13 Jun 2002 12:06:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5DJ6a7k028225; Thu, 13 Jun 2002 12:06:36 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DJ6Xk7028218 for ; Thu, 13 Jun 2002 12:06:33 -0700 (PDT) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g5DJ6UoR004955 for ; Thu, 13 Jun 2002 12:06:30 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g5DJ6UCf004954 for ipng@sunroof.eng.sun.com; Thu, 13 Jun 2002 12:06:30 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DCnNk7024985 for ; Thu, 13 Jun 2002 05:49:23 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA07283 for ; Thu, 13 Jun 2002 05:49:28 -0700 (PDT) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA16490 for ; Thu, 13 Jun 2002 05:49:28 -0700 (PDT) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id A0F143B87; Thu, 13 Jun 2002 08:49:27 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 13 Jun 2002 08:49:27 -0400 x-mimeole: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols Date: Thu, 13 Jun 2002 08:49:27 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B8A0D@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Fwd: IPv6 Scoped Addresses and Routing Protocols Thread-Index: AcIOfNNyO4kB2pxQT3SUtDj3Ej1M7AAFzbMAAREhZkA= From: "Bound, Jim" To: "Michel Py" , Cc: "Bob Hinden" , "Steven M. Bellovin" , X-OriginalArrivalTime: 13 Jun 2002 12:49:27.0603 (UTC) FILETIME=[C0C2E830:01C212D8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5DCnNk7024986 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Michel, Your view of planet could be the IPv4 NAT view and with true e2e with IPsec, TLS, and many others those security interrupts and gateways that see my conversations on the net will go away. So I don't like the way the planet is and we should change it. /jim > -----Original Message----- > From: Michel Py [mailto:michel@arneill-py.sacramento.ca.us] > Sent: Friday, June 07, 2002 10:32 PM > To: sommerfeld@east.sun.com > Cc: Bob Hinden; Steven M. Bellovin; ipng@sunroof.eng.sun.com > Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols > > > >> Michel Py wrote: > >> On the other hand, considering that a typical IPv6 will > _not_ feature > >> IPv6 NAT, an IPv6 host that has _only_ a site-local address would > have > >> an extra layer of protection against external attacks as > it would not > be > >> reachable at all from the outside. > > > Bill Sommerfeld wrote: > > I see this as a distinction without a difference -- if the site has > > some systems running a global p2p network's software with external > > connectivity, and that p2p network is cracked, the site will be > > vulnerable to attacks relayed through the p2p network. > > if one system within the site has external connectivity and is part > > of the compromised p2p network, any system at the site will now be > > open to attacks from the compromised system. > > I don't know on which planet you are living, but on earth a > system that > has no direct access to the outside is more secure than a system that > does; this is called a fact, not a distinction. Security is the sum of > different things, including passwords, firewalls _and_ > preventing direct > access from the Internet. > > > > If there is widespread deployment of systems with site-local only > > addresses, this will in turn drive the creation of ipv6 NAT > > specifically to give them external connectivity.. > > That looks like a solution without a problem. To give these hosts > connectivity you just have both the site-local and the global address. > Since NAT would not bring anything to the table why implement > it in the > first place? > > Michel. > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Jun 13 12:07:04 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DJ72k7028255; Thu, 13 Jun 2002 12:07:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5DJ72hX028254; Thu, 13 Jun 2002 12:07:02 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DJ6wk7028244 for ; Thu, 13 Jun 2002 12:06:58 -0700 (PDT) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g5DJ6toR004971 for ; Thu, 13 Jun 2002 12:06:55 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g5DJ6td9004970 for ipng@sunroof.eng.sun.com; Thu, 13 Jun 2002 12:06:55 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DCpRk7025014 for ; Thu, 13 Jun 2002 05:51:27 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA07544 for ; Thu, 13 Jun 2002 05:51:31 -0700 (PDT) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA02744 for ; Thu, 13 Jun 2002 06:51:31 -0600 (MDT) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 4BFA3398C; Thu, 13 Jun 2002 08:51:30 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 13 Jun 2002 08:51:30 -0400 x-mimeole: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Securing Neighbor Discovery BOF Date: Thu, 13 Jun 2002 08:51:29 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B8A0F@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Securing Neighbor Discovery BOF Thread-Index: AcIPgbxSoKM4CZh7SteCrSTGfrS1MwDVz2SA From: "Bound, Jim" To: "James Kempf" , "Pekka Savola" Cc: X-OriginalArrivalTime: 13 Jun 2002 12:51:30.0244 (UTC) FILETIME=[09DC7040:01C212D9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5DCpRk7025015 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk the market will solve the keying problem James while the IETF is still working on it :--) /jim > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Sunday, June 09, 2002 2:41 AM > To: Pekka Savola > Cc: ipng@sunroof.eng.sun.com > Subject: Re: Securing Neighbor Discovery BOF > > > Pekka, > > We will shortly be releasing the ABK draft with a statement like the > Photuris statement, which was included in IKE. > > Also, some people believe that IPsec will work. If some way > can be found > around the keying problem, it could be a viable alternative. > > jak > > ----- Original Message ----- > From: "Pekka Savola" > To: "James Kempf" > Cc: > Sent: Friday, June 07, 2002 1:51 AM > Subject: Re: Securing Neighbor Discovery BOF > > > > On Fri, 7 Jun 2002, James Kempf wrote: > > > On Tues. afternoon of IETF 54 13:00-14:00, there will be > a BOF held > to > > > discuss securing Neighbor Discovery. The BOF description, > along with > a > > > suggested reading list, will appear when the agenda is > posted on the > > > IETF 54 Web page. If you are interested in this problem, please > attend. > > > If you would like to speak, please send email to me or Pekka > Nikkander > > > (Pekka.Nikander@nomadiclab.com). > > > > Are there any non-encumbered technologies to Secure ND? > > > > Thought so... > > > > -- > > Pekka Savola "Tell me of difficulties surmounted, > > Netcore Oy not those you stumble over and fall" > > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 13 12:07:21 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DJ7Kk7028281; Thu, 13 Jun 2002 12:07:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5DJ7JkX028280; Thu, 13 Jun 2002 12:07:19 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DJ7Dk7028264 for ; Thu, 13 Jun 2002 12:07:13 -0700 (PDT) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g5DJ7AoR004979 for ; Thu, 13 Jun 2002 12:07:10 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g5DJ7A87004978 for ipng@sunroof.eng.sun.com; Thu, 13 Jun 2002 12:07:10 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DCrmk7025064 for ; Thu, 13 Jun 2002 05:53:48 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA13384 for ; Thu, 13 Jun 2002 05:53:53 -0700 (PDT) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA03637 for ; Thu, 13 Jun 2002 06:53:52 -0600 (MDT) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 4F1ED488E; Thu, 13 Jun 2002 08:53:51 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 13 Jun 2002 08:53:49 -0400 x-mimeole: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols Date: Thu, 13 Jun 2002 08:53:49 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B8A10@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Fwd: IPv6 Scoped Addresses and Routing Protocols Thread-Index: AcIPwJZoU3i7L0/YSCWofgIVK7NLPwDGJbVw From: "Bound, Jim" To: "Steven M. Bellovin" , "Pekka Savola" Cc: "Ralph Droms" , X-OriginalArrivalTime: 13 Jun 2002 12:53:49.0805 (UTC) FILETIME=[5D0BC1D0:01C212D9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5DCrmk7025065 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk with all due respect. rfc 1918 was a hack and never would pass the IESG today IMO they are doing a far better job these days causing us to detail our network views and development of protocols. 1918 has wrecked the Internet. /jim > -----Original Message----- > From: Steven M. Bellovin [mailto:smb@research.att.com] > Sent: Sunday, June 09, 2002 10:17 AM > To: Pekka Savola > Cc: Ralph Droms; ipng@sunroof.eng.sun.com > Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols > > > In message > , Pekka Savola > writes: > >On Sun, 9 Jun 2002, Ralph Droms wrote: > >> problem. A router can't know when it's forwarding a > packet outside of a > >> site unless it's been configured with information about > site borders. So > >> network architects and admins have to define what makes up > sites and > >> configure the routers at the borders to know about those site > >> borders. And, I don't think there's a good way to define > default behavior > >> or auto-discovery for site-local addressing... > > > >Precisely. > > Yup -- and now we're elevating it to an architectural principle. > > > >> I don't see much difference between RFC 1918 addresses and > site-local > >> addresses in the areas of network design and deployment... > > > >Me neither. More probable outcome is that someone starts to > request that > >people implement NATv6, because 1) they're already used to > it (and like > >its "security") in v4 world, and 2) they think it's easier > for them to do > >NAT than to renumber. > > > >Site-locals were born in the era that not all sites had internet > >connectivity. Now that assumption is not all that valid > anymore. It's > >just easier for people to use a global address block (even > if we define > >that address block to be 3ffe:eff3::/32 or whatever) even with these > >"internal needs" (note: I believe there should be > _something_ that does > >not require you to fill any kind of paperwork). > > > > Yah. Let's pick a prefix, and tell folks to pick a random > number (more > precisely, use an RFC 1750-compatible RNG) to fill out the > rest of the > high-order bits to a /48 or a /64. We encourage ISPs to provide real > prefixes to companies that are using application-layer gateways, and > hence don't "need" a routable prefix. We promise two months of > connectivity to folks using non-conflicting random prefixes when they > connect, while they renumber. We think of other, creative solutions > that exploit the fact that we have a really large address space that > we're not going to exhaust. > > In short, that we do *something* that isn't going to cause long-term > architectural and operational pain. > > --Steve Bellovin, http://www.research.att.com/~smb (me) > http://www.wilyhacker.com ("Firewalls" book) > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Jun 13 12:07:29 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DJ7Sk7028294; Thu, 13 Jun 2002 12:07:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5DJ7RQ5028293; Thu, 13 Jun 2002 12:07:27 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DJ7Nk7028283 for ; Thu, 13 Jun 2002 12:07:23 -0700 (PDT) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g5DJ7KoR004987 for ; Thu, 13 Jun 2002 12:07:20 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g5DJ7KbS004986 for ipng@sunroof.eng.sun.com; Thu, 13 Jun 2002 12:07:20 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DCsfk7025078 for ; Thu, 13 Jun 2002 05:54:41 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA13570 for ; Thu, 13 Jun 2002 05:54:46 -0700 (PDT) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA19523 for ; Thu, 13 Jun 2002 06:56:31 -0600 (MDT) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 3933E2B26; Thu, 13 Jun 2002 08:54:45 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 13 Jun 2002 08:54:45 -0400 x-mimeole: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols Date: Thu, 13 Jun 2002 08:54:44 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B8A11@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Fwd: IPv6 Scoped Addresses and Routing Protocols Thread-Index: AcIPw05rH0TXLq8jQhSmIOnMIBNhmgDFh2YQ From: "Bound, Jim" To: "Brian Haberman" , "Margaret Wasserman" Cc: X-OriginalArrivalTime: 13 Jun 2002 12:54:45.0212 (UTC) FILETIME=[7E1231C0:01C212D9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5DCsfk7025079 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, It would not be significant to rip the site stuff out of the code as I see it. /jim > -----Original Message----- > From: Brian Haberman [mailto:bkhabs@nc.rr.com] > Sent: Sunday, June 09, 2002 10:33 AM > To: Margaret Wasserman > Cc: ipng@sunroof.eng.sun.com > Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols > > > Hi Margaret, > I suppose that I should admit to being remiss in this area. I > have done a fair amount of work in this area and just haven't had the > time to document routing protocol behavior changes to support site > local prefixes (even though I recall telling you I was going > to do it). > > Anyway, I will start by saying that I have modified RIPng to > correctly handle the advertisement of site-locals. In order to make > this efficient, I maintained the concept of a single instance of RIPng > running in the router. In order to understand the changes to the > routing protocol, you also have to understand the changes to the > RIB for site locals. So, how did I make it work? > > 1. The RIB now contains an additional field, the zone ID. I > have done this in two different ways. The first is to add > the zone ID as a separate field. The second is to embed > the zone ID in the "unused" portion of the site local > prefix. > > 2. RIPng was changed to build its route advertisement messages > on a per zone ID basis. That is, it starts with adding all > global prefixes to the message. It then adds site local > prefixes that are in the same zone ID as the interface that > the advertisement will be transmitted. It determines this > by extracting the zone ID from the outgoing interface and > using this find all site locals in the RIB with a matching > zone ID. > > 3. When RIPng receives a route advertisement from a peer, it > takes the zone ID from the receiving interface and using > that to add the site local prefixes to the RIB. > > That, in a nutshell, allows a single instance of RIPng to control > the advertising of site local unicast prefixes. Though I haven't > done the work, I would see OSPF as acting in a similar manner. > > If someone wants me to describe the actual forwarding, just let me > know. > > Regards, > Brian > > Margaret Wasserman wrote: > > > > I sent the attached message to the routing area discussion > list. I thought that people on > > the IPv6 list might be interested in this discussion, so I > will forward a message containing > > the responses after this one. I suppose I just should have > cc:ed the IPv6 group in the > > first place... > > > > Margaret > > > > >Date: Fri, 24 May 2002 12:17:04 -0400 > > >To: routing-discussion@ietf.org > > From: Margaret Wasserman > > >Subject: IPv6 Scoped Addresses and Routing Protocols > > > > > > > > > > > >Hi All, > > > > > >I raised some questions with Bill Fenner in Minneapolis > regarding IPv6 scoped > > >addressing and our current IPv6 routing protocol > specifications, and Bill suggested > > >that I should send my questions to this list for > discussion. So, here they are. > > > > > >First, some background... > > > > > >As many of you probably know, IPv6 includes the concept of > scoped unicast > > >addressing -- a unicast address can have link-local scope, > site-local scope > > >or global scope. The address scopes are defined in the > IPv6 Addressing > > >Architecture: > > > > > > >http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-addr-ar > ch-v3-07.txt > > > > > >Additional information can be found in the IPv6 Scoped Address > > >Architecture: > > > > > > >http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-scoping > -arch-03.txt > > > > > >I would suggest that all of you read the IPv6 Scoped > Address Architecture > > >document, if you haven't already, as it contains > information regarding > > >the expected configuration and forwarding behaviour of > IPv6 routers. > > >It also defines the concept of an IPv6 site, which is > important to understanding > > >the questions that I am about to raise. > > > > > >In IPv6, there is a concept of site-local addressing that > is quite different > > >from the concept of "net 10" addresses in IPv4. Sites are > administratively > > >defined entities that must be "convex" (i.e. the best > route between two nodes > > >in the site must, at all scopes, fall completely within > the site). Sites boundaries > > >run through routers, so a single router (called a site > border router (SBR)) can > > >have interfaces in more than one site. And, IPv6 > site-local addresses can be > > >used for site-constrained communication, even when a site > is globally > > >connected and global addresses are available. > > > > > >Because all site-local addresses use the same well-known > site-local prefix, the > > >only way to tell that a particular site-local address > belongs to a particular > > >site is to know which site originated the address. SBRs will need > > >to enforce site boundaries, not mixing site-local routing > information, and not > > >forwarding packets outside of a given site. To do this, > it is expected that > > >SBRs will need to maintain multiple "conceptual routing > tables", including one > > >site-local routing table for each attached site, and one > global routing table. > > > > > >Unfortunately, I can't find any indication that these > concepts have been reflected > > >in the current IPv6 routing protocols. None of our IPv6 > routing protocol documents > > >deal with site-local boundaries or SBR behaviour explicitly. > > > > > >There are currently four standards for how IPv6 routes > will be handled in BGP, OSPF, > > >IS-IS and RIP. I will refer to these documents as > BGP-IPv6, OSPF-IPv6 and IS-IS-IPv6, > > >and RIP-IPv6 respectively: > > > > > >Use of BGP-4 Multiprotocol Extensions for IPv6 > Inter-Domain Routing: > > >http://www.ietf.org/rfc/rfc2545.txt > > > > > >OSPF for IPv6 > > >http://www.ietf.org/rfc/rfc2740.txt > > > > > >Routing IPv6 with IS-IS: > > >http://www.ietf.org/internet-drafts/draft-ietf-isis-ipv6-02.txt > > > > > >RIPng for IPv6 > > >http://www.ietf.org/rfc/rfc2080.txt > > > > > >So here are my actual questions: > > > > > >(1) Are the statements regarding the routing system in the > IPv6 Scoped Addressing Architecture > > >draft valid? Will they work in real life? Please read > it, and comment to the IPv6 WG if you think that > > >there are any issues with what it says. > > > > > >(2) BGP-IPv6: > > > > > >BGP-IPv6 states: "As this document makes no assumption on > the characteristics of a particular > > >routing realm where BGP-4 is used, it makes no distinction > between global and site-local addresses > > >and refers to both as "global" or "non-link-local"." > > > > > >Would it ever be reasonable for BGP to propagate > site-local routing information? Why, under > > >what circumstances? Would it be reasonable to assume that > an Inter-Domain Routing protocol > > >shouldn't propagate site-local information at all? > > > > > >If BGP should be capable of propagating site-local > information, will it be possible, using existing > > >BGP standards for a BGP SBR router with four interfaces > (A, B, C & D), in two sites (A & B in S1, > > >and C & D in S2) to maintain two separate sets of > information for prefix FEC0::/10, one that applies > > >to S1 (interfaces A & B) and one that applies to S2 > (interfaces C & D), and to propagate that information > > >accordingly? Is this really just an issue of configuring > the router properly, as BGP-IPv6 implies? > > > > > >(3) OSPF-IPV6: > > > > > >In this specification, no distinction is made between > site-local and global addresses. Unlike the > > >previous specification (BGP-IPv6), this assumption is not > stated up-front. Instead, everywhere in > > >the draft where either site-local or global addresses are > mentioned they are both mentioned (i.e. > > >"site-local or global IPv6 addresses"). > > > > > >Again this specification makes no provision for separate > sets of site local information. There is > > >also no mention of a boundary for site-local route > propagation, and no mention of multiple conceptual > > >sets of site-local routing information. Would it make > sense to tie the concept of an IPv6 site to > > >one of the existing propagation boundaries in OSPF, such > as an OSPF area? Or to assume that > > >an OSPF AS will always be completely contained within one > site -- which is what the current draft > > >seems to assume? > > > > > >(4) IS-IS-IPv6: > > > > > >IS-IS-IPv6 makes no mention of site-local or scoped > addressing at all. Is this appropriate? How will IS-IS > > >SBRs know not to propagate site-local routing information > between two attached sites? I don't yet > > >know enough about IS-IS to understand how site-local > routing information would best be handled > > >in IS-IS. Any thoughts? > > > > > >(5) RIP-IPv6: > > > > > >The RIP-IPv6 document explicitly states that there is a > single IPv6 routing table, and it makes no > > >mention of sites. I think it would be fine to constrain > RIP to operating within a single IPv6 > > >site, but that should be explicitly stated somewhere. > > > > > >(6) Will the MIBs for any of these routing tables be > capable of representing multiple independent, > > >possibly overlapping sets of site-local routing > information? I looked them over quickly, and it > > >wasn't immediately obvious to me how they could do this. > > > > > >(7) Do you think that there would be some utility to > defining the actual routing architecture (as > > >opposed to just the addressing architecture) for IPv6? If > so, what would be the best way to do > > >that? > > > > > >(8) Should we mention link-local addresses anywhere in > these specifications? We certainly would > > >not want to propagate routing information for link-local addresses. > > > > > >If there is some work that needs to be done here, I am > very happy to provide some IPv6 expertise > > >to that effort. > > > > > >Margaret > > > > > > > > > > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Jun 13 12:07:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DJ7hk7028310; Thu, 13 Jun 2002 12:07:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5DJ7hQ0028309; Thu, 13 Jun 2002 12:07:43 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DJ7Zk7028299 for ; Thu, 13 Jun 2002 12:07:36 -0700 (PDT) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g5DJ7WoR004995 for ; Thu, 13 Jun 2002 12:07:32 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g5DJ7WpR004994 for ipng@sunroof.eng.sun.com; Thu, 13 Jun 2002 12:07:32 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DCutk7025089 for ; Thu, 13 Jun 2002 05:56:55 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA14219 for ; Thu, 13 Jun 2002 05:57:00 -0700 (PDT) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA20520 for ; Thu, 13 Jun 2002 06:58:45 -0600 (MDT) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 5146D4374; Thu, 13 Jun 2002 08:56:59 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 13 Jun 2002 08:56:59 -0400 x-mimeole: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols Date: Thu, 13 Jun 2002 08:56:58 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B8A12@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Fwd: IPv6 Scoped Addresses and Routing Protocols Thread-Index: AcIQEKfiYTyOJlw8TTyuTTuBc82EFQCyQl5w From: "Bound, Jim" To: , "Tony Hain" Cc: "Steven M. Bellovin" , "Pekka Savola" , "Ralph Droms" , X-OriginalArrivalTime: 13 Jun 2002 12:56:59.0306 (UTC) FILETIME=[CDFF50A0:01C212D9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5DCutk7025090 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk None that I am aware of? Putting SLs in DNS is the two-face problem and at least the BIND code don't deal with this yet. And I don't think it should ever do this IMO. /jim > -----Original Message----- > From: Allison Mankin [mailto:mankin@isi.edu] > Sent: Sunday, June 09, 2002 7:50 PM > To: Tony Hain > Cc: Steven M. Bellovin; Pekka Savola; Ralph Droms; > ipng@sunroof.eng.sun.com > Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols > > > > and the > > only reason a DNS server should return an SL address is if > the query was > > addressed to its SL address. Maybe this needs to be stated > clearly in > > the ngtrans doc on DNS issues, but this should be obvious from the > > perspective of 'don't return an answer that can't be used'. > > I would question whether this is well-understood and DNS servers > are ready to select which AAAA records to reply with depending > on the address the query was sent to. Do current servers implement > this, including caching servers? > > Allison > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Jun 13 12:08:03 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DJ81k7028334; Thu, 13 Jun 2002 12:08:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5DJ81uv028333; Thu, 13 Jun 2002 12:08:01 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DJ7vk7028326 for ; Thu, 13 Jun 2002 12:07:57 -0700 (PDT) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g5DJ7soR005011 for ; Thu, 13 Jun 2002 12:07:54 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g5DJ7sMi005010 for ipng@sunroof.eng.sun.com; Thu, 13 Jun 2002 12:07:54 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DD4Uk7025123 for ; Thu, 13 Jun 2002 06:04:30 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA16181 for ; Thu, 13 Jun 2002 06:04:35 -0700 (PDT) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA08512 for ; Thu, 13 Jun 2002 07:04:34 -0600 (MDT) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 5B47A691; Thu, 13 Jun 2002 09:04:34 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 13 Jun 2002 09:04:34 -0400 x-mimeole: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols Date: Thu, 13 Jun 2002 09:04:33 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B8A14@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Fwd: IPv6 Scoped Addresses and Routing Protocols Thread-Index: AcIQb0UId0YKB0eiR7GoY3BQZnGx4wCayAMw From: "Bound, Jim" To: "Randy Bush" , "Francis Dupont" Cc: "Steven M. Bellovin" , X-OriginalArrivalTime: 13 Jun 2002 13:04:34.0166 (UTC) FILETIME=[DD1D7160:01C212DA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5DD4Vk7025124 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk randy, I know how this must work and its even more horrifying than you might imagine. What you have to do in a nutshell is add tons of context and management to the implementation to note the boundaries and then the sub-boundaries as you can have in the future org-scope, or dept-scope and on and on. Its insane to keep this in the architecture. And NO ONE has it working and the code to be removed is insignificant. As Jinmei pointed out with the API as one example. yes we have to manage more state with anycast but that is minimal and well defined. that is good and ok. Also this is not the case for link-local. The reason is that the links are hardwired in the implementation and treating them as zones works for links. But sites are "virtual". The entire use of them is bogus IMO. /jim > -----Original Message----- > From: Randy Bush [mailto:randy@psg.com] > Sent: Monday, June 10, 2002 7:07 AM > To: Francis Dupont > Cc: Steven M. Bellovin; ipng@sunroof.eng.sun.com > Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols > > > >> But as site is rather vaguely defined, I think many > vendors just skip > >> this little detail.. > > I disagree: we have a similar but more complex issue for multicast > > forwarding and the zone boundary check is very easy to implement > > cool. how do you detect that you are at the edge of a site? > > randy > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Jun 13 12:08:07 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DJ85k7028337; Thu, 13 Jun 2002 12:08:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5DJ85XS028336; Thu, 13 Jun 2002 12:08:05 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DJ7kk7028312 for ; Thu, 13 Jun 2002 12:07:46 -0700 (PDT) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g5DJ7hoR005003 for ; Thu, 13 Jun 2002 12:07:43 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g5DJ7hpu005002 for ipng@sunroof.eng.sun.com; Thu, 13 Jun 2002 12:07:43 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DCxuk7025105 for ; Thu, 13 Jun 2002 05:59:56 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA08775 for ; Thu, 13 Jun 2002 06:00:00 -0700 (PDT) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA21029 for ; Thu, 13 Jun 2002 06:59:59 -0600 (MDT) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 021A16B20; Thu, 13 Jun 2002 08:59:59 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 13 Jun 2002 08:59:58 -0400 x-mimeole: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols Date: Thu, 13 Jun 2002 08:59:58 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B8A13@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Fwd: IPv6 Scoped Addresses and Routing Protocols Thread-Index: AcIQS8T6GUY/Z7JIRHSdzOa2FSBGHACjidsQ From: "Bound, Jim" To: "JINMEI Tatuya / ????" , "Margaret Wasserman" Cc: "Brian Haberman" , X-OriginalArrivalTime: 13 Jun 2002 12:59:58.0928 (UTC) FILETIME=[390F7500:01C212DA] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Exactly. The entire IPv6 code base would be reduced in size and more importantly the decision constructs and data struct lookups which is a big win. Lets face it site-locals are very painful for real development currently and in the long run will produce more bugs in all our products (handhelds, servers, routers, clients) and adds another degree of complexity to all our IETF protocols like SCTP. Lets kill them.:--) /jim > -----Original Message----- > From: jinmei@isl.rdc.toshiba.co.jp > [mailto:jinmei@isl.rdc.toshiba.co.jp] > Sent: Monday, June 10, 2002 2:53 AM > To: Margaret Wasserman > Cc: Brian Haberman; ipng@sunroof.eng.sun.com > Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols > > > >>>>> On Sun, 09 Jun 2002 18:56:11 -0400, > >>>>> Margaret Wasserman said: > > > I'm also concerned about the complexity that site-local addressing > > adds to an IPv6 host. Looking at the default address > selection rules, > > it appears that host implementations will be impacted by site-local > > addressing (implementation size and complexity), even in cases > > where it isn't really used. > > Regarding the default address selection rules, I don't think > site-local adds much stuff. We also need to handle link-local in the > selection rules, which could impact the host implementations enough. > > In fact, in our implementation of the address selection, there is only > few additional code that is specific to site-local. > > If the host implementation is *completely* unconscious of scoped > addresses (which would be the case for some "minimal" implementation), > it will be able to reduce much on the size and complexity. > > 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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 13 12:08:25 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DJ8Nk7028357; Thu, 13 Jun 2002 12:08:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5DJ8Mul028356; Thu, 13 Jun 2002 12:08:22 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DJ8Kk7028349 for ; Thu, 13 Jun 2002 12:08:20 -0700 (PDT) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g5DJ8HoR005027 for ; Thu, 13 Jun 2002 12:08:17 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g5DJ8HCf005026 for ipng@sunroof.eng.sun.com; Thu, 13 Jun 2002 12:08:17 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DDBak7025183 for ; Thu, 13 Jun 2002 06:11:36 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA10974 for ; Thu, 13 Jun 2002 06:11:41 -0700 (PDT) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA27372 for ; Thu, 13 Jun 2002 07:13:26 -0600 (MDT) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 7895CA65; Thu, 13 Jun 2002 09:11:40 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 13 Jun 2002 09:11:40 -0400 x-mimeole: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols Date: Thu, 13 Jun 2002 09:11:40 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B8A17@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Fwd: IPv6 Scoped Addresses and Routing Protocols Thread-Index: AcIQujNhE1kaR4UfSY+Vy4Ir3QtRgACITDUg From: "Bound, Jim" To: "Bill Fenner" , X-OriginalArrivalTime: 13 Jun 2002 13:11:40.0423 (UTC) FILETIME=[DB2F1970:01C212DB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5DDBak7025184 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Without managing protocols like icmp or mibs or something to use this then its still a virtual abstraction in the code that must be understoond. the room for error or isolating nodes incorrectly in a network design is very bad. In my role as consultant to several large deployers of IPv6 with mission critical networks where lives are at stake I strongly advise to not even use them. anycast as I said before is close to being a bad idea too but that maybe is workable. Read the latest architectural Internet doc by Bush et al. Lets keep it simple. site-locals IMO kill that Internet principle completely. Good diagram too. /jim > -----Original Message----- > From: Bill Fenner [mailto:fenner@research.att.com] > Sent: Monday, June 10, 2002 4:01 PM > To: ipng@sunroof.eng.sun.com > Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols > > > > An example that may be a little too contrived: > > H1 > | > |// > B-------A > / // \ > / | > | | > C D > | | > | | > \ \\ / > E--------F > |\\ > | > H2 > > A,B,C,E,F are in one site (on the left); A, D, and F are in > another site (or > no site). H1 is connected to A, and H2 is connected to F. > > It's fairly clear how to allow A and F to not advertise site-local > addresses across the boundary (at least, as long as it > coincides with a > routing protocol boundary, e.g. OSPF area). However, if H1 knows that > H2 is witchin the same site, H1 is allowed to use its > site-local source > address to send to H2's global address. However, along the > H1-A-D-F-H2 > path, A would have to drop the packet because it has a > site-local address > and is trying to cross a site boundary. > > > Although this example is a bit contrived, it comes close to describing > the topology at AT&T, with Research split between the coasts and both > a private link (e.g. the internal site link) and links to the AT&T > internal network (which is still organizational-internal, so it's > reasonable to speak an IGP). > > 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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 13 12:08:18 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DJ8Fk7028347; Thu, 13 Jun 2002 12:08:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5DJ8FFG028346; Thu, 13 Jun 2002 12:08:15 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DJ8Ak7028339 for ; Thu, 13 Jun 2002 12:08:10 -0700 (PDT) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g5DJ86oR005019 for ; Thu, 13 Jun 2002 12:08:06 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g5DJ86Yx005018 for ipng@sunroof.eng.sun.com; Thu, 13 Jun 2002 12:08:06 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DD66k7025144 for ; Thu, 13 Jun 2002 06:06:06 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA09976 for ; Thu, 13 Jun 2002 06:06:11 -0700 (PDT) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA23787 for ; Thu, 13 Jun 2002 06:06:10 -0700 (PDT) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 44DA02B98; Thu, 13 Jun 2002 09:06:10 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 13 Jun 2002 09:06:10 -0400 x-mimeole: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols Date: Thu, 13 Jun 2002 09:06:09 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B8A15@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Fwd: IPv6 Scoped Addresses and Routing Protocols Thread-Index: AcIQkgD/9o/CvWDoRkyAzq1pblE89wCSOqrw From: "Bound, Jim" To: "Keith Moore" , "Tony Hain" Cc: "Steven M. Bellovin" , "Pekka Savola" , "Ralph Droms" , X-OriginalArrivalTime: 13 Jun 2002 13:06:10.0129 (UTC) FILETIME=[16503C10:01C212DB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5DD66k7025145 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk let me second that and add. Its BRAIN DEAD idea. Sorry I view code like a child. children with sitelocals is like children on drugs to use a randy type abstraction :--) /jim > -----Original Message----- > From: Keith Moore [mailto:moore@cs.utk.edu] > Sent: Monday, June 10, 2002 11:14 AM > To: Tony Hain > Cc: Steven M. Bellovin; Pekka Savola; Ralph Droms; > ipng@sunroof.eng.sun.com > Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols > > > > In any > > case, the only way a DNS server should return a SL in a > response is if > > the query was received on a SL. This is the only reasonable > way for the > > server to know if the answer is usable. > > it doesn't work in general, because the query could be from a cache > that doesn't know anything about SL. > > putting limited-scope addrs in DNS is a Bad Idea, period. > > Keith > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 13 12:08:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DJ8Zk7028371; Thu, 13 Jun 2002 12:08:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5DJ8Y6t028367; Thu, 13 Jun 2002 12:08:34 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DJ8Uk7028359 for ; Thu, 13 Jun 2002 12:08:30 -0700 (PDT) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g5DJ8RoR005035 for ; Thu, 13 Jun 2002 12:08:27 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g5DJ8Rc8005034 for ipng@sunroof.eng.sun.com; Thu, 13 Jun 2002 12:08:27 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DDEXk7025199 for ; Thu, 13 Jun 2002 06:14:33 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA00998 for ; Thu, 13 Jun 2002 06:14:38 -0700 (PDT) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA14398 for ; Thu, 13 Jun 2002 06:14:37 -0700 (PDT) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 537959A8; Thu, 13 Jun 2002 09:14:37 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 13 Jun 2002 09:14:34 -0400 x-mimeole: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C212DC.425A769B" Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols Date: Thu, 13 Jun 2002 09:14:33 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B8A18@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Fwd: IPv6 Scoped Addresses and Routing Protocols Thread-Index: AcIRTzR6RPBXVMbnSOixF/SWu7S+0wBjPqBw From: "Bound, Jim" To: , , X-OriginalArrivalTime: 13 Jun 2002 13:14:34.0000 (UTC) FILETIME=[42A4D900:01C212DC] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C212DC.425A769B Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable We have seen this for too long. We should not wait on this SL figuring = it out anymore rip them out of IPv6. =20 /jim -----Original Message----- From: rbrabson@us.ibm.com [mailto:rbrabson@us.ibm.com] Sent: Tuesday, June 11, 2002 9:47 AM To: Mark.Andrews@isc.org; ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols On Tuesday, 06/11/2002 at 01:47ZE10, Mark.Andrews@isc.org wrote: > Putting limited-scope addrs in DNS is a bad idea *unless* > you have a way to uniquely identify the scope. >=20 > Neither AAAA or A6 provide support for this. I made a proposal > that would have added this to A6 *before* there was any A6 > deployment. It got totally ignored by the IPv6 community (with > the exception of Matt). >=20 > Now might be a good time to raise the idea again except I won't > tie it to A6. >=20 > SA >=20 > SA scoped address > scopename is a domainname choosen to be globally unique. > global addresses have a scopename of ".". >=20 > the conversion from scopename to scopeid / zoneid is a > *local* resolution problem for the machine. So, to make SL work, we need changes to the DNS name server, changes=20 to the resolver, routers to advertise the scope zones, hosts to=20 learn the scope zones from routers and include them on DDNS=20 registrations and use them in making routing decisions, updates to=20 routing protocols, IANA needs to manage a new zone scope naming=20 space, and who knows what else. Wouldn't it make sense to hold off on SL until we at least have=20 some proposals on the table which describe the changes necessary to=20 make SL work, at which time we could have a discussion on the=20 technical merits of the proposal(s)? Until that time, though, the=20 SL unicast address space should either be reserved or moved to=20 experimental. Roy ------_=_NextPart_001_01C212DC.425A769B Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
We=20 have seen this for too long.  We should not wait on this SL = figuring it out=20 anymore rip them out of IPv6.
 
/jim
-----Original Message-----
= rbrabson@us.ibm.com=20 [mailto:rbrabson@us.ibm.com]
Sent: Tuesday, June 11, 2002 = 9:47=20 AM
To: Mark.Andrews@isc.org;=20 ipng@sunroof.eng.sun.com
Subject: Re: Fwd: IPv6 Scoped = Addresses and=20 Routing Protocols

On Tuesday, 06/11/2002 at = 01:47ZE10,=20 Mark.Andrews@isc.org wrote:
> Putting limited-scope addrs in DNS = is a=20 bad idea *unless*
> you have a way to uniquely identify the=20 scope.
>
> Neither AAAA or A6 provide support for this. =  I=20 made a proposal
> that would have added this to A6 *before* = there was=20 any A6
> deployment.  It got totally ignored by the IPv6 = community=20 (with
> the exception of Matt).
>
> Now might be a = good=20 time to raise the idea again except I won't
> tie it to = A6.
>=20
> <ownername> SA <IPV6 address> = <scopename>
>=20
> SA  scoped address
> scopename is a domainname = choosen to=20 be globally unique.
>  global addresses have a scopename of = ".".
>
> the conversion from scopename to scopeid / = zoneid is=20 a
> *local* resolution problem for the = machine.

So, to=20 make SL work, we need changes to the DNS name server, changes =
to=20 the resolver, routers to advertise the scope zones, hosts to=20
learn the scope zones from routers and include them on = DDNS=20
registrations and use them in making routing decisions, = updates=20 to
routing protocols, IANA needs to manage a new zone = scope=20 naming
space, and who knows what = else.

Wouldn't=20 it make sense to hold off on SL until we at least have =
some=20 proposals on the table which describe the changes necessary to=20
make SL work, at which time we could have a discussion on = the=20
technical merits of the proposal(s)?  Until that = time,=20 though, the
SL unicast address space should either be = reserved or=20 moved to=20
experimental.

Roy ------_=_NextPart_001_01C212DC.425A769B-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 13 12:08:52 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DJ8ok7028398; Thu, 13 Jun 2002 12:08:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5DJ8mch028392; Thu, 13 Jun 2002 12:08:48 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DJ8Xk7028366 for ; Thu, 13 Jun 2002 12:08:33 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA03882 for ; Thu, 13 Jun 2002 12:08:37 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA03854 for ; Thu, 13 Jun 2002 13:10:23 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5DJ8VY03298; Thu, 13 Jun 2002 15:08:31 -0400 (EDT) Message-Id: <200206131908.g5DJ8VY03298@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: Brian E Carpenter , ipng@sunroof.eng.sun.com Subject: Re: IESG comments on draft-ietf-ipngwg-default-addr-select-06.txt In-reply-to: (Your message of "Fri, 14 Jun 2002 02:35:59 +0900.") Date: Thu, 13 Jun 2002 15:08:31 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > (though I'm not making an objection to what you're sayign) let me > clarify the issue (mostly for myself) once more. We're perhaps mixing > up host issues and application issues. In my understanding, > > 1. whether or not privacy is desired is a per-host (or > per-administrator) issue, not a per-application issue; if the main > user (likely the administrator) of a host really wants the privacy, > the user wants the privacy apply to all applications on the host, > even if some of the applications do not work well due to > the characteristics of temporary addresses. I disagree. I think the user will want applications to work well even if that means giving them public addresses, and that it's probably safe to assume that for applications that do work with private addresses, users won't mind if those apps use them. > So, the specification should be: > > - the privacy extension draft should clearly say that it is optional > to (support and) configure temporary addresses and that the default > is not configuring temporary addresses. the draft should also > describe the troublesome cases with temporary addresses to > communicate the risk of using them for administrators. > - the address selection draft should say *if temporary addresses are > configured on the host* the temporary addresses should be preferred. > It should also note that whether or not configuring temporary > addresses are optional and the default is not configuring them. > - we'll not necessarily need a per-connection switch to change the > logic of preferring temporary or public addresses, because if we > want privacy or not is rather a per-host issue. we MAY add such a > knob, but it does not have to be a MUST. > > Can this be a compromise for this issue? completely disagree. there's every reason to let the app control whether it gets temporary addresses, and no justification that I can see for the per-host knob. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 13 12:09:02 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DJ90k7028416; Thu, 13 Jun 2002 12:09:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5DJ8xl9028415; Thu, 13 Jun 2002 12:08:59 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DJ8rk7028406 for ; Thu, 13 Jun 2002 12:08:53 -0700 (PDT) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g5DJ8noR005051 for ; Thu, 13 Jun 2002 12:08:49 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g5DJ8ni9005050 for ipng@sunroof.eng.sun.com; Thu, 13 Jun 2002 12:08:49 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DDJOk7025249 for ; Thu, 13 Jun 2002 06:19:24 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA12632 for ; Thu, 13 Jun 2002 06:19:30 -0700 (PDT) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA16658 for ; Thu, 13 Jun 2002 06:19:29 -0700 (PDT) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 2431265D4; Thu, 13 Jun 2002 09:19:29 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 13 Jun 2002 09:19:29 -0400 x-mimeole: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols Date: Thu, 13 Jun 2002 09:19:28 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B8A1A@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Fwd: IPv6 Scoped Addresses and Routing Protocols Thread-Index: AcIRaeMw7jxf1QexS6qSqsd3vXL9mABcwVjQ From: "Bound, Jim" To: "Keith Moore" , "Steven M. Bellovin" Cc: , X-OriginalArrivalTime: 13 Jun 2002 13:19:29.0150 (UTC) FILETIME=[F29129E0:01C212DC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5DDJPk7025250 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk exactly. /jim > -----Original Message----- > From: Keith Moore [mailto:moore@cs.utk.edu] > Sent: Tuesday, June 11, 2002 1:00 PM > To: Steven M. Bellovin > Cc: rbrabson@us.ibm.com; ipng@sunroof.eng.sun.com > Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols > > > > I think this is the key point. Regardless of the possible > benefits of > > site-local addresses -- and I'm willing to withhold judgment on that > > point -- we don't know in detail how to make them work. At > a minimum, > > we need changes in routing and the DNS. We may need new global > > namespaces as well, with all that implies for co-ordination and > > administrative overhead. > > and given that all that stuff is "needed", and the costs > associated not just > with this infrastructure but also of the increased burden on > applications, > it ought to raise a strong suspicion that SL addresses are > not worth the cost. > > Keith > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 13 12:08:51 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DJ8nk7028397; Thu, 13 Jun 2002 12:08:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5DJ8mjD028394; Thu, 13 Jun 2002 12:08:48 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DJ8fk7028379 for ; Thu, 13 Jun 2002 12:08:41 -0700 (PDT) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g5DJ8doR005043 for ; Thu, 13 Jun 2002 12:08:39 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g5DJ8cnN005042 for ipng@sunroof.eng.sun.com; Thu, 13 Jun 2002 12:08:38 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DDIqk7025238 for ; Thu, 13 Jun 2002 06:18:52 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA01795 for ; Thu, 13 Jun 2002 06:18:57 -0700 (PDT) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA16438 for ; Thu, 13 Jun 2002 06:18:57 -0700 (PDT) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 9B0E52ADE; Thu, 13 Jun 2002 09:18:56 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 13 Jun 2002 09:18:56 -0400 x-mimeole: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: IESG comments on draft-ietf-ipngwg-default-addr-select-06.txt Date: Thu, 13 Jun 2002 09:18:55 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B8A19@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IESG comments on draft-ietf-ipngwg-default-addr-select-06.txt Thread-Index: AcIRZIDwnZPMeRPkR5q1dps03lefmwBeBS1A From: "Bound, Jim" To: "Thomas Narten" , X-OriginalArrivalTime: 13 Jun 2002 13:18:56.0556 (UTC) FILETIME=[DF23B6C0:01C212DC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5DDIqk7025239 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas, I can't support this at my end. It should be left to configuration. All we can do is tell users the danger (which I believe is mostly perceived) forcing people to not use public addresses is very bad as a default. That was not what many of us bought into when the paranoid forced us to create 3041. Temp is there if you perceive a problem. I don't support the current wording below. /jim > -----Original Message----- > From: Thomas Narten [mailto:narten@us.ibm.com] > Sent: Tuesday, June 11, 2002 12:19 PM > To: ipng@sunroof.eng.sun.com > Subject: IESG comments on draft-ietf-ipngwg-default-addr-select-06.txt > > > The IESG has a number of comments on this document. Most of them are > of an editorial nature, and I'll let Rich summarize those in a > separate note. > > One issue was substantive and requires WG feedback. The -06 document > specifies that public addresses are to be preferred over temporary by > default. My recollection is that the WG originally had temporary > addresses being preferred, but more recently switched this under > concerns that there were cases where the use of temporary addresses > might harm an application. Thus, the conservative thing to do would be > to prefer public addresses but allow the application (via an API) to > reverse this preference. > > The IESG is concerned that if temporary addresses are not enabled by > default, they won't see widespread use in practice. This would > significantly decrease the overall impact that RFC 3041 will have on > reducing the threat it attempts to address. What the IESG would > prefer seeing is that temporary addresses be given preference by > default, but also include more guidance text in the document to make > it clear that there are cases where the use of temporary addresses by > default may not be appropriate. > > The following text has been proposed to address this issue: > > Proposed new wording: > > Rule 7: Prefer public addresses. > > If SA is a temporary address and SB is a public address, > then prefer > SA. Similarly, if SB is a temporary address and SA is a public > address, then prefer SB. > An implementation MUST support a per-connection configuration > mechanism (for example, an API extension) to reverse the sense of > this preference and prefer public addresses over public > addresses. > > In order for temporary addresses to have their desired effect, they > must become widely used in practice. The above rule is designed to > ensure widespread usage and enablement of temporary addresses. It > is believed that in many cases, temporary addresses can be used in > place of public addresses without problems. However, there are some > classes of applications that may fail due to the relatively short > lifetime of temporary addresses (compared with public addresses) or > due to the possibility of the reverse lookup of a temporary address > either failing or returning a randomized name. Implementations in > which it is believed that such applications exist MAY reverse the > sense of this rule and by default prefer public addresses over > temporary addresses. > > It should also be noted that a simple "prefer" or "don't prefer" > configuration switch with regards to the default selection of > temporary addresses is not sufficiently flexible in many cases. In > practice, it is expected that both client and server applications > will run on the same devices simultaneously. Client applications > will generally be able to use temporary addresses, while servers > will generally need to use public addresses. One possible heuristic > for distinguishing these cases is to assume that an application > that invokes a passive open (as its first network usage) is a > server, while an application that first invokes an active open be > assumed to be a client. > > (Note also, that the above text changes a "may" to MUST with regards > the need to provide a way for individual applications to change the > default via, e.g, a socket option) > > Is the above a reasonable way forward? (Individual responses, even if > they are along the lines of "fine with me" would be appreciated, as > this document is needed soon to meet a 3GPP deadline). > > 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 Thu Jun 13 12:09:12 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DJ9Ak7028442; Thu, 13 Jun 2002 12:09:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5DJ98GT028440; Thu, 13 Jun 2002 12:09:08 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DJ8lk7028393 for ; Thu, 13 Jun 2002 12:08:48 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA27714 for ; Thu, 13 Jun 2002 12:08:51 -0700 (PDT) Received: from zcamail04.zca.compaq.com (zcamail04.zca.compaq.com [161.114.32.104]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA19417 for ; Thu, 13 Jun 2002 13:08:51 -0600 (MDT) Received: from mailrelay01.cce.cpqcorp.net (mailrelay01.cce.cpqcorp.net [16.47.68.171]) by zcamail04.zca.compaq.com (Postfix) with ESMTP id C6F05E03; Thu, 13 Jun 2002 12:13:19 -0700 (PDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id 59C0613C3; Thu, 13 Jun 2002 14:08:38 -0500 (CDT) Received: from hp.com by anw.zk3.dec.com (8.11.1/1.1.22.2/08Sep98-0251PM) id g5DJ8bN0000623457; Thu, 13 Jun 2002 15:08:37 -0400 (EDT) Message-ID: <3D08EDB5.70706@hp.com> Date: Thu, 13 Jun 2002 15:08:37 -0400 From: Vladislav Yasevich Organization: Hewlett Packard User-Agent: Mozilla/5.0 (X11; U; OSF1 alpha; en-US; rv:0.9.9) Gecko/20020318 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tony Hain Cc: ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [I am not sure if this has been said yet, I stil have ~130 unread messages, but...] Tony I strongly disagree. DNS servers function from the stand point of RRsets not individuals RRs like A and AAAA. What you are proposing is similar to not returning A records for a query that used IPv6 network which was discussed on ngtrans a while ago. This would end up splitting the RRset and returning a partial set, which may not be what was required by the requestor. You are limiting the response of the server based on the protocol/addresses used to access it. The only thing that does this now is two-faced DNS or multiple views in bind 9. But, I am not sure that handle muliple sites. -vlad Tony Hain wrote: > > > THere is a mismatch between the DNS perception of 'site' and the > site-local definition of 'site'. The DNS version is much stricter about > physical separation, but there shouldn't be a requirement that DNS > servers for a segment of an AS have to be in differrent SL regions. It > sounds like there is more to do on the DNS operations document... In any > case, the only way a DNS server should return a SL in a response is if > the query was received on a SL. This is the only reasonable way for the > server to know if the answer is usable. If the DNS servers for a given > set of hosts are split across multiple SL zones, then some of the > answers will be global. This is logically the right thing to do from the > DNS query/response perspective, but from the operations perspective, the > servers shouldn't be in separate SL zones. If a particular network > doesn't want to add to the DNS infrastructure, there is no requirement > to populate it with SL addresses. If the routers don't announce them in > the RA, and they aren't in the DNS, they don't get used. That does not > mean we should get rid of them, because smaller organizations will > typically find them useful to minimize the impact of changing providers. > > Tony > > > > > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > > -- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Vladislav Yasevich Tru64 UNIX - IPv6 Project Lead Hewlett Packard Tel: (603) 884-1079 Nashua, NH 03062 ZKO3-3/T07 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 13 12:09:30 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DJ9Ck7028446; Thu, 13 Jun 2002 12:09:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5DJ9BJC028445; Thu, 13 Jun 2002 12:09:11 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DJ93k7028425 for ; Thu, 13 Jun 2002 12:09:03 -0700 (PDT) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g5DJ8xoR005059 for ; Thu, 13 Jun 2002 12:08:59 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g5DJ8x94005058 for ipng@sunroof.eng.sun.com; Thu, 13 Jun 2002 12:08:59 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DDM6k7025260 for ; Thu, 13 Jun 2002 06:22:06 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA13140 for ; Thu, 13 Jun 2002 06:22:11 -0700 (PDT) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA17730 for ; Thu, 13 Jun 2002 06:22:11 -0700 (PDT) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id EAE118DCC; Thu, 13 Jun 2002 09:22:10 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 13 Jun 2002 09:22:10 -0400 x-mimeole: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: IPv6 Scoped Addresses and Routing Protocols Date: Thu, 13 Jun 2002 09:22:10 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B8A1B@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv6 Scoped Addresses and Routing Protocols Thread-Index: AcIRfNHyXtm96FF8QzCAjjofjNiP0gBYGJuw From: "Bound, Jim" To: "Alain Durand" , "Randy Bush" Cc: "Keith Moore" , "Markku Savela" , X-OriginalArrivalTime: 13 Jun 2002 13:22:10.0900 (UTC) FILETIME=[52FA4140:01C212DD] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5DDM6k7025261 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk another good point. I will have to put all this "virtual" if-then context in all the transition code. YUCK............ Come on folks lets kill them. /jim > -----Original Message----- > From: Alain Durand [mailto:Alain.Durand@Sun.COM] > Sent: Tuesday, June 11, 2002 3:13 PM > To: Randy Bush > Cc: Keith Moore; Markku Savela; ipng@sunroof.eng.sun.com > Subject: Re: IPv6 Scoped Addresses and Routing Protocols > > > > On Tuesday, June 11, 2002, at 12:02 PM, Randy Bush wrote: > > >> it seems obvious in hindsight that private addresses were a mistake > >> in IPv4. so the fact that they exist, and that we now find it > >> necessary > >> to warn people to not advertise them in DNS, shouldn't be cited as > >> a justification to make further mistakes which will then > necessitate > >> further kludges to DNS. > > > > agree. so let's get rid of these kinky scoped addresses in v6 > > That would certainly make life in v6 land much simpler. > And anything that makes it simpler ease transition worries. > > - Alain. > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 13 12:09:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DJ9Yk7028482; Thu, 13 Jun 2002 12:09:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5DJ9XGS028479; Thu, 13 Jun 2002 12:09:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DJ9Rk7028466 for ; Thu, 13 Jun 2002 12:09:28 -0700 (PDT) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g5DJ9PoR005075 for ; Thu, 13 Jun 2002 12:09:25 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g5DJ9PwN005074 for ipng@sunroof.eng.sun.com; Thu, 13 Jun 2002 12:09:25 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DDPsk7025288 for ; Thu, 13 Jun 2002 06:25:54 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA21544 for ; Thu, 13 Jun 2002 06:25:59 -0700 (PDT) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA02645 for ; Thu, 13 Jun 2002 07:25:58 -0600 (MDT) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 349E939F9; Thu, 13 Jun 2002 09:25:58 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 13 Jun 2002 09:25:57 -0400 x-mimeole: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: IPv6 Scoped Addresses and Routing Protocols Date: Thu, 13 Jun 2002 09:25:56 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B8A1D@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv6 Scoped Addresses and Routing Protocols Thread-Index: AcIRoPkuiLFSVZD3S9aIsk7Ik7iuFgBPNfrw From: "Bound, Jim" To: "Derek Fawcus" , X-OriginalArrivalTime: 13 Jun 2002 13:25:57.0465 (UTC) FILETIME=[DA055490:01C212DD] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5DDPsk7025289 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk we can keep link-local and not above. /jim > -----Original Message----- > From: Derek Fawcus [mailto:dfawcus@cisco.com] > Sent: Tuesday, June 11, 2002 4:36 PM > To: ipng@sunroof.eng.sun.com > Subject: Re: IPv6 Scoped Addresses and Routing Protocols > > > My view on site local addresses is a bit split. > > From a personal point of view I like them. I can use them in my home > network, together with global addresses (6to4 at the moment), and > even store them in my local DNS server. None of this causes me > any problems, it all works and means if/when an ISP in the UK is > able to supply me with real IPv6 global addresses I'll not have to > alter much. > > As things stand if someone was to query my DNS server from the > outside world (assuming the domain I'm using delegated to me), > they'd not see any SL addresses - split DNS. > > This is the simple scenario of SL enabled globally at home, and > having a couple of (site) border routers, both of which have some > global interfaces and some site interfaces. Both routers only know > about the one site - the same site. > > However as an router implementor - they're a right royal pain. > > One major issue being the possibility of having more than one site > cutting through the router. For a single CPU router this is not > too bad, for a multi CPU router it is awkward. > > Now even if we were to simplify things so that a node (router) could > not attach to more than one site at a time (i.e. the case of site > links, and non-site (global) links), things'd not stay simple > for long. > > I say this 'cause I'd anticipate that someone would want to supply > outsourced managed 'Site' networks in the same fashion as ISPs > offer managed VPNs at the moment. This would effectively collapse > things back into the situation we have at the moment with multi-site > routers. > > -- > > Overrall I guess I'd say keep them, then hope they never get deployed > at anything other than the sort of use I personally have for them. > > This basically means that they'd not be of much use for anything other > than small scale use, and (as someone else pointed out) are of no use > to large organisations with geographically diverse facilities. > > What does worry me though is if customers (ISPs) want to have the same > sort of VPN facility I've mentioned above - this seems to naturally > coincide with the v6 view of SL addresses, and raises very similar > issues to be solved. > > The real answer to the underlying problem here is a lot harder to > solve. It all seems to mainly be about security, and it would > seem that IPsec should be used to address it. However the issue > of having keys distributed, and prooving identity still needs > to be rolled out. > > DF > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Jun 13 12:09:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DJ9Mk7028465; Thu, 13 Jun 2002 12:09:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5DJ9LW7028464; Thu, 13 Jun 2002 12:09:21 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DJ9Fk7028448 for ; Thu, 13 Jun 2002 12:09:15 -0700 (PDT) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g5DJ9BoR005067 for ; Thu, 13 Jun 2002 12:09:11 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g5DJ9B0I005066 for ipng@sunroof.eng.sun.com; Thu, 13 Jun 2002 12:09:11 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DDOlk7025274 for ; Thu, 13 Jun 2002 06:24:47 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA21308 for ; Thu, 13 Jun 2002 06:24:52 -0700 (PDT) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA02087 for ; Thu, 13 Jun 2002 06:24:52 -0700 (PDT) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 7F225B7B; Thu, 13 Jun 2002 09:24:51 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 13 Jun 2002 09:24:51 -0400 x-mimeole: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: IESG comments on draft-ietf-ipngwg-default-addr-select-06.txt Date: Thu, 13 Jun 2002 09:24:50 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B8A1C@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IESG comments on draft-ietf-ipngwg-default-addr-select-06.txt Thread-Index: AcIRl/k/k4b3XMjqTKiIh+lN+sd0SgBRW4qA From: "Bound, Jim" To: "Erik Nordmark" , "Keith Moore" Cc: "Thomas Narten" , X-OriginalArrivalTime: 13 Jun 2002 13:24:51.0293 (UTC) FILETIME=[B29448D0:01C212DD] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5DDOlk7025275 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The default should be public. Thats the Internet way. Temp is means Temp. If you want to make a phone call over VoIPv6 and you have a temp address my phone call could be killed or paused waiting for renew. I find that kind of rude. Default should be public temp should be an option. Also give me one technical reason why it should be temp. /jim > -----Original Message----- > From: Erik Nordmark [mailto:Erik.Nordmark@Sun.COM] > Sent: Tuesday, June 11, 2002 6:29 PM > To: Keith Moore > Cc: Thomas Narten; ipng@sunroof.eng.sun.com > Subject: Re: IESG comments on > draft-ietf-ipngwg-default-addr-select-06.txt > > > > I respect the desire for temporary addresses (and AFAIK I > was one of > > the first people to raise concerns about embedding tracable > information > > in an IPv6 address) but I don't think it's a good idea to > effectively > > change the API in a way that would break apps at this late date. > > The proposed text is trying to say that temporary addresses > are preferable > but that there might be issues (such as applications having problems) > which consistitute a good enough reason to not follow the default. > Thus there is significant freedom for implementors to use their best > judgement based on their knowledge about the applications. > > Do you see a problem with this approach? > > 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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 13 12:16:20 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DJGHk7028681; Thu, 13 Jun 2002 12:16:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5DJGFJs028677; Thu, 13 Jun 2002 12:16:15 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DJFwk7028649 for ; Thu, 13 Jun 2002 12:15:59 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA09373; Thu, 13 Jun 2002 15:15:55 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g5DJFtZs005045; Thu, 13 Jun 2002 15:15:55 -0400 (EDT) Message-Id: <200206131915.g5DJFtZs005045@thunk.east.sun.com> From: Bill Sommerfeld To: "Bound, Jim" cc: "James Kempf" , ipng@sunroof.eng.sun.com Subject: Re: Securing Neighbor Discovery BOF In-Reply-To: Your message of "Thu, 13 Jun 2002 08:32:38 EDT." <9C422444DE99BC46B3AD3C6EAFC9711B020B8A04@tayexc13.americas.cpqcorp.net> Reply-to: sommerfeld@east.sun.com Date: Thu, 13 Jun 2002 15:15:54 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > What problem are you trying to solve? securing neighbor discovery exchanges. > IPsec works for ND? Using AH/ESP to protect ND works fine once the SA's exist. However, there's a chicken & egg problem if you want to use IKE, and manually configuring N*(N-1) SA's across N machines on the link is not deployable. So if you want to use IPsec to protect ND, you need to solve the key management problem for ND. - 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 Jun 13 12:21:59 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DJLwk7029076; Thu, 13 Jun 2002 12:21:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5DJLv2w029074; Thu, 13 Jun 2002 12:21:57 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DJLok7029061 for ; Thu, 13 Jun 2002 12:21:51 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA15724 for ; Thu, 13 Jun 2002 12:21:54 -0700 (PDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA13771 for ; Thu, 13 Jun 2002 12:21:54 -0700 (PDT) Received: from northrelay03.pok.ibm.com (northrelay03.pok.ibm.com [9.56.224.151]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g5DJLqg5109288 for ; Thu, 13 Jun 2002 15:21:53 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.9.21]) by northrelay03.pok.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5DJLoe17812 for ; Thu, 13 Jun 2002 15:21:50 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id g5DJJri10087 for ; Thu, 13 Jun 2002 15:19:53 -0400 Message-Id: <200206131919.g5DJJri10087@rotala.raleigh.ibm.com> To: ipng@sunroof.eng.sun.com Subject: IESG followup on draft-ietf-ipv6-default-addr-select-07.txt Date: Thu, 13 Jun 2002 15:19:53 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG had a telechat today and discussed the WG feedback on its request regarding draft-ietf-ipv6-default-addr-select-07.txt. Based on the feedback, the request to prefer temporary addresses over public addresses is withdrawn; leaving the default to prefer public addresses is OK. The IESG would still, however, like to see the following change made: An implementation MUST support a per-connection configuration mechanism (for example, an API extension) to reverse the sense of this preference and prefer temporary addresses over public addresses. 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 Jun 13 12:23:38 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DJNbk7029242; Thu, 13 Jun 2002 12:23:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5DJNa5u029241; Thu, 13 Jun 2002 12:23:36 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DJNUk7029234 for ; Thu, 13 Jun 2002 12:23:30 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA16621 for ; Thu, 13 Jun 2002 12:23:34 -0700 (PDT) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA29949 for ; Thu, 13 Jun 2002 13:23:34 -0600 (MDT) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id A6E0C88B; Thu, 13 Jun 2002 15:23:33 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 13 Jun 2002 15:23:33 -0400 x-mimeole: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: IESG comments on draft-ietf-ipngwg-default-addr-select-06.txt Date: Thu, 13 Jun 2002 15:23:30 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B8A3C@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IESG comments on draft-ietf-ipngwg-default-addr-select-06.txt Thread-Index: AcIS4PylZRkNT5CJThamnWsiZYBjVQALstPA From: "Bound, Jim" To: "Brian E Carpenter" , Cc: "Thomas Narten" X-OriginalArrivalTime: 13 Jun 2002 19:23:33.0476 (UTC) FILETIME=[CECCCA40:01C2130F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5DJNVk7029235 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Maybe........... /jim > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Thursday, June 13, 2002 9:45 AM > To: ipng@sunroof.eng.sun.com > Cc: Thomas Narten > Subject: Re: IESG comments on > draft-ietf-ipngwg-default-addr-select-06.txt > > > JINMEI Tatuya / $B?@L@C#:H(B wrote: > > > > >>>>> On Wed, 12 Jun 2002 10:38:24 -0400, > > >>>>> Margaret Wasserman said: > > > > >> The proposed text is trying to say that temporary > addresses are preferable > > >> but that there might be issues (such as applications > having problems) > > >> which consistitute a good enough reason to not follow > the default. > > >> Thus there is significant freedom for implementors to > use their best > > >> judgement based on their knowledge about the applications. > > > > > Is it optional for a vendor to implement temporary > addresses? Is it optional > > > for a user to configure site-local addresses on a box (or > perhaps even for > > > a vendor to support them)? > > > > Good point...I thought in this context we assume vendors implement > > temporary addresses and users configure temporary addresses by > > default. Otherwise, the original concern: > > > > "The IESG is concerned that if temporary addresses are > not enabled by > > default, they won't see widespread use in practice." > > > > would not make sense. > > But in fact that isn't a correct assumption. It's only a > certain class of > systems (today's pure-client style PCs or their equivalents) > for which the > privacy aspect of temporary addresses makes any sense. For > them, a SHOULD rule > for preferring temporary addresses makes sense. But many > other hosts (servers > and anything that wants to break out of the client/server > restriction) won't > use temporary addresses and will use other privacy > mechanisms; so for them > it's simply irrelevant. I think that is the answer to my > colleague Roy Brabson's > objection to the proposed change - hosts that have the > problem he describes > won't be using temporary addresses anyway. And anyone who > attempts to run server > style apps on a host using temporary addresses will get all > kinds of trouble > anyway. > > But it should be a SHOULD. > > Brian > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > Brian E Carpenter > Distinguished Engineer, Internet Standards & Technology, IBM > On assignment at the IBM Zurich Laboratory, Switzerland > Board Chairman, Internet Society http://www.isoc.org > INET 2002, Washington, DC, 18-21 June http://www.inet2002.org > <<=== seats still available! > > > > If, for example, the premise is implementing and > configuring temporary > > addresses are both optional, I'll be just okay with the proposed > > change. Users (or administrators) who dare to configure temporary > > addresses under such an environments should have a strong desire for > > privacy. So, even if the source address selection prefers public > > address by default, such users will explicitly (try to) reverse the > > logic for every communication. This makes the default meaningless, > > and thus preferring temporary address should make much sense. > > (though the premise would be meaningless according to the original > > motivation; widespread use of temporary addresses) > > > > X-Mozilla-Status: 0009 > > 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 > > -------------------------------------------------------------------- > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Jun 13 12:24:15 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DJODk7029361; Thu, 13 Jun 2002 12:24:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5DJOCe5029360; Thu, 13 Jun 2002 12:24:12 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DJO2k7029319 for ; Thu, 13 Jun 2002 12:24:02 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA09626 for ; Thu, 13 Jun 2002 12:24:07 -0700 (PDT) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA15419 for ; Thu, 13 Jun 2002 12:24:06 -0700 (PDT) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id D24B1454B; Thu, 13 Jun 2002 15:24:05 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 13 Jun 2002 15:24:05 -0400 x-mimeole: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols Date: Thu, 13 Jun 2002 15:24:05 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B8A3D@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Fwd: IPv6 Scoped Addresses and Routing Protocols Thread-Index: AcIS4vpADsatCAMDQ0KjctX00jVesQALNlhQ From: "Bound, Jim" To: "Pekka Savola" Cc: "Michel Py" , , "Bob Hinden" , "Steven M. Bellovin" , X-OriginalArrivalTime: 13 Jun 2002 19:24:05.0616 (UTC) FILETIME=[E1F4F700:01C2130F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5DJO3k7029325 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk and that has produced horror not warm and fuzzy. /jim > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Thursday, June 13, 2002 10:02 AM > To: Bound, Jim > Cc: Michel Py; sommerfeld@east.sun.com; Bob Hinden; Steven M. > Bellovin; > ipng@sunroof.eng.sun.com > Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols > > > On Thu, 13 Jun 2002, Bound, Jim wrote: > > > I don't do warm and fuzzy in the IETF. [...] > > My point exactly. I believe site-locals as a serious security measure > mainly provide a "warm fuzzy feeling" like NAT does with IPv4 today. > > > > > -----Original Message----- > > > From: Pekka Savola [mailto:pekkas@netcore.fi] > > > Sent: Saturday, June 08, 2002 6:20 AM > > > To: Michel Py > > > Cc: sommerfeld@east.sun.com; Bob Hinden; Steven M. Bellovin; > > > ipng@sunroof.eng.sun.com > > > Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols > > > > > > > > > On Fri, 7 Jun 2002, Michel Py wrote: > > > > > If there is widespread deployment of systems with > site-local only > > > > > addresses, this will in turn drive the creation of ipv6 NAT > > > > > specifically to give them external connectivity.. > > > > > > > > That looks like a solution without a problem. To give > these hosts > > > > connectivity you just have both the site-local and the > > > global address. > > > > Since NAT would not bring anything to the table why > > > implement it in the > > > > first place? > > > > > > To give folks that think IPv4 private addresses provide security > > > (especially wrt. incoming connections) a smooth transition > > > path to IPv6 > > > and "warm fuzzy feeling". > > > > > > -- > > > Pekka Savola "Tell me of difficulties surmounted, > > > Netcore Oy not those you stumble over and fall" > > > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > > > > > > -------------------------------------------------------------------- > > > IETF IPng Working Group Mailing List > > > IPng Home Page: > http://playground.sun.com/ipng > > > FTP archive: > ftp://playground.sun.com/pub/ipng > > > Direct all administrative requests to > majordomo@sunroof.eng.sun.com > > > > -------------------------------------------------------------------- > > > > > > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 13 12:32:28 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DJWSk7029857; Thu, 13 Jun 2002 12:32:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5DJWR0g029856; Thu, 13 Jun 2002 12:32:27 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DJWOk7029849 for ; Thu, 13 Jun 2002 12:32:24 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA13475 for ; Thu, 13 Jun 2002 12:32:28 -0700 (PDT) Received: from ensemada.lava.net (ensemada.lava.net [64.65.64.27]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA03706 for ; Thu, 13 Jun 2002 13:32:27 -0600 (MDT) Received: from malasada.lava.net ([64.65.64.17]) (1476 bytes) by ensemada.lava.net; Thu, 13 Jun 2002 09:29:50 -1000 (HST) via sendmail [esmtp] id for Date: Thu, 13 Jun 2002 09:29:50 -1000 (HST) From: Antonio Querubin To: Robert Elz cc: Jun-ichiro itojun Hagino , Subject: Re: Review of"Use of /127 Prefix Length Between Routers Considered Harmful" In-Reply-To: <23436.1023962021@munnari.OZ.AU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 13 Jun 2002, Robert Elz wrote: > From: Jun-ichiro itojun Hagino > | i can think of no reason to use somethiing other than /64. > > The obvious one is to conserve address space. Another is to make it > easier to see what are p2p links from their addresses (all of an organisation's > p2p links can easily be numbered out of one /64). > > In any case, unless there's something that will be broken by using a > longer prefix, there's no reason to forbid it, is there? Concur on both points. Just because one can assign a /64 and get millions of addresses on a p2p link doesn't mean one should. Furthermore, I can understand the arguments for avoiding /127 or /128 but in the cases where the lost capability is a non-issue why bother forbidding even those 2 prefix lengths? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 13 12:33:31 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DJXVk7029867; Thu, 13 Jun 2002 12:33:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5DJWo7i029866; Thu, 13 Jun 2002 12:32:50 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DJWkk7029859 for ; Thu, 13 Jun 2002 12:32:46 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA20522 for ; Thu, 13 Jun 2002 12:32:50 -0700 (PDT) Received: from zcamail04.zca.compaq.com (zcamail04.zca.compaq.com [161.114.32.104]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA20118 for ; Thu, 13 Jun 2002 12:32:50 -0700 (PDT) Received: from taynzmail03.nz-tay.cpqcorp.net (taynzmail03.nz-tay.cpqcorp.net [16.47.4.103]) by zcamail04.zca.compaq.com (Postfix) with ESMTP id 91C57D98; Thu, 13 Jun 2002 12:37:26 -0700 (PDT) Received: from anw.zk3.dec.com (fanw4.zk3.dec.com [16.140.160.17]) by taynzmail03.nz-tay.cpqcorp.net (Postfix) with ESMTP id EED831821; Thu, 13 Jun 2002 15:32:47 -0400 (EDT) Received: from hp.com by anw.zk3.dec.com (8.11.1/1.1.22.2/08Sep98-0251PM) id g5DJWlY0002179019; Thu, 13 Jun 2002 15:32:47 -0400 (EDT) Message-ID: <3D08F35F.1060103@hp.com> Date: Thu, 13 Jun 2002 15:32:47 -0400 From: Vladislav Yasevich Organization: Hewlett Packard User-Agent: Mozilla/5.0 (X11; U; OSF1 alpha; en-US; rv:0.9.9) Gecko/20020318 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Haberman Cc: ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols References: <4.2.2.20020605134805.0245def0@mail.windriver.com> <3D036720.7B02E8E8@nc.rr.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian Wouldn't the Zone ID for a given site on all routers in that same site have to be same for this to work? -vlad Brian Haberman wrote: > Hi Margaret, > I suppose that I should admit to being remiss in this area. I > have done a fair amount of work in this area and just haven't had the > time to document routing protocol behavior changes to support site > local prefixes (even though I recall telling you I was going to do it). > > Anyway, I will start by saying that I have modified RIPng to > correctly handle the advertisement of site-locals. In order to make > this efficient, I maintained the concept of a single instance of RIPng > running in the router. In order to understand the changes to the > routing protocol, you also have to understand the changes to the > RIB for site locals. So, how did I make it work? > > 1. The RIB now contains an additional field, the zone ID. I > have done this in two different ways. The first is to add > the zone ID as a separate field. The second is to embed > the zone ID in the "unused" portion of the site local > prefix. > > 2. RIPng was changed to build its route advertisement messages > on a per zone ID basis. That is, it starts with adding all > global prefixes to the message. It then adds site local > prefixes that are in the same zone ID as the interface that > the advertisement will be transmitted. It determines this > by extracting the zone ID from the outgoing interface and > using this find all site locals in the RIB with a matching > zone ID. > > 3. When RIPng receives a route advertisement from a peer, it > takes the zone ID from the receiving interface and using > that to add the site local prefixes to the RIB. > > That, in a nutshell, allows a single instance of RIPng to control > the advertising of site local unicast prefixes. Though I haven't > done the work, I would see OSPF as acting in a similar manner. > > If someone wants me to describe the actual forwarding, just let me > know. > > Regards, > Brian > > Margaret Wasserman wrote: > >>I sent the attached message to the routing area discussion list. I thought that people on >>the IPv6 list might be interested in this discussion, so I will forward a message containing >>the responses after this one. I suppose I just should have cc:ed the IPv6 group in the >>first place... >> >>Margaret >> >> >>>Date: Fri, 24 May 2002 12:17:04 -0400 >>>To: routing-discussion@ietf.org >>>From: Margaret Wasserman >>>Subject: IPv6 Scoped Addresses and Routing Protocols >>> >>> >>> >>>Hi All, >>> >>>I raised some questions with Bill Fenner in Minneapolis regarding IPv6 scoped >>>addressing and our current IPv6 routing protocol specifications, and Bill suggested >>>that I should send my questions to this list for discussion. So, here they are. >>> >>>First, some background... >>> >>>As many of you probably know, IPv6 includes the concept of scoped unicast >>>addressing -- a unicast address can have link-local scope, site-local scope >>>or global scope. The address scopes are defined in the IPv6 Addressing >>>Architecture: >>> >>>http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-addr-arch-v3-07.txt >>> >>>Additional information can be found in the IPv6 Scoped Address >>>Architecture: >>> >>>http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-scoping-arch-03.txt >>> >>>I would suggest that all of you read the IPv6 Scoped Address Architecture >>>document, if you haven't already, as it contains information regarding >>>the expected configuration and forwarding behaviour of IPv6 routers. >>>It also defines the concept of an IPv6 site, which is important to understanding >>>the questions that I am about to raise. >>> >>>In IPv6, there is a concept of site-local addressing that is quite different >> >>>from the concept of "net 10" addresses in IPv4. Sites are administratively >> >>>defined entities that must be "convex" (i.e. the best route between two nodes >>>in the site must, at all scopes, fall completely within the site). Sites boundaries >>>run through routers, so a single router (called a site border router (SBR)) can >>>have interfaces in more than one site. And, IPv6 site-local addresses can be >>>used for site-constrained communication, even when a site is globally >>>connected and global addresses are available. >>> >>>Because all site-local addresses use the same well-known site-local prefix, the >>>only way to tell that a particular site-local address belongs to a particular >>>site is to know which site originated the address. SBRs will need >>>to enforce site boundaries, not mixing site-local routing information, and not >>>forwarding packets outside of a given site. To do this, it is expected that >>>SBRs will need to maintain multiple "conceptual routing tables", including one >>>site-local routing table for each attached site, and one global routing table. >>> >>>Unfortunately, I can't find any indication that these concepts have been reflected >>>in the current IPv6 routing protocols. None of our IPv6 routing protocol documents >>>deal with site-local boundaries or SBR behaviour explicitly. >>> >>>There are currently four standards for how IPv6 routes will be handled in BGP, OSPF, >>>IS-IS and RIP. I will refer to these documents as BGP-IPv6, OSPF-IPv6 and IS-IS-IPv6, >>>and RIP-IPv6 respectively: >>> >>>Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing: >>>http://www.ietf.org/rfc/rfc2545.txt >>> >>>OSPF for IPv6 >>>http://www.ietf.org/rfc/rfc2740.txt >>> >>>Routing IPv6 with IS-IS: >>>http://www.ietf.org/internet-drafts/draft-ietf-isis-ipv6-02.txt >>> >>>RIPng for IPv6 >>>http://www.ietf.org/rfc/rfc2080.txt >>> >>>So here are my actual questions: >>> >>>(1) Are the statements regarding the routing system in the IPv6 Scoped Addressing Architecture >>>draft valid? Will they work in real life? Please read it, and comment to the IPv6 WG if you think that >>>there are any issues with what it says. >>> >>>(2) BGP-IPv6: >>> >>>BGP-IPv6 states: "As this document makes no assumption on the characteristics of a particular >>>routing realm where BGP-4 is used, it makes no distinction between global and site-local addresses >>>and refers to both as "global" or "non-link-local"." >>> >>>Would it ever be reasonable for BGP to propagate site-local routing information? Why, under >>>what circumstances? Would it be reasonable to assume that an Inter-Domain Routing protocol >>>shouldn't propagate site-local information at all? >>> >>>If BGP should be capable of propagating site-local information, will it be possible, using existing >>>BGP standards for a BGP SBR router with four interfaces (A, B, C & D), in two sites (A & B in S1, >>>and C & D in S2) to maintain two separate sets of information for prefix FEC0::/10, one that applies >>>to S1 (interfaces A & B) and one that applies to S2 (interfaces C & D), and to propagate that information >>>accordingly? Is this really just an issue of configuring the router properly, as BGP-IPv6 implies? >>> >>>(3) OSPF-IPV6: >>> >>>In this specification, no distinction is made between site-local and global addresses. Unlike the >>>previous specification (BGP-IPv6), this assumption is not stated up-front. Instead, everywhere in >>>the draft where either site-local or global addresses are mentioned they are both mentioned (i.e. >>>"site-local or global IPv6 addresses"). >>> >>>Again this specification makes no provision for separate sets of site local information. There is >>>also no mention of a boundary for site-local route propagation, and no mention of multiple conceptual >>>sets of site-local routing information. Would it make sense to tie the concept of an IPv6 site to >>>one of the existing propagation boundaries in OSPF, such as an OSPF area? Or to assume that >>>an OSPF AS will always be completely contained within one site -- which is what the current draft >>>seems to assume? >>> >>>(4) IS-IS-IPv6: >>> >>>IS-IS-IPv6 makes no mention of site-local or scoped addressing at all. Is this appropriate? How will IS-IS >>>SBRs know not to propagate site-local routing information between two attached sites? I don't yet >>>know enough about IS-IS to understand how site-local routing information would best be handled >>>in IS-IS. Any thoughts? >>> >>>(5) RIP-IPv6: >>> >>>The RIP-IPv6 document explicitly states that there is a single IPv6 routing table, and it makes no >>>mention of sites. I think it would be fine to constrain RIP to operating within a single IPv6 >>>site, but that should be explicitly stated somewhere. >>> >>>(6) Will the MIBs for any of these routing tables be capable of representing multiple independent, >>>possibly overlapping sets of site-local routing information? I looked them over quickly, and it >>>wasn't immediately obvious to me how they could do this. >>> >>>(7) Do you think that there would be some utility to defining the actual routing architecture (as >>>opposed to just the addressing architecture) for IPv6? If so, what would be the best way to do >>>that? >>> >>>(8) Should we mention link-local addresses anywhere in these specifications? We certainly would >>>not want to propagate routing information for link-local addresses. >>> >>>If there is some work that needs to be done here, I am very happy to provide some IPv6 expertise >>>to that effort. >>> >>>Margaret >>> >>> >>> >> >>-------------------------------------------------------------------- >>IETF IPng Working Group Mailing List >>IPng Home Page: http://playground.sun.com/ipng >>FTP archive: ftp://playground.sun.com/pub/ipng >>Direct all administrative requests to majordomo@sunroof.eng.sun.com >>-------------------------------------------------------------------- > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > > -- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Vladislav Yasevich Tru64 UNIX - IPv6 Project Lead Hewlett Packard Tel: (603) 884-1079 Nashua, NH 03062 ZKO3-3/T07 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 13 12:37:58 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DJbwk7029908; Thu, 13 Jun 2002 12:37:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5DJbvS6029907; Thu, 13 Jun 2002 12:37:57 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DJbsk7029900 for ; Thu, 13 Jun 2002 12:37:54 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA10098 for ; Thu, 13 Jun 2002 12:37:59 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA07888 for ; Thu, 13 Jun 2002 13:37:58 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g5DJbel17355; Thu, 13 Jun 2002 22:37:40 +0300 Date: Thu, 13 Jun 2002 22:37:40 +0300 (EEST) From: Pekka Savola To: "Bound, Jim" cc: Michel Py , , Bob Hinden , "Steven M. Bellovin" , Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B020B8A3D@tayexc13.americas.cpqcorp.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 13 Jun 2002, Bound, Jim wrote: > and that has produced horror not warm and fuzzy. Exactly: horror to thow who know what they're about, warm and fuzzy who think they're safe. > > -----Original Message----- > > From: Pekka Savola [mailto:pekkas@netcore.fi] > > Sent: Thursday, June 13, 2002 10:02 AM > > To: Bound, Jim > > Cc: Michel Py; sommerfeld@east.sun.com; Bob Hinden; Steven M. > > Bellovin; > > ipng@sunroof.eng.sun.com > > Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols > > > > > > On Thu, 13 Jun 2002, Bound, Jim wrote: > > > > > I don't do warm and fuzzy in the IETF. [...] > > > > My point exactly. I believe site-locals as a serious security measure > > mainly provide a "warm fuzzy feeling" like NAT does with IPv4 today. > > > > > > > > -----Original Message----- > > > > From: Pekka Savola [mailto:pekkas@netcore.fi] > > > > Sent: Saturday, June 08, 2002 6:20 AM > > > > To: Michel Py > > > > Cc: sommerfeld@east.sun.com; Bob Hinden; Steven M. Bellovin; > > > > ipng@sunroof.eng.sun.com > > > > Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols > > > > > > > > > > > > On Fri, 7 Jun 2002, Michel Py wrote: > > > > > > If there is widespread deployment of systems with > > site-local only > > > > > > addresses, this will in turn drive the creation of ipv6 NAT > > > > > > specifically to give them external connectivity.. > > > > > > > > > > That looks like a solution without a problem. To give > > these hosts > > > > > connectivity you just have both the site-local and the > > > > global address. > > > > > Since NAT would not bring anything to the table why > > > > implement it in the > > > > > first place? > > > > > > > > To give folks that think IPv4 private addresses provide security > > > > (especially wrt. incoming connections) a smooth transition > > > > path to IPv6 > > > > and "warm fuzzy feeling". > > > > > > > > -- > > > > Pekka Savola "Tell me of difficulties surmounted, > > > > Netcore Oy not those you stumble over and fall" > > > > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > > > > > > > > > -------------------------------------------------------------------- > > > > IETF IPng Working Group Mailing List > > > > IPng Home Page: > > http://playground.sun.com/ipng > > > > FTP archive: > > ftp://playground.sun.com/pub/ipng > > > > Direct all administrative requests to > > majordomo@sunroof.eng.sun.com > > > > > > -------------------------------------------------------------------- > > > > > > > > > > > -- > > Pekka Savola "Tell me of difficulties surmounted, > > Netcore Oy not those you stumble over and fall" > > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > > > > -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 13 12:40:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DJeZk7029928; Thu, 13 Jun 2002 12:40:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5DJeZ7u029927; Thu, 13 Jun 2002 12:40:35 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DJeVk7029920 for ; Thu, 13 Jun 2002 12:40:31 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA23815 for ; Thu, 13 Jun 2002 12:40:30 -0700 (PDT) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA23943 for ; Thu, 13 Jun 2002 12:40:25 -0700 (PDT) Subject: RE: Review of"Use of /127 Prefix Length Between Routers ConsideredHarmful" Date: Thu, 13 Jun 2002 12:40:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046406C81F@server2000.arneill-py.sacramento.ca.us> X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 X-MS-TNEF-Correlator: Thread-Topic: Review of"Use of /127 Prefix Length Between Routers ConsideredHarmful" content-class: urn:content-classes:message Thread-Index: AcITEb0A2F5brzBBTcSHg8TdKd3K6gAABJbg From: "Michel Py" To: "Antonio Querubin" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5DJeWk7029921 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Antonio Querubin wrote: > Concur on both points. Just because one can assign a /64 and get > millions of addresses on a p2p link doesn't mean one should. > Furthermore, I can understand the arguments for avoiding /127 or > /128 but in the cases where the lost capability is a non-issue > why bother forbidding even those 2 prefix lengths? The fact of the matter is that any prefix longer than /64 goes against [ADDRARCH] Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 13 12:42:26 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DJgQk7029950; Thu, 13 Jun 2002 12:42:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5DJgP3K029949; Thu, 13 Jun 2002 12:42:25 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DJgMk7029942 for ; Thu, 13 Jun 2002 12:42:22 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA11942 for ; Thu, 13 Jun 2002 12:42:27 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA07363 for ; Thu, 13 Jun 2002 12:42:26 -0700 (PDT) Received: by p2.piuha.net (Postfix, from userid 962) id 037656A904; Thu, 13 Jun 2002 22:42:19 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 07BD26A901; Thu, 13 Jun 2002 22:42:11 +0300 (EEST) Message-ID: <3D08F5E0.5010701@kolumbus.fi> Date: Thu, 13 Jun 2002 22:43:28 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: sommerfeld@east.sun.com Cc: "Bound, Jim" , James Kempf , ipng@sunroof.eng.sun.com, ietf-send@standards.ericsson.net Subject: Re: Securing Neighbor Discovery BOF References: <200206131915.g5DJFtZs005045@thunk.east.sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bill Sommerfeld wrote: > Using AH/ESP to protect ND works fine once the SA's exist. > > However, there's a chicken & egg problem if you want to use IKE, and > manually configuring N*(N-1) SA's across N machines on the link is not > deployable. Actually, it's worse. ND uses e.g. the solicited node multicast address and the unicast address -- even if each node had a single address. Since the RFC 2401 SAs are indexed through , you'll need _multiple_ SAs between two machines, even in one direction. So, your formula should be more like 2*M*N*(N-1) where M is the number of addresses per node. Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 13 12:50:11 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DJoAk7029985; Thu, 13 Jun 2002 12:50:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5DJoAkC029984; Thu, 13 Jun 2002 12:50:10 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DJo6k7029977 for ; Thu, 13 Jun 2002 12:50:07 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA27636 for ; Thu, 13 Jun 2002 12:50:12 -0700 (PDT) Received: from qwerty.ssvl.kth.se (qwerty.ssvl.kth.se [192.16.125.203]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA02057 for ; Thu, 13 Jun 2002 13:50:10 -0600 (MDT) Received: from localhost (qwerty.ssvl.kth.se [127.0.0.1]) by qwerty.ssvl.kth.se (8.11.2/8.11.2) with ESMTP id g5DJikY00521; Thu, 13 Jun 2002 21:44:47 +0200 Date: Thu, 13 Jun 2002 21:44:46 +0200 (CEST) From: Alberto Escudero-Pascual X-X-Sender: To: "Bound, Jim" cc: Erik Nordmark , Keith Moore , Thomas Narten , Subject: RE: IESG comments on draft-ietf-ipngwg-default-addr-select-06.txt In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B020B8A1C@tayexc13.americas.cpqcorp.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Jim! If only the users that have concerns about privacy will end up using temp addresses (RFC3041) we will end up with a minority group of techno-geeks or as you call us 'paranoids' highly observable and easy to identify from the crowd. I firmly beleive that RFC3041 should be the default option and only the nodes that require a fixed address should enable that option. 'Privacy' should be the default option. I don't want to be sorrounded by boxes with EUI-64 based addresses and be myself the only one running RFC3041. /aep -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 13 12:57:14 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DJvDk7000028; Thu, 13 Jun 2002 12:57:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5DJvDwk000027; Thu, 13 Jun 2002 12:57:13 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DJv9k7000020 for ; Thu, 13 Jun 2002 12:57:09 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA00304 for ; Thu, 13 Jun 2002 12:57:14 -0700 (PDT) Received: from qwerty.ssvl.kth.se (qwerty.ssvl.kth.se [192.16.125.203]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA05415 for ; Thu, 13 Jun 2002 13:57:10 -0600 (MDT) Received: from localhost (qwerty.ssvl.kth.se [127.0.0.1]) by qwerty.ssvl.kth.se (8.11.2/8.11.2) with ESMTP id g5DJo6Y00564; Thu, 13 Jun 2002 21:50:06 +0200 Date: Thu, 13 Jun 2002 21:50:06 +0200 (CEST) From: Alberto Escudero-Pascual X-X-Sender: To: "Bound, Jim" cc: Erik Nordmark , Keith Moore , Thomas Narten , Subject: RE: IESG comments on draft-ietf-ipngwg-default-addr-select-06.txt In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B020B8A1C@tayexc13.americas.cpqcorp.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Time ago i wrote a paper concerning the observability of RFC3041 and the famous u=0 bit in the address. http://www.it.kth.se/~aep/publications/rvk02-escuderoa.pdf Escudero A, Requirements for unobservability of privacy extension in IPv6. /aep On Thu, 13 Jun 2002, Bound, Jim wrote: > The default should be public. Thats the Internet way. Temp is means Temp. If you want to make a phone call over VoIPv6 and you have a temp address my phone call could be killed or paused waiting for renew. I find that kind of rude. > > Default should be public temp should be an option. > > Also give me one technical reason why it should be temp. > > > /jim > > > -----Original Message----- > > From: Erik Nordmark [mailto:Erik.Nordmark@Sun.COM] > > Sent: Tuesday, June 11, 2002 6:29 PM > > To: Keith Moore > > Cc: Thomas Narten; ipng@sunroof.eng.sun.com > > Subject: Re: IESG comments on > > draft-ietf-ipngwg-default-addr-select-06.txt > > > > > > > I respect the desire for temporary addresses (and AFAIK I > > was one of > > > the first people to raise concerns about embedding tracable > > information > > > in an IPv6 address) but I don't think it's a good idea to > > effectively > > > change the API in a way that would break apps at this late date. > > > > The proposed text is trying to say that temporary addresses > > are preferable > > but that there might be issues (such as applications having problems) > > which consistitute a good enough reason to not follow the default. > > Thus there is significant freedom for implementors to use their best > > judgement based on their knowledge about the applications. > > > > Do you see a problem with this approach? > > > > 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 > > -------------------------------------------------------------------- > > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -- -------------------------------------------------------------------------- A "No" uttered from deepest conviction is better and greater than a "Yes" merely uttered to please, or what is worse, to avoid trouble. Mahatma Gandhi -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 13 12:57:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DJv8k7000018; Thu, 13 Jun 2002 12:57:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5DJv73a000017; Thu, 13 Jun 2002 12:57:07 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DJv4k7000010 for ; Thu, 13 Jun 2002 12:57:04 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA00262 for ; Thu, 13 Jun 2002 12:57:09 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA17182 for ; Thu, 13 Jun 2002 13:57:08 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g5DJv8L17594 for ; Thu, 13 Jun 2002 22:57:08 +0300 Date: Thu, 13 Jun 2002 22:57:07 +0300 (EEST) From: Pekka Savola To: ipng@sunroof.eng.sun.com Subject: back on track? [RE: Review of "Use of /127 Prefix Length Between Routers Considered Harmful"] In-Reply-To: <2B81403386729140A3A899A8B39B046406C81F@server2000.arneill-py.sacramento.ca.us> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 13 Jun 2002, Michel Py wrote: > > Antonio Querubin wrote: > > Concur on both points. Just because one can assign a /64 and get > > millions of addresses on a p2p link doesn't mean one should. > > Furthermore, I can understand the arguments for avoiding /127 or > > /128 but in the cases where the lost capability is a non-issue > > why bother forbidding even those 2 prefix lengths? > > The fact of the matter is that any prefix longer than /64 goes against > [ADDRARCH] Sure .. but let's be pragmatic: people will use them anyway, no matter how forbidden they are. I just try to point out which is should be avoided for their own good. In any case, I think, as Robert Elz put it, this is going off track. Could we stop arguing about best prefix length? I don't think people will get consensus on that, and it isn't the point. I'm trying to come up with a wording that doesn't get us into an endless fight and a slippery slope. I now have a new section: --8<-- 2. Scope of this Memo This memo does not advocate the use of long prefixes, but brings up problems for those that do want to use them, for one reason or another. Detailed discussion on what is the "right" solution is out of the scope; it is not the goal of this memo to try to find the "best" addressing solution for everyone. --8<-- And a note at Solutions paragraph: --8<-- In addition to using a different prefix length, one could also use only link-local addresses or "two /128's". --8<-- (usually they aren't really two /128's, but include stuff like static routes etc. -- I guess that's a good enough wording without going into detail; better wording anyone?). The whole new proposed draft is at: http://www.netcore.fi/pekkas/ietf/draft-savola-ipv6-127-prefixlen-04.txt Is this ok? Also note that this is and an *Informational* document, not even a BCP. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 13 13:01:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DK1Xk7000101; Thu, 13 Jun 2002 13:01:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5DK1XvA000100; Thu, 13 Jun 2002 13:01:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DK1Tk7000093 for ; Thu, 13 Jun 2002 13:01:29 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA23061 for ; Thu, 13 Jun 2002 13:01:34 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA08821; Thu, 13 Jun 2002 13:01:33 -0700 (PDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5DK1SY07170; Thu, 13 Jun 2002 16:01:29 -0400 (EDT) Message-Id: <200206132001.g5DK1SY07170@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Alberto Escudero-Pascual cc: "Bound, Jim" , Erik Nordmark , Keith Moore , Thomas Narten , ipng@sunroof.eng.sun.com Subject: Re: IESG comments on draft-ietf-ipngwg-default-addr-select-06.txt In-reply-to: (Your message of "Thu, 13 Jun 2002 21:44:46 +0200.") Date: Thu, 13 Jun 2002 16:01:28 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I firmly beleive that RFC3041 should be the default option and only the > nodes that require a fixed address should enable that option. 'Privacy' > should be the default option. no. having apps work should be the default. having the reasons for failure be obvious should be the default. having the apps determine whether they need private addresses or not (after all, they're the ones that know) should be the default. I have every confidence that apps that can make use of private addresses, will do so if we give them a uniform API to work with. if you really want privacy to be the default, unplug your network. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 13 13:07:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DK7Xk7000143; Thu, 13 Jun 2002 13:07:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5DK7XZt000142; Thu, 13 Jun 2002 13:07: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.12.4/8.12.4) with ESMTP id g5DK7Nk7000135 for ; Thu, 13 Jun 2002 13:07:23 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA03669 for ; Thu, 13 Jun 2002 13:07:29 -0700 (PDT) Received: from mail8.nc.rr.com (fe8.southeast.rr.com [24.93.67.55]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA11921 for ; Thu, 13 Jun 2002 13:07:28 -0700 (PDT) Received: from mail pickup service by mail8.nc.rr.com with Microsoft SMTPSVC; Thu, 13 Jun 2002 16:03:20 -0400 Received: from ncmx02.mgw.rr.com ([24.93.67.222]) by mail8.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Tue, 11 Jun 2002 00:14:35 -0400 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ncmx02.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5B4EZIa001803 for ; Tue, 11 Jun 2002 00:14:35 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA18439; Mon, 10 Jun 2002 22:15:48 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA08930; Mon, 10 Jun 2002 21:14:04 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5B4CIk7009286; Mon, 10 Jun 2002 21:12:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5B4CIXG009285; Mon, 10 Jun 2002 21:12:18 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5B4CEk7009278 for ; Mon, 10 Jun 2002 21:12:14 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA10028 for ; Mon, 10 Jun 2002 21:12:17 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA25763 for ; Mon, 10 Jun 2002 22:12:16 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5B49On28896; Tue, 11 Jun 2002 00:09:24 -0400 (EDT) Message-Id: <200206110409.g5B49On28896@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Mark.Andrews@isc.org cc: Keith Moore , "Tony Hain" , "Steven M. Bellovin" , "Pekka Savola" , "Ralph Droms" , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-reply-to: (Your message of "Tue, 11 Jun 2002 13:47:49 +1000.") <200206110347.g5B3lnm0004460@drugs.dv.isc.org> Date: Tue, 11 Jun 2002 00:09:24 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > In any > > > case, the only way a DNS server should return a SL in a response is if > > > the query was received on a SL. This is the only reasonable way for the > > > server to know if the answer is usable. > > > > it doesn't work in general, because the query could be from a cache > > that doesn't know anything about SL. > > > > putting limited-scope addrs in DNS is a Bad Idea, period. > > No. > > Putting limited-scope addrs in DNS is a bad idea *unless* > you have a way to uniquely identify the scope. since there is no notion of a scope identifier in the Internet architecure, what you are saying is tantamount to saying that putting limited-scope addresses in the DNS is a bad idea. > Now might be a good time to raise the idea again except I won't > tie it to A6. > > SA > > SA scoped address > scopename is a domainname choosen to be globally unique. > global addresses have a scopename of ".". > > the conversion from scopename to scopeid / zoneid is a > *local* resolution problem for the machine. great - so let's add a lot of complexity to every application just so we can get no additional functionality and reduced reliability. let's stamp out SL addresses, now. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 13 13:28:40 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DKSek7000659; Thu, 13 Jun 2002 13:28:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5DKSeO0000658; Thu, 13 Jun 2002 13:28:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DKSZk7000651 for ; Thu, 13 Jun 2002 13:28:35 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA28592 for ; Thu, 13 Jun 2002 13:28:41 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA18377 for ; Thu, 13 Jun 2002 14:30:27 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5DKSXY07245; Thu, 13 Jun 2002 16:28:33 -0400 (EDT) Message-Id: <200206132028.g5DKSXY07245@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Alberto Escudero-Pascual cc: Keith Moore , "Bound, Jim" , Erik Nordmark , Thomas Narten , ipng@sunroof.eng.sun.com Subject: Re: IESG comments on draft-ietf-ipngwg-default-addr-select-06.txt In-reply-to: (Your message of "Thu, 13 Jun 2002 22:24:20 +0200.") Date: Thu, 13 Jun 2002 16:28:33 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I have also the confidence that apps that require the use of PUBLIC > fixed addresses, will do so if we give them a uniform API to work with. we've had that API for 20+ years now. what we're arguing about is whether to change it. I say "no". -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 13 13:30:14 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DKUDk7000679; Thu, 13 Jun 2002 13:30:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5DKUDvh000678; Thu, 13 Jun 2002 13:30:13 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DKU9k7000671 for ; Thu, 13 Jun 2002 13:30:09 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA12778 for ; Thu, 13 Jun 2002 13:30:15 -0700 (PDT) Received: from qwerty.ssvl.kth.se (qwerty.ssvl.kth.se [192.16.125.203]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA20180 for ; Thu, 13 Jun 2002 14:30:14 -0600 (MDT) Received: from localhost (qwerty.ssvl.kth.se [127.0.0.1]) by qwerty.ssvl.kth.se (8.11.2/8.11.2) with ESMTP id g5DKOKY00614; Thu, 13 Jun 2002 22:24:20 +0200 Date: Thu, 13 Jun 2002 22:24:20 +0200 (CEST) From: Alberto Escudero-Pascual X-X-Sender: To: Keith Moore cc: "Bound, Jim" , Erik Nordmark , Thomas Narten , Subject: Re: IESG comments on draft-ietf-ipngwg-default-addr-select-06.txt In-Reply-To: <200206132001.g5DK1SY07170@astro.cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I have also the confidence that apps that require the use of PUBLIC fixed addresses, will do so if we give them a uniform API to work with. /aep On Thu, 13 Jun 2002, Keith Moore wrote: > > I firmly beleive that RFC3041 should be the default option and only the > > nodes that require a fixed address should enable that option. 'Privacy' > > should be the default option. > > no. > having apps work should be the default. > having the reasons for failure be obvious should be the default. > having the apps determine whether they need private addresses or not > (after all, they're the ones that know) should be the default. > > I have every confidence that apps that can make use of private > addresses, will do so if we give them a uniform API to work with. > > if you really want privacy to be the default, unplug your network. > > Keith > -- -------------------------------------------------------------------------- A "No" uttered from deepest conviction is better and greater than a "Yes" merely uttered to please, or what is worse, to avoid trouble. Mahatma Gandhi -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 13 14:27:05 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DLR4k7000969; Thu, 13 Jun 2002 14:27:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5DLR4AF000968; Thu, 13 Jun 2002 14:27:04 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DLR1k7000959 for ; Thu, 13 Jun 2002 14:27:01 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA18397 for ; Thu, 13 Jun 2002 14:27:04 -0700 (PDT) Received: from emerson.torrentnet.com (emerson.torrentnet.com [198.78.51.110]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA18620 for ; Thu, 13 Jun 2002 15:28:50 -0600 (MDT) Received: from imperial.torrentnet.com (imperial.torrentnet.com [198.78.51.109]) by emerson.torrentnet.com (8.11.2/8.11.2) with ESMTP id g5DLQVG82837; Thu, 13 Jun 2002 17:26:31 -0400 (EDT) Received: from castillo.torrentnet.com (castillo.torrentnet.com [4.18.161.34]) by imperial.torrentnet.com (8.11.2/8.11.2) with ESMTP id g5DLQQH35095; Thu, 13 Jun 2002 17:26:27 -0400 (EDT) Received: from castillo.torrentnet.com (localhost.torrentnet.com [127.0.0.1]) by castillo.torrentnet.com (8.9.3/8.9.3) with ESMTP id RAA01182; Thu, 13 Jun 2002 17:26:21 -0400 (EDT) Message-Id: <200206132126.RAA01182@castillo.torrentnet.com> X-Mailer: exmh version 2.0.2 2/24/98 To: "Bound, Jim" cc: "Steven M. Bellovin" , "Pekka Savola" , "Ralph Droms" , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-reply-to: Your message of "Thu, 13 Jun 2002 08:53:49 EDT." <9C422444DE99BC46B3AD3C6EAFC9711B020B8A10@tayexc13.americas.cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 13 Jun 2002 17:26:21 -0400 From: Steve Blake Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim Bound wrote: > with all due respect. rfc 1918 was a hack and never would pass the IESG > today IMO they are doing a far better job these days causing us to detail > our network views and development of protocols. 1918 has wrecked the > Internet. Ripping site-locals out of the specs will not prevent folks who perceive the need for stable addresses (e.g., for internal use) from allocating them, especially given that ~7/8 of the IPv6 address space is held in reserve. Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven L. Blake Ericsson IP Infrastructure 919-472-9913 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 13 14:54:05 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DLs5k7001059; Thu, 13 Jun 2002 14:54:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5DLs5if001058; Thu, 13 Jun 2002 14:54:05 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DLs1k7001051 for ; Thu, 13 Jun 2002 14:54:01 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA29396 for ; Thu, 13 Jun 2002 14:54:06 -0700 (PDT) From: rbrabson@us.ibm.com Received: from mail8.nc.rr.com (fe8.southeast.rr.com [24.93.67.55]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA19085 for ; Thu, 13 Jun 2002 14:54:05 -0700 (PDT) Received: from mail pickup service by mail8.nc.rr.com with Microsoft SMTPSVC; Thu, 13 Jun 2002 16:52:54 -0400 Received: from ncmx01.mgw.rr.com ([24.93.67.251]) by mail8.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Mon, 10 Jun 2002 13:27:35 -0400 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ncmx01.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5AHRYtH005352 for ; Mon, 10 Jun 2002 13:27:34 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA23874; Mon, 10 Jun 2002 11:23:08 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA29851; Mon, 10 Jun 2002 10:22:58 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5AHKrk7007530; Mon, 10 Jun 2002 10:20:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5AHKr0c007529; Mon, 10 Jun 2002 10:20:53 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5AHKok7007522 for ; Mon, 10 Jun 2002 10:20:50 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA15435 for ; Mon, 10 Jun 2002 10:20:53 -0700 (PDT) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA09670 for ; Mon, 10 Jun 2002 10:20:52 -0700 (PDT) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.us.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.12.2/8.12.2) with ESMTP id g5AHKpRY047420; Mon, 10 Jun 2002 13:20:51 -0400 Received: from d04nm200.raleigh.ibm.com (d04nm200.raleigh.ibm.com [9.67.226.57]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5AHKp695150; Mon, 10 Jun 2002 13:20:51 -0400 Subject: RE: Multiple Sites and DNS (was IPv6 Scoped Addresses and Routing Protocols) To: "Tony Hain" Cc: ipng@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Mon, 10 Jun 2002 13:20:41 -0400 X-MIMETrack: Serialize by Router on D04NM200/04/M/IBM(Build M13TT_05222002 Pre-release 2|May 22, 2002) at 06/10/2002 13:20:50 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=0ABBE147DFC271828f9e8a93df938690918c0ABBE147DFC27182" Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --0__=0ABBE147DFC271828f9e8a93df938690918c0ABBE147DFC27182 Content-type: text/plain; charset=US-ASCII On Sunday, 06/09/2002 at 11:00 MST, "Tony Hain" wrote: > THere is a mismatch between the DNS perception of 'site' and the > site-local definition of 'site'. The DNS version is much stricter about > physical separation, but there shouldn't be a requirement that DNS > servers for a segment of an AS have to be in differrent SL regions. It > sounds like there is more to do on the DNS operations document... In any > case, the only way a DNS server should return a SL in a response is if > the query was received on a SL. This is the only reasonable way for the > server to know if the answer is usable. If the DNS servers for a given > set of hosts are split across multiple SL zones, then some of the > answers will be global. This is logically the right thing to do from the > DNS query/response perspective, but from the operations perspective, the > servers shouldn't be in separate SL zones. If a particular network > doesn't want to add to the DNS infrastructure, there is no requirement > to populate it with SL addresses. If the routers don't announce them in > the RA, and they aren't in the DNS, they don't get used. That does not > mean we should get rid of them, because smaller organizations will > typically find them useful to minimize the impact of changing providers. The DNS issues surrounding site-local addresses concern me far more than routing issues which have been discussed. I tried to imagine how DNS would work given what is described above, especially for the case where a host is attached to multiple sites. I don't think this is just an operational problem, but requires new standards and new code at both the resolvers as well as name servers in order for it to work. The more I thought about it, the more I liked the idea of site-local addresses disappearing from the architecture or, at a minimum, a host being restricted to connecting to a single site at any given time. Imagine a host (Host1) which is directly connected to multiple sites, both of which are using site-local addressing. When connecting to a 2nd host (Host2), Host2 may also be connected to multiple sites - perhaps even the same two as Host1. Host1 / \ / \ SiteA SiteB \ / \ / Host2 | | SiteC When Host1 queries DNS for the addresses for Host2, what addresses should it receive back? I'd think Host1 would want Host2's global addresses, site-local addresses for interfaces attached to SiteA, and site-local addresses for interfaces attached to SiteB. Since Host1 is not attached to SiteC, it would not want to receive site-local addresses for SiteC. In each case, Host1 must know the site in which the site-local addresses returned are valid, so that it will only forward packets using the destination site-local address into the site in which the address is valid. Host1 may also want to restrict the results returned so that it only receives site-local addresses for a single site (say SiteA), and not receive any of Host2's site-local addresses for SiteB. >From what I read above, in order for Host1 to receive all of Host2's addresses, it would need to send two queries to the DNS name server - one via SiteA and one via SiteB. In each case, in order to receive a site-local address the destination address for the DNS name server would need to be a site-local address for the site over which the query is sent. In order to receive the packets with a site-local destination address, the DNS name server must be directly connected to each site that a host in a zone for which it is authoritative is also connected. For instance, the each authoritative name server for Host2 must be connected to SiteA, SiteB, and SiteC, while the authoritative name server for Host1 only needs to be connected to SiteA and SiteB. In order for a client to receive all IP addresses for a given host, the client must be directly attached to each site to which the host is also attached, as it cannot receive any site-local addresses for sites to which it is not attached. That is, to receive all of Host2's addresses, the client must be directly connected to SiteA, SiteB, and SiteC. For a "typical" application, only receiving site-local addresses for sites to which the client is attached should be fine. For DNS management tools (nslookup, dig, etc.) it might not be. When performing a zone transfer, the primary name server needs to somehow tell the secondary name servers which zone a site-local address for a host is associated with. This way, the secondary name server can restrict which site-local addresses it returns to a client. When referring a client to another name server, the referring name server must know if the client and new target name server are in the same site. If so, the address of the new name server should be a site-local address for the site to which both are directly attached (if the name server has a site-local address for that site); otherwise, it should be a global address. When returning the sockaddr_in6 structures to the requesting application, the resolver must fill in the sin6_scope_id field for any site-local addresses based on the site to which the DNS query is sent. This allows the TCP/IP stack to know the site in which the site-local address is valid, and to route packets using the site-local address to the site in which the address is valid. When registering IP addresses, a host must ensure that it only register site-local addresses via the site in which the site-local address is defined, while global addresses may be registered via any site. This way, the DNS name server can know which site-local addresses are associated with which sites. Roy --0__=0ABBE147DFC271828f9e8a93df938690918c0ABBE147DFC27182 Content-type: text/html; charset=US-ASCII Content-Disposition: inline On Sunday, 06/09/2002 at 11:00 MST, "Tony Hain" <alh-ietf@tndh.net> wrote:
> THere is a mismatch between the DNS perception of 'site' and the
> site-local definition of 'site'. The DNS version is much stricter about
> physical separation, but there shouldn't be a requirement that DNS
> servers for a segment of an AS have to be in differrent SL regions. It
> sounds like there is more to do on the DNS operations document... In any
> case, the only way a DNS server should return a SL in a response is if
> the query was received on a SL. This is the only reasonable way for the
> server to know if the answer is usable. If the DNS servers for a given
> set of hosts are split across multiple SL zones, then some of the
> answers will be global. This is logically the right thing to do from the
> DNS query/response perspective, but from the operations perspective, the
> servers shouldn't be in separate SL zones. If a particular network
> doesn't want to add to the DNS infrastructure, there is no requirement
> to populate it with SL addresses. If the routers don't announce them in
> the RA, and they aren't in the DNS, they don't get used. That does not
> mean we should get rid of them, because smaller organizations will
> typically find them useful to minimize the impact of changing providers.

The DNS issues surrounding site-local addresses concern me far more than
routing issues which have been discussed.  I tried to imagine how DNS
would work given what is described above, especially for the case where
a host is attached to multiple sites.  I don't think this is just an
operational problem, but requires new standards and new code at both the
resolvers as well as name servers in order for it to work.  The more I
thought about it, the more I liked the idea of site-local addresses
disappearing from the architecture or, at a minimum, a host being
restricted to connecting to a single site at any given time.

Imagine a host (Host1) which is directly connected to multiple sites, both
of which are using site-local addressing.  When connecting to a 2nd host
(Host2), Host2 may also be connected to multiple sites - perhaps even the
same two as Host1.

            Host1
           /     \
          /       \
       SiteA     SiteB
          \        /
           \      /
            Host2
              |
              |
            SiteC

When Host1 queries DNS for the addresses for Host2, what addresses should
it receive back?  I'd think Host1 would want Host2's global addresses,
site-local addresses for interfaces attached to SiteA, and site-local
addresses for interfaces attached to SiteB.  Since Host1 is not attached
to SiteC, it would not want to receive site-local addresses for SiteC.  In
each case, Host1 must know the site in which the site-local addresses
returned are valid, so that it will only forward packets using the
destination site-local address into the site in which the address is
valid.  Host1 may also want to restrict the results returned so that it
only receives site-local addresses for a single site (say SiteA), and not
receive any of Host2's site-local addresses for SiteB.

From what I read above, in order for Host1 to receive all of Host2's
addresses, it would need to send two queries to the DNS name server - one
via SiteA and one via SiteB.  In each case, in order to receive a
site-local address the destination address for the DNS name server would
need to be a site-local address for the site over which the query is sent.

In order to receive the packets with a site-local destination address, the
DNS name server must be directly connected to each site that a host in a
zone for which it is authoritative is also connected.  For instance, the
each authoritative name server for Host2 must be connected to SiteA, SiteB,
and SiteC, while the authoritative name server for Host1 only needs to be
connected to SiteA and SiteB.

In order for a client to receive all IP addresses for a given host, the
client must be directly attached to each site to which the host is also
attached, as it cannot receive any site-local addresses for sites to
which it is not attached.  That is, to receive all of Host2's addresses,
the client must be directly connected to SiteA, SiteB, and SiteC.  For
a "typical" application, only receiving site-local addresses for sites
to which the client is attached should be fine.  For DNS management tools
(nslookup, dig, etc.) it might not be.

When performing a zone transfer, the primary name server needs to somehow
tell the secondary name servers which zone a site-local address for a
host is associated with.  This way, the secondary name server can restrict
which site-local addresses it returns to a client.

When referring a client to another name server, the referring name server
must know if the client and new target name server are in the same site.  
If so, the address of the new name server should be a site-local address
for the site to which both are directly attached (if the name server has
a site-local address for that site); otherwise, it should be a global
address.

When returning the sockaddr_in6 structures to the requesting application,
the resolver must fill in the sin6_scope_id field for any site-local
addresses based on the site to which the DNS query is sent.  This
allows the TCP/IP stack to know the site in which the site-local address
is valid, and to route packets using the site-local address to the
site in which the address is valid.

When registering IP addresses, a host must ensure that it only register
site-local addresses via the site in which the site-local address is
defined, while global addresses may be registered via any site.  This
way, the DNS name server can know which site-local addresses are
associated with which sites.

Roy --0__=0ABBE147DFC271828f9e8a93df938690918c0ABBE147DFC27182-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Jun 13 15:24:27 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DMORk7001741; Thu, 13 Jun 2002 15:24:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5DMORlF001740; Thu, 13 Jun 2002 15:24:27 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DMOMk7001730 for ; Thu, 13 Jun 2002 15:24:22 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA13242 for ; Thu, 13 Jun 2002 15:24:27 -0700 (PDT) Received: from mail8.nc.rr.com ([24.93.67.55]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA11239 for ; Thu, 13 Jun 2002 16:24:26 -0600 (MDT) Received: from mail pickup service by mail8.nc.rr.com with Microsoft SMTPSVC; Thu, 13 Jun 2002 18:17:28 -0400 Received: from ncmx02.mgw.rr.com ([24.93.67.222]) by mail8.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Wed, 12 Jun 2002 08:42:54 -0400 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ncmx02.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5CCgra2005103 for ; Wed, 12 Jun 2002 08:42:54 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA14520; Wed, 12 Jun 2002 06:44:18 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA21578; Wed, 12 Jun 2002 05:42:31 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5CCevk7013772; Wed, 12 Jun 2002 05:40:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5CCevUC013771; Wed, 12 Jun 2002 05:40:57 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5CCerk7013764 for ; Wed, 12 Jun 2002 05:40:53 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA21189 for ; Wed, 12 Jun 2002 05:40:55 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA16064; Wed, 12 Jun 2002 06:40:51 -0600 (MDT) Received: from localhost ([3ffe:501:100f:1048:fd5e:6e52:ab0f:8f5d]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g5CCek894158; Wed, 12 Jun 2002 21:40:46 +0900 (JST) Date: Wed, 12 Jun 2002 21:40:50 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Keith Moore Cc: Erik Nordmark , Thomas Narten , ipng@sunroof.eng.sun.com Subject: Re: IESG comments on draft-ietf-ipngwg-default-addr-select-06.txt In-Reply-To: References: <200206112320.g5BNKZn27758@astro.cs.utk.edu> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 24 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Wed, 12 Jun 2002 17:39:54 +0900, >>>>> JINMEI Tatuya said: >> I've got some other problems with the document also - specifically >> the idea that link-local addresses are preferable to global addresses. > Please let me confirm: are you referring to Rule 2 of source address > selection? Perhaps you are talking about Rule 8 of destination address selection: Rule 8: Prefer smaller scope. If Scope(DA) < Scope(DB), then prefer DA. Similarly, if Scope(DA) > Scope(DB), then prefer DB. This rule may be sometimes controversial, but I personally think it is reasonable, because we can (in theory) expect better reachability for a smaller scope of destinations. This is especially true for a link-local destination where we don't need L3 routing. 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 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 13 15:28:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DMSXk7002139; Thu, 13 Jun 2002 15:28:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5DMSXWD002138; Thu, 13 Jun 2002 15:28:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DMSSk7002125 for ; Thu, 13 Jun 2002 15:28:28 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA10266 for ; Thu, 13 Jun 2002 15:28:33 -0700 (PDT) Received: from tndh.net (evrtwa1-ar8-4-65-028-011.evrtwa1.dsl-verizon.net [4.65.28.11]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA00858 for ; Thu, 13 Jun 2002 16:28:32 -0600 (MDT) Received: from eagleswings (127.0.0.1) by localhost (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Thu, 13 Jun 2002 15:29:13 -0700 From: "Tony Hain" To: "Keith Moore" , "Alberto Escudero-Pascual" Cc: "Bound, Jim" , "Erik Nordmark" , "Thomas Narten" , Subject: RE: IESG comments on draft-ietf-ipngwg-default-addr-select-06.txt Date: Thu, 13 Jun 2002 15:27:38 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <200206132028.g5DKSXY07245@astro.cs.utk.edu> X-Mimeole: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith, get off the soap box... IPv6 requires a new API, so there is no valid argument that we are not changing it. If you want to argue that we should minimize the changes, I would agree. Tony > -----Original Message----- > From: owner-ipng@sunroof.eng.sun.com > [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Keith Moore > Sent: Thursday, June 13, 2002 1:29 PM > To: Alberto Escudero-Pascual > Cc: Keith Moore; Bound, Jim; Erik Nordmark; Thomas Narten; > ipng@sunroof.eng.sun.com > Subject: Re: IESG comments on > draft-ietf-ipngwg-default-addr-select-06.txt > > > > I have also the confidence that apps that require the use of PUBLIC > > fixed addresses, will do so if we give them a uniform API > to work with. > > we've had that API for 20+ years now. what we're arguing about is > whether to change it. I say "no". > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 13 15:32:38 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DMWck7002242; Thu, 13 Jun 2002 15:32:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5DMWceM002241; Thu, 13 Jun 2002 15:32:38 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DMWXk7002231 for ; Thu, 13 Jun 2002 15:32:33 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA16616 for ; Thu, 13 Jun 2002 15:32:38 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA05959 for ; Thu, 13 Jun 2002 15:32:37 -0700 (PDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5DMVEY08270; Thu, 13 Jun 2002 18:31:14 -0400 (EDT) Message-Id: <200206132231.g5DMVEY08270@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Steve Blake cc: "Bound, Jim" , "Steven M. Bellovin" , "Pekka Savola" , "Ralph Droms" , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-reply-to: (Your message of "Thu, 13 Jun 2002 17:26:21 EDT.") <200206132126.RAA01182@castillo.torrentnet.com> Date: Thu, 13 Jun 2002 18:31:14 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Ripping site-locals out of the specs will not prevent folks who perceive > the need for stable addresses (e.g., for internal use) from allocating them, > especially given that ~7/8 of the IPv6 address space is held in reserve. the problem of course is that such addresses are not for internal use forever. even if the net never connects to the public internet, the chance that the net will connect to some other network that does connect to the public internet are fairly good, and this invites potential address collisions. (though less likely in v6 than in v4, where most nets use RFC 1918 space...) seems like you really want some address space that - is unique - isn't provider-based - can be routed between private nets Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 13 15:34:51 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DMYpk7002291; Thu, 13 Jun 2002 15:34:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5DMYpGi002290; Thu, 13 Jun 2002 15:34:51 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DMYkk7002283 for ; Thu, 13 Jun 2002 15:34:46 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA17496 for ; Thu, 13 Jun 2002 15:34:51 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA06902 for ; Thu, 13 Jun 2002 16:34:50 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 3BA7E4B24; Fri, 14 Jun 2002 07:34:46 +0900 (JST) To: "Tony Hain" Cc: ipng@sunroof.eng.sun.com In-reply-to: alh-ietf's message of Thu, 13 Jun 2002 15:27:38 MST. 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: IESG comments on draft-ietf-ipngwg-default-addr-select-06.txt From: itojun@iijlab.net Date: Fri, 14 Jun 2002 07:34:46 +0900 Message-ID: <3071.1024007686@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >get off the soap box... IPv6 requires a new API, so there is no valid >argument that we are not changing it. If you want to argue that we >should minimize the changes, I would agree. no more changes, *please*. we have spent more than reasonable amount of years to settle down to RFC2553/bis. and people are now using it. I would quote words from sendmail people - "first gethostbyname2, then gethostbyname3, then getipnodebyname, then you want us to switch to getaddrinfo? how can we know that it will be the final one?" I was so embarrassed when i heard this. 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 Thu Jun 13 15:34:44 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DMYTk7002276; Thu, 13 Jun 2002 15:34:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5DMYSsm002275; Thu, 13 Jun 2002 15:34:28 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DMYLk7002257 for ; Thu, 13 Jun 2002 15:34:21 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA04723 for ; Thu, 13 Jun 2002 15:34:25 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA06726 for ; Thu, 13 Jun 2002 16:34:25 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5DMYDY08295; Thu, 13 Jun 2002 18:34:16 -0400 (EDT) Message-Id: <200206132234.g5DMYDY08295@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Tony Hain" cc: "Keith Moore" , "Alberto Escudero-Pascual" , "Bound, Jim" , "Erik Nordmark" , "Thomas Narten" , ipng@sunroof.eng.sun.com Subject: Re: IESG comments on draft-ietf-ipngwg-default-addr-select-06.txt In-reply-to: (Your message of "Thu, 13 Jun 2002 15:27:38 PDT.") Date: Thu, 13 Jun 2002 18:34:13 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > get off the soap box... IPv6 requires a new API, so there is no valid > argument that we are not changing it. If you want to argue that we > should minimize the changes, I would agree. believe it or not there are already lots of progams using the v6 API... many of which were very slight modifications to v4 programs. I'm happy that IESG has decided not to insist on temp addresses as the default and has backed the idea that there should be an API to request them. Now, who's going to define the API extension? Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 13 15:38:22 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DMcLk7002356; Thu, 13 Jun 2002 15:38:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5DMcLIj002355; Thu, 13 Jun 2002 15:38:21 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DMcIk7002348 for ; Thu, 13 Jun 2002 15:38:18 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA13790 for ; Thu, 13 Jun 2002 15:38:23 -0700 (PDT) Received: from tndh.net (evrtwa1-ar8-4-65-028-011.evrtwa1.dsl-verizon.net [4.65.28.11]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA05482 for ; Thu, 13 Jun 2002 16:38:22 -0600 (MDT) Received: from eagleswings (127.0.0.1) by localhost (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Thu, 13 Jun 2002 15:39:04 -0700 From: "Tony Hain" To: "Keith Moore" , "Alberto Escudero-Pascual" Cc: "Bound, Jim" , "Erik Nordmark" , "Thomas Narten" , Subject: RE: IESG comments on draft-ietf-ipngwg-default-addr-select-06.txt Date: Thu, 13 Jun 2002 15:37:29 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <200206132001.g5DK1SY07170@astro.cs.utk.edu> X-Mimeole: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith Moore wrote: > > > I firmly beleive that RFC3041 should be the default option > and only the > > nodes that require a fixed address should enable that > option. 'Privacy' > > should be the default option. > > no. > having apps work should be the default. > having the reasons for failure be obvious should be the default. > having the apps determine whether they need private addresses or not > (after all, they're the ones that know) should be the default. > Your logic doesn't make sense. In fact the app that needs a fixed address should know that, and one that can live with a variable one probably has no idea what address is being used anyway. > I have every confidence that apps that can make use of private > addresses, will do so if we give them a uniform API to work with. > Any app that doesn't need a forward or reverse record in DNS will work with a private address, why do they need a special API. What you are looking for is a simple way during address selection to know which address is recorded in DNS. > if you really want privacy to be the default, unplug your network. That is not what private addresses are for and you know it. Rather than bash the new concept for being different, why not provide a constructive proposal like a flag on the local address list to know which have been recorded in DNS? Tony > > Keith > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 13 15:43:47 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DMhkk7002423; Thu, 13 Jun 2002 15:43:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5DMhkcU002422; Thu, 13 Jun 2002 15:43:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DMhgk7002412 for ; Thu, 13 Jun 2002 15:43:42 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA08149 for ; Thu, 13 Jun 2002 15:43:47 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA25494; Thu, 13 Jun 2002 16:45:33 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5DMhfY08343; Thu, 13 Jun 2002 18:43:41 -0400 (EDT) Message-Id: <200206132243.g5DMhfY08343@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Tony Hain" cc: "Keith Moore" , "Alberto Escudero-Pascual" , "Bound, Jim" , "Erik Nordmark" , "Thomas Narten" , ipng@sunroof.eng.sun.com Subject: Re: IESG comments on draft-ietf-ipngwg-default-addr-select-06.txt In-reply-to: (Your message of "Thu, 13 Jun 2002 15:37:29 PDT.") Date: Thu, 13 Jun 2002 18:43:41 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Your logic doesn't make sense. In fact the app that needs a fixed > address should know that, and one that can live with a variable one > probably has no idea what address is being used anyway. the problem is there's a large body of code out there written to assume fixed addresses because that's been the API for 20+ years. if we were starting from scratch I might agree with you. > > I have every confidence that apps that can make use of private > > addresses, will do so if we give them a uniform API to work with. > > > > Any app that doesn't need a forward or reverse record in DNS will work > with a private address, uh, no. DNS isn't the only way that apps get addresses, and some apps need stable addresses whether or not they're listed in DNS. > What you are > looking for is a simple way during address selection to know which > address is recorded in DNS. no. not even close. > > if you really want privacy to be the default, unplug your network. > > That is not what private addresses are for and you know it. Rather than > bash the new concept for being different, why not provide a constructive > proposal like a flag on the local address list to know which have been > recorded in DNS? because it wouldn't solve the problem. I already made a constructive proposal that does solve the problem. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 13 16:01:51 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DN1pk7002499; Thu, 13 Jun 2002 16:01:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5DN1pno002498; Thu, 13 Jun 2002 16:01:51 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DN1nk7002491 for ; Thu, 13 Jun 2002 16:01:49 -0700 (PDT) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g5DN1loR005394 for ; Thu, 13 Jun 2002 16:01:47 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g5DN1l7E005393 for ipng@sunroof.eng.sun.com; Thu, 13 Jun 2002 16:01:47 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5D2BHk7017652 for ; Wed, 12 Jun 2002 19:11:18 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA01803 for ; Wed, 12 Jun 2002 19:11:21 -0700 (PDT) Received: from mail5.nc.rr.com (fe5.southeast.rr.com [24.93.67.52]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA10095 for ; Wed, 12 Jun 2002 20:13:04 -0600 (MDT) Received: from nc.rr.com ([24.162.252.183]) by mail5.nc.rr.com with Microsoft SMTPSVC(5.5.1877.687.68); Wed, 12 Jun 2002 22:11:09 -0400 Message-ID: <3D07FE90.1950DC5E@nc.rr.com> Date: Wed, 12 Jun 2002 22:08:16 -0400 From: Brian Haberman X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Michel Py CC: Alain Durand , ipng@sunroof.eng.sun.com Subject: Re: Reviewof"Use of /127 Prefix Length Between Routers Considered Harmful" References: <2B81403386729140A3A899A8B39B046405E0F9@server2000.arneill-py.sacramento.ca.us> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Place this in context: what we are talking about here is either a > router-to-router tunnel or a router-to-router link. Guess what: there is > likely to be a routing protocol there. Could you explain me how you > configure RIP when the other router is not on the same subnet? In all of my labs where I have had p2p links like that, both ends of the link only have link-local addresses and RIPng works just fine. IPv6 cloud --- RTR1 --- p2p --- RTR2 ---IPv6 cloud Each router has a global address and a link-local address on the cloud interfaces and link-local addresses on the p2p. RIPng running and reachability everywhere. 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 Jun 13 16:02:18 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DN2Hk7002509; Thu, 13 Jun 2002 16:02:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5DN2HHg002508; Thu, 13 Jun 2002 16:02:17 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DN2Fk7002501 for ; Thu, 13 Jun 2002 16:02:15 -0700 (PDT) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g5DN2DoR005402 for ; Thu, 13 Jun 2002 16:02:13 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g5DN2Dhf005401 for ipng@sunroof.eng.sun.com; Thu, 13 Jun 2002 16:02:13 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DCSCk7024028 for ; Thu, 13 Jun 2002 05:28:12 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA07539 for ; Thu, 13 Jun 2002 05:28:16 -0700 (PDT) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA23986 for ; Thu, 13 Jun 2002 05:28:16 -0700 (PDT) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id A8C3D3A50; Thu, 13 Jun 2002 08:28:15 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 13 Jun 2002 08:28:15 -0400 x-mimeole: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols Date: Thu, 13 Jun 2002 08:28:15 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B8A01@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Fwd: IPv6 Scoped Addresses and Routing Protocols Thread-Index: AcINitl+x++SsX3FSh+8PSJoRc6khQFSr3eQ From: "Bound, Jim" To: "Randall Stewart" , "Steven M. Bellovin" Cc: X-OriginalArrivalTime: 13 Jun 2002 12:28:15.0619 (UTC) FILETIME=[CA998D30:01C212D5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5DCSCk7024029 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk As all know I wanted these dreaded site-locals gone since we invented them in IPv6. This has been discussed before if we can revisit this again that is a very good thing. Steve and Randy are 100% correct. I would also add they break lots of stuff. /jim > -----Original Message----- > From: Randall Stewart [mailto:randall@stewart.chicago.il.us] > Sent: Thursday, June 06, 2002 2:46 PM > To: Steven M. Bellovin > Cc: ipng@sunroof.eng.sun.com > Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols > > > Steve: > > Having implemented SCTP and IPv6 together I could not agree with you > more. > I know in our work on scoping of addresses it got very very tricky on > attempting to figure out which set of addresses to tell the other > SCTP endpoint about to avoid black hole conditions. So in the end > the only way you could handle it is if the destination address > of your INIT packet (consider it a SYN) was TO a site-local then > you could include your site-locals... This means that if the user > sent the INIT to the global address then the peer NEVER gets informed > of site locals.... maybe something not desired but unavoidable... > > > Now with the new addition of site-scoping even this will break since > one must all of a sudden be cognizant of what site the peer is on and > only send a sub-set of the site-local addresses (gak!!). > > In all of this I have tried to figure out what use these site locals > are? > > If I have a global address why would I ever want to use a site-local? > If no global-addresses are available and I am not attached to the > public inter-net I could possibly see using a site-local.. maybe but > I would think this is more the 'dentists' office scenario where in > link-local will suffice... If the 'dentist' wants to talk to the > insurance company I doubt that it would be in the 'dentist's' site... > so he would need a connection to the global address space... and the > problem goes away.... > > Only in a large company would I see a site-local being applied.. but > in such a company why not just use a global address? What does it > buy me to have this extra address? I already know my assigned address > space... I can have my company border routers prevent spoofing of > my address into my network... so I can use the source being the > global address that is assigned to me to "know" that I am in the > same company...if thats what I want... > > I may be able to see (maybe) that a large company wants to NOT > connect to the global address space... so here site-local MIGHT be > something I could use... but adding in scoped site-locals I just can't > see a use for... It just causes all sorts of fun problems. > > I would much rather see the company that is NOT going to want to > connect to the global address space just have a way to get some > global address space.... I realize with the current number scheme > this is not possible so maybe a site-local does make sense in > this one strange instance... but in this case the company > does not need > to worry about global mixed with site-local :> > > So maybe site-local (if allowed) should only be valid if NO global > address is defined :> > > R > > "Steven M. Bellovin" wrote: > > > > In message > <4.2.2.20020605134805.0245def0@mail.windriver.com>, Margaret Wasserm > > an writes: > > > > > >I sent the attached message to the routing area discussion > list. I thought th > > >at people on > > >the IPv6 list might be interested in this discussion, so I > will forward a mess > > >age containing > > >the responses after this one. I suppose I just should > have cc:ed the IPv6 gro > > >up in the > > >first place... > > > > > > > My strong preference would be to drop site-local addresses > completely. > > I think they're an administrative and technical nightmare. > > > > Margaret has pointed out that our routing protocols don't support > > site-local addresses. The only alternative suggestion I've > seen thus > > far is to run multiple instances of, say, OSPF on all > routers within a > > site. But how are these distinguished from each other? > OSPF runs with > > an IP protocol number, not a port number, so we can't have multiple > > instances that way. And RFC 2740's specification of the necessary > > multicast addresses notes that they're all link-local. > Still, there's > > apparently running code; I look forward to seeing the details. > > > > I'm very concerned about DNS entries. When should a DNS > server -- or a > > caching resolver -- return a site-local address? (If the DNS never > > returns such things, they're useless.) One suggestion I've heard is > > two-faced DNS servers -- only return site-local information if the > > querier is within the same site. Apart from the fact that I have no > > idea how that determination can be made -- surely no one > will suggest > > putting site-local addresses into NS records -- RFC 2182 > (aka BCP 0016) > > specifically warns against putting all secondary servers for a zone > > within a site: > > > > Consequently, placing all servers at the local site, > while easy to > > arrange, and easy to manage, is not a good policy. > Should a single > > link fail, or there be a site, or perhaps even building, or room, > > power failure, such a configuration can lead to all servers being > > disconnected from the Internet. > > > > Secondary servers must be placed at both topologically and > > geographically dispersed locations on the Internet, to > minimise the > > likelihood of a single failure disabling all of them. > > > > Etc. > > > > There will also be a lot of unnecessary pain in DNS maintenance as > > "sites" are split or merged. v6 is designed to support > easy renumbering > > of global addresses, but those are designed to reflect topology. > > Site-local addresses do not, which increases the probability of > > address space collision during a merger. > > > > Philosophically, I think that the problem is that a "site" is a new > > (and deliberately poorly defined) concept. The DNS is > designed to work > > with administrative boundaries, while routing and addressing reflect > > topology. We now have a new concept that is neither > administrative nor > > topological, but one that must be supported by administrative and > > topological mechanisms. > > > > Finally -- and perhaps least important -- I'm not sure what problem > > they solve. I can understand site-local multicast, since (most) > > inter-site traffic traverses links that are not inherently > > multicast-capable. There is thus considerable extra > expense. But why > > do I need site-local unicast addresses? > > > > --Steve Bellovin, > http://www.research.att.com/~smb (me) > > http://www.wilyhacker.com ("Firewalls" book) > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > > -- > Randall R. Stewart > randall@stewart.chicago.il.us 815-342-5222 (cell phone) > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Jun 13 16:03:00 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DN30k7002524; Thu, 13 Jun 2002 16:03:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5DN2xMV002523; Thu, 13 Jun 2002 16:02:59 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DN2vk7002511 for ; Thu, 13 Jun 2002 16:02:57 -0700 (PDT) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g5DN2toR005410 for ; Thu, 13 Jun 2002 16:02:55 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g5DN2tKl005409 for ipng@sunroof.eng.sun.com; Thu, 13 Jun 2002 16:02:55 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DJvkk7000032 for ; Thu, 13 Jun 2002 12:57:46 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA21435 for ; Thu, 13 Jun 2002 12:57:51 -0700 (PDT) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA01536 for ; Thu, 13 Jun 2002 13:59:37 -0600 (MDT) Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.04) id 17Iaj7-0003Pf-00; Thu, 13 Jun 2002 12:57:49 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: "Bound, Jim" Cc: "Bill Fenner" , Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols References: <9C422444DE99BC46B3AD3C6EAFC9711B020B8A17@tayexc13.americas.cpqcorp.net> Message-Id: Date: Thu, 13 Jun 2002 12:57:49 -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Read the latest architectural Internet doc by Bush et al. from the credit where due department: dave meyer was the principal author -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 13 16:03:22 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DN3Mk7002536; Thu, 13 Jun 2002 16:03:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5DN3LS1002535; Thu, 13 Jun 2002 16:03:21 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DN3Jk7002528 for ; Thu, 13 Jun 2002 16:03:19 -0700 (PDT) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g5DN3HoR005418 for ; Thu, 13 Jun 2002 16:03:17 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g5DN3HbO005417 for ipng@sunroof.eng.sun.com; Thu, 13 Jun 2002 16:03:17 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DL6Tk7000805 for ; Thu, 13 Jun 2002 14:06:30 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA28920 for ; Thu, 13 Jun 2002 14:06:33 -0700 (PDT) Received: from mail7.nc.rr.com (mail7.southeast.rr.com [24.93.67.54]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA08279 for ; Thu, 13 Jun 2002 15:08:20 -0600 (MDT) Received: from nc.rr.com ([24.162.252.183]) by mail7.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Thu, 13 Jun 2002 16:56:23 -0400 Message-ID: <3D09064A.8E1BA9F0@nc.rr.com> Date: Thu, 13 Jun 2002 16:53:30 -0400 From: Brian Haberman X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Vladislav Yasevich CC: ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols References: <4.2.2.20020605134805.0245def0@mail.windriver.com> <3D036720.7B02E8E8@nc.rr.com> <3D08F35F.1060103@hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Vlad, Not at all. The zone IDs are not included in the route advertisement messages. That simplifies things a great deal since you don't have to coordinate the zone IDs across a site. The zone IDs only have meaning on the node in which they are used. Brian Vladislav Yasevich wrote: > > Brian > > Wouldn't the Zone ID for a given site on all routers in that same site > have to be same for this to work? > > -vlad > > Brian Haberman wrote: > > Hi Margaret, > > I suppose that I should admit to being remiss in this area. I > > have done a fair amount of work in this area and just haven't had the > > time to document routing protocol behavior changes to support site > > local prefixes (even though I recall telling you I was going to do it). > > > > Anyway, I will start by saying that I have modified RIPng to > > correctly handle the advertisement of site-locals. In order to make > > this efficient, I maintained the concept of a single instance of RIPng > > running in the router. In order to understand the changes to the > > routing protocol, you also have to understand the changes to the > > RIB for site locals. So, how did I make it work? > > > > 1. The RIB now contains an additional field, the zone ID. I > > have done this in two different ways. The first is to add > > the zone ID as a separate field. The second is to embed > > the zone ID in the "unused" portion of the site local > > prefix. > > > > 2. RIPng was changed to build its route advertisement messages > > on a per zone ID basis. That is, it starts with adding all > > global prefixes to the message. It then adds site local > > prefixes that are in the same zone ID as the interface that > > the advertisement will be transmitted. It determines this > > by extracting the zone ID from the outgoing interface and > > using this find all site locals in the RIB with a matching > > zone ID. > > > > 3. When RIPng receives a route advertisement from a peer, it > > takes the zone ID from the receiving interface and using > > that to add the site local prefixes to the RIB. > > > > That, in a nutshell, allows a single instance of RIPng to control > > the advertising of site local unicast prefixes. Though I haven't > > done the work, I would see OSPF as acting in a similar manner. > > > > If someone wants me to describe the actual forwarding, just let me > > know. > > > > Regards, > > Brian > > > > Margaret Wasserman wrote: > > > >>I sent the attached message to the routing area discussion list. I thought that people on > >>the IPv6 list might be interested in this discussion, so I will forward a message containing > >>the responses after this one. I suppose I just should have cc:ed the IPv6 group in the > >>first place... > >> > >>Margaret > >> > >> > >>>Date: Fri, 24 May 2002 12:17:04 -0400 > >>>To: routing-discussion@ietf.org > >>From: Margaret Wasserman > >>>Subject: IPv6 Scoped Addresses and Routing Protocols > >>> > >>> > >>> > >>>Hi All, > >>> > >>>I raised some questions with Bill Fenner in Minneapolis regarding IPv6 scoped > >>>addressing and our current IPv6 routing protocol specifications, and Bill suggested > >>>that I should send my questions to this list for discussion. So, here they are. > >>> > >>>First, some background... > >>> > >>>As many of you probably know, IPv6 includes the concept of scoped unicast > >>>addressing -- a unicast address can have link-local scope, site-local scope > >>>or global scope. The address scopes are defined in the IPv6 Addressing > >>>Architecture: > >>> > >>>http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-addr-arch-v3-07.txt > >>> > >>>Additional information can be found in the IPv6 Scoped Address > >>>Architecture: > >>> > >>>http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-scoping-arch-03.txt > >>> > >>>I would suggest that all of you read the IPv6 Scoped Address Architecture > >>>document, if you haven't already, as it contains information regarding > >>>the expected configuration and forwarding behaviour of IPv6 routers. > >>>It also defines the concept of an IPv6 site, which is important to understanding > >>>the questions that I am about to raise. > >>> > >>>In IPv6, there is a concept of site-local addressing that is quite different > >> > >>>from the concept of "net 10" addresses in IPv4. Sites are administratively > >> > >>>defined entities that must be "convex" (i.e. the best route between two nodes > >>>in the site must, at all scopes, fall completely within the site). Sites boundaries > >>>run through routers, so a single router (called a site border router (SBR)) can > >>>have interfaces in more than one site. And, IPv6 site-local addresses can be > >>>used for site-constrained communication, even when a site is globally > >>>connected and global addresses are available. > >>> > >>>Because all site-local addresses use the same well-known site-local prefix, the > >>>only way to tell that a particular site-local address belongs to a particular > >>>site is to know which site originated the address. SBRs will need > >>>to enforce site boundaries, not mixing site-local routing information, and not > >>>forwarding packets outside of a given site. To do this, it is expected that > >>>SBRs will need to maintain multiple "conceptual routing tables", including one > >>>site-local routing table for each attached site, and one global routing table. > >>> > >>>Unfortunately, I can't find any indication that these concepts have been reflected > >>>in the current IPv6 routing protocols. None of our IPv6 routing protocol documents > >>>deal with site-local boundaries or SBR behaviour explicitly. > >>> > >>>There are currently four standards for how IPv6 routes will be handled in BGP, OSPF, > >>>IS-IS and RIP. I will refer to these documents as BGP-IPv6, OSPF-IPv6 and IS-IS-IPv6, > >>>and RIP-IPv6 respectively: > >>> > >>>Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing: > >>>http://www.ietf.org/rfc/rfc2545.txt > >>> > >>>OSPF for IPv6 > >>>http://www.ietf.org/rfc/rfc2740.txt > >>> > >>>Routing IPv6 with IS-IS: > >>>http://www.ietf.org/internet-drafts/draft-ietf-isis-ipv6-02.txt > >>> > >>>RIPng for IPv6 > >>>http://www.ietf.org/rfc/rfc2080.txt > >>> > >>>So here are my actual questions: > >>> > >>>(1) Are the statements regarding the routing system in the IPv6 Scoped Addressing Architecture > >>>draft valid? Will they work in real life? Please read it, and comment to the IPv6 WG if you think that > >>>there are any issues with what it says. > >>> > >>>(2) BGP-IPv6: > >>> > >>>BGP-IPv6 states: "As this document makes no assumption on the characteristics of a particular > >>>routing realm where BGP-4 is used, it makes no distinction between global and site-local addresses > >>>and refers to both as "global" or "non-link-local"." > >>> > >>>Would it ever be reasonable for BGP to propagate site-local routing information? Why, under > >>>what circumstances? Would it be reasonable to assume that an Inter-Domain Routing protocol > >>>shouldn't propagate site-local information at all? > >>> > >>>If BGP should be capable of propagating site-local information, will it be possible, using existing > >>>BGP standards for a BGP SBR router with four interfaces (A, B, C & D), in two sites (A & B in S1, > >>>and C & D in S2) to maintain two separate sets of information for prefix FEC0::/10, one that applies > >>>to S1 (interfaces A & B) and one that applies to S2 (interfaces C & D), and to propagate that information > >>>accordingly? Is this really just an issue of configuring the router properly, as BGP-IPv6 implies? > >>> > >>>(3) OSPF-IPV6: > >>> > >>>In this specification, no distinction is made between site-local and global addresses. Unlike the > >>>previous specification (BGP-IPv6), this assumption is not stated up-front. Instead, everywhere in > >>>the draft where either site-local or global addresses are mentioned they are both mentioned (i.e. > >>>"site-local or global IPv6 addresses"). > >>> > >>>Again this specification makes no provision for separate sets of site local information. There is > >>>also no mention of a boundary for site-local route propagation, and no mention of multiple conceptual > >>>sets of site-local routing information. Would it make sense to tie the concept of an IPv6 site to > >>>one of the existing propagation boundaries in OSPF, such as an OSPF area? Or to assume that > >>>an OSPF AS will always be completely contained within one site -- which is what the current draft > >>>seems to assume? > >>> > >>>(4) IS-IS-IPv6: > >>> > >>>IS-IS-IPv6 makes no mention of site-local or scoped addressing at all. Is this appropriate? How will IS-IS > >>>SBRs know not to propagate site-local routing information between two attached sites? I don't yet > >>>know enough about IS-IS to understand how site-local routing information would best be handled > >>>in IS-IS. Any thoughts? > >>> > >>>(5) RIP-IPv6: > >>> > >>>The RIP-IPv6 document explicitly states that there is a single IPv6 routing table, and it makes no > >>>mention of sites. I think it would be fine to constrain RIP to operating within a single IPv6 > >>>site, but that should be explicitly stated somewhere. > >>> > >>>(6) Will the MIBs for any of these routing tables be capable of representing multiple independent, > >>>possibly overlapping sets of site-local routing information? I looked them over quickly, and it > >>>wasn't immediately obvious to me how they could do this. > >>> > >>>(7) Do you think that there would be some utility to defining the actual routing architecture (as > >>>opposed to just the addressing architecture) for IPv6? If so, what would be the best way to do > >>>that? > >>> > >>>(8) Should we mention link-local addresses anywhere in these specifications? We certainly would > >>>not want to propagate routing information for link-local addresses. > >>> > >>>If there is some work that needs to be done here, I am very happy to provide some IPv6 expertise > >>>to that effort. > >>> > >>>Margaret > >>> > >>> > >>> > >> > >>-------------------------------------------------------------------- > >>IETF IPng Working Group Mailing List > >>IPng Home Page: http://playground.sun.com/ipng > >>FTP archive: ftp://playground.sun.com/pub/ipng > >>Direct all administrative requests to majordomo@sunroof.eng.sun.com > >>-------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > > > > > > -- > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > Vladislav Yasevich Tru64 UNIX - IPv6 Project Lead > Hewlett Packard Tel: (603) 884-1079 > Nashua, NH 03062 ZKO3-3/T07 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 13 16:03:43 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DN3gk7002553; Thu, 13 Jun 2002 16:03:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5DN3f6G002552; Thu, 13 Jun 2002 16:03:41 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DN3ek7002545 for ; Thu, 13 Jun 2002 16:03:40 -0700 (PDT) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g5DN3boR005426 for ; Thu, 13 Jun 2002 16:03:37 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g5DN3but005425 for ipng@sunroof.eng.sun.com; Thu, 13 Jun 2002 16:03:37 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DLVxk7000995 for ; Thu, 13 Jun 2002 14:31:59 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA20378 for ; Thu, 13 Jun 2002 14:32:03 -0700 (PDT) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA05363 for ; Thu, 13 Jun 2002 15:32:03 -0600 (MDT) Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.04) id 17IcCH-0009Kn-00; Thu, 13 Jun 2002 14:32:01 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: Steve Blake Cc: "Bound, Jim" , "Steven M. Bellovin" , "Pekka Savola" , "Ralph Droms" , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols References: <9C422444DE99BC46B3AD3C6EAFC9711B020B8A10@tayexc13.americas.cpqcorp.net> <200206132126.RAA01182@castillo.torrentnet.com> Message-Id: Date: Thu, 13 Jun 2002 14:32:01 -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Ripping site-locals out of the specs will not prevent folks who perceive > the need for stable addresses (e.g., for internal use) from allocating > them, especially given that ~7/8 of the IPv6 address space is held in > reserve. that is what folk said about chunks of v4 space and then got into deep doo doo when it was allocated, another site with which they merged had also grabbed it, ... occasionally, the goddesses are just. we have all been here before -- crosby, stills, and nash randy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 13 16:09:59 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DN9xk7002707; Thu, 13 Jun 2002 16:09:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5DN9wOs002706; Thu, 13 Jun 2002 16:09:58 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DN9tk7002699 for ; Thu, 13 Jun 2002 16:09:55 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA23106 for ; Thu, 13 Jun 2002 16:10:00 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA07377 for ; Thu, 13 Jun 2002 17:11:46 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 8D58B4B24 for ; Fri, 14 Jun 2002 08:09:55 +0900 (JST) To: ipng@sunroof.eng.sun.com In-reply-to: itojun's message of Thu, 13 Jun 2002 13:04:57 +0900. <20020613040457.E9D027C4@starfruit.itojun.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: Review of"Use of /127 Prefix Length Between Routers Considered Harmful" From: itojun@iijlab.net Date: Fri, 14 Jun 2002 08:09:55 +0900 Message-ID: <3331.1024009795@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > i usually use /64 for p2p link. it works just fine, it supports > temporary address (RFC3041) if you desire, i can think of no reason to > use somethiing other than /64. let me be clear - I usually use either /64 global address prefix, or no global address (link-local only), on p2p link. both works just fine. i assign /64 global prefix when we need to monitor router p2p interface from remote (by ping6), for instance. in other cases, i don't assign /64 global addess prefix. 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 Thu Jun 13 16:13:47 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DNDlk7002744; Thu, 13 Jun 2002 16:13:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5DNDlX3002743; Thu, 13 Jun 2002 16:13:47 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DNDik7002736 for ; Thu, 13 Jun 2002 16:13:44 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA19304 for ; Thu, 13 Jun 2002 16:13:49 -0700 (PDT) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA20709 for ; Thu, 13 Jun 2002 17:13:48 -0600 (MDT) Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.04) id 17Idmm-000GDa-00; Thu, 13 Jun 2002 16:13:48 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: itojun@iijlab.net Cc: ipng@sunroof.eng.sun.com Subject: Re: Review of"Use of /127 Prefix Length Between Routers Considered Harmful" References: <20020613040457.E9D027C4@starfruit.itojun.org> <3331.1024009795@itojun.org> Message-Id: Date: Thu, 13 Jun 2002 16:13:48 -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > let me be clear - I usually use either /64 global address prefix, or > no global address (link-local only), on p2p link. both works just > fine. traceroute is my friend. this is an enemy of traceroute. and enemy of my friend is my enemy. > i assign /64 global prefix when we need to monitor router p2p > interface from remote (by ping6), for instance. in other cases, i > don't assign /64 global addess prefix. this is like assigning 1918 addresses to v4 interface, only the filtering is more assured. does not make me comfortable. randy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 13 16:18:20 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DNIKk7002770; Thu, 13 Jun 2002 16:18:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5DNIK27002769; Thu, 13 Jun 2002 16:18:20 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5DNIGk7002762 for ; Thu, 13 Jun 2002 16:18:16 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA04210 for ; Thu, 13 Jun 2002 16:18:21 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA10735 for ; Thu, 13 Jun 2002 17:20:08 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 33C264B24; Fri, 14 Jun 2002 08:18:17 +0900 (JST) To: Randy Bush Cc: ipng@sunroof.eng.sun.com In-reply-to: randy's message of Thu, 13 Jun 2002 16:13:48 MST. 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: Review of"Use of /127 Prefix Length Between Routers Considered Harmful" From: itojun@iijlab.net Date: Fri, 14 Jun 2002 08:18:17 +0900 Message-ID: <3417.1024010297@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> let me be clear - I usually use either /64 global address prefix, or >> no global address (link-local only), on p2p link. both works just >> fine. >traceroute is my friend. this is an enemy of traceroute. and enemy of >my friend is my enemy. as long as the following two condition holds, traceroute6 work fine. - intermediate routers are using weak host model - intermediate routers have at least one global address 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 Thu Jun 13 17:17:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5E0Htk7003127; Thu, 13 Jun 2002 17:17:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5E0HtWS003126; Thu, 13 Jun 2002 17:17:55 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5E0Hqk7003119 for ; Thu, 13 Jun 2002 17:17:52 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA13863 for ; Thu, 13 Jun 2002 17:17:58 -0700 (PDT) Received: from tndh.net (evrtwa1-ar8-4-65-028-011.evrtwa1.dsl-verizon.net [4.65.28.11]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA13603 for ; Thu, 13 Jun 2002 18:17:57 -0600 (MDT) Received: from eagleswings (127.0.0.1) by localhost (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Thu, 13 Jun 2002 17:18:39 -0700 From: "Tony Hain" To: "Bound, Jim" , "Randall Stewart" , "Steven M. Bellovin" Cc: Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols Date: Thu, 13 Jun 2002 17:17:04 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B020B8A01@tayexc13.americas.cpqcorp.net> X-Mimeole: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk It is time to get off this thread and back to real work. Those who want SL removed should get 1918 moved to historic first, get all products using that off the market, then come back and raise the issue. Since we know that won't happen, the constructive thing to do is for those that don't think they can support SL to leave it out of their implementation, while those that have figured out how to use it as a differentiator can leave it in. Yes that might cause interoperability problems, but only in the case where a site was running with SL as its only prefix. When a node doesn't support SL, it will be hard pressed to register an SL address in whatever name resolution system is being used, and if a product can't respond correctly to an SL address, an administrator shouldn't register it. Every node should be able to work when only a global address is returned, so in any realistic scenario, where is the interoperability problem? On the topic of documenting when and how SL interacts with DNS or SIP or your favorite name-to-address-mapper, yes more work is needed. I would argue this belongs in the DNS WGs, but if their approach is to ignore it because it is different from current operation, then the IPv6 community will have to corner some DNS experts long enough to learn the issues. In any case it doesn't make sense to waste time arguing that 'XYZ configuration will not work', when no sane network manager would configure a network that way. When particular configurations don't work, pointing that out in documentation makes sense, but demanding to throw out the mechanism because an obscure corner case fails is not good engineering. One issue that I am surprised has not been raised here is the case where a node has administrative restrictions on which prefixes it can learn from an RA (specifically so that it will only work on the home network), and that list includes SL. If that node appeared on a foreign net, it would ignore the globals, but would happly accept any SL and may be wide open. One could argue that it shouldn't happen, but consider the case where enterprise-A uses 802.11, and a laptop with it built-in (and no administrative rights to the user to turn it off) were to show up at enterprise-B. The sys-admin may have thought the machine was reasonably protected by the filter list on the RA, but by using SL left that node wide open when it was away from home. This is not an argument that SL shoudl be dropped, just that it is not appropriate in all contexts. One case where it does make sense is in consumer electronics that are intended for local in-home use, and have no reason for global addressibility (say a light switch). Those who want SL removed are arguing that the average consumer will be required to manage a firewall to keep the global address of the light switch from being reached externally. Many of them can't even get self-configuring NATs to work with help from a support desk, so forget any hope that they will do something more complex. While having the light switch accessed by a control unit could be done with LL, does it make sense to have a control unit connect to every possible link technology in a home, or does it make more sense to use SL from a stand-alone control unit and have a routing device attach to the different segments? We typically define control and routing jobs as separate functions, so why would someone expect that they now magically show up in the same box? The router should be a cheap box with nothing but connectors, while the control unit has a fancy UI and may be replicated in multiple locations. As I scan through this thread, it started by questioning the lack of documentation about how SL should work in a particular context, but quickly degraded into an attack on change. The IETF is about managing the consistent change that has been taking place in networking, so standing up and saying 'take this out because it requires us to change the way we have done it forever' is counter to our role. Documenting that a mechanims works in configuration A, not at all in configuration B, and we haven't figured out configuraion C, is what we need to do here, so lets get on with it. Tony Jim Bound wrote: > As all know I wanted these dreaded site-locals gone since we > invented them in IPv6. > This has been discussed before if we can revisit this again > that is a very good thing. > Steve and Randy are 100% correct. > > I would also add they break lots of stuff. > > /jim > > > -----Original Message----- > > From: Randall Stewart [mailto:randall@stewart.chicago.il.us] > > Sent: Thursday, June 06, 2002 2:46 PM > > To: Steven M. Bellovin > > Cc: ipng@sunroof.eng.sun.com > > Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols > > > > > > Steve: > > > > Having implemented SCTP and IPv6 together I could not agree with you > > more. > > I know in our work on scoping of addresses it got very very > tricky on > > attempting to figure out which set of addresses to tell the other > > SCTP endpoint about to avoid black hole conditions. So in the end > > the only way you could handle it is if the destination address > > of your INIT packet (consider it a SYN) was TO a site-local then > > you could include your site-locals... This means that if the user > > sent the INIT to the global address then the peer NEVER > gets informed > > of site locals.... maybe something not desired but unavoidable... > > > > > > Now with the new addition of site-scoping even this will break since > > one must all of a sudden be cognizant of what site the peer > is on and > > only send a sub-set of the site-local addresses (gak!!). > > > > In all of this I have tried to figure out what use these site locals > > are? > > > > If I have a global address why would I ever want to use a > site-local? > > If no global-addresses are available and I am not attached to the > > public inter-net I could possibly see using a site-local.. maybe but > > I would think this is more the 'dentists' office scenario where in > > link-local will suffice... If the 'dentist' wants to talk to the > > insurance company I doubt that it would be in the > 'dentist's' site... > > so he would need a connection to the global address space... and the > > problem goes away.... > > > > Only in a large company would I see a site-local being > applied.. but > > in such a company why not just use a global address? What does it > > buy me to have this extra address? I already know my > assigned address > > space... I can have my company border routers prevent spoofing of > > my address into my network... so I can use the source being the > > global address that is assigned to me to "know" that I am in the > > same company...if thats what I want... > > > > I may be able to see (maybe) that a large company wants to NOT > > connect to the global address space... so here site-local MIGHT be > > something I could use... but adding in scoped site-locals I > just can't > > see a use for... It just causes all sorts of fun problems. > > > > I would much rather see the company that is NOT going to want to > > connect to the global address space just have a way to get some > > global address space.... I realize with the current number scheme > > this is not possible so maybe a site-local does make sense in > > this one strange instance... but in this case the company > > does not need > > to worry about global mixed with site-local :> > > > > So maybe site-local (if allowed) should only be valid if NO global > > address is defined :> > > > > R > > > > "Steven M. Bellovin" wrote: > > > > > > In message > > <4.2.2.20020605134805.0245def0@mail.windriver.com>, Margaret Wasserm > > > an writes: > > > > > > > >I sent the attached message to the routing area discussion > > list. I thought th > > > >at people on > > > >the IPv6 list might be interested in this discussion, so I > > will forward a mess > > > >age containing > > > >the responses after this one. I suppose I just should > > have cc:ed the IPv6 gro > > > >up in the > > > >first place... > > > > > > > > > > My strong preference would be to drop site-local addresses > > completely. > > > I think they're an administrative and technical nightmare. > > > > > > Margaret has pointed out that our routing protocols don't support > > > site-local addresses. The only alternative suggestion I've > > seen thus > > > far is to run multiple instances of, say, OSPF on all > > routers within a > > > site. But how are these distinguished from each other? > > OSPF runs with > > > an IP protocol number, not a port number, so we can't > have multiple > > > instances that way. And RFC 2740's specification of the necessary > > > multicast addresses notes that they're all link-local. > > Still, there's > > > apparently running code; I look forward to seeing the details. > > > > > > I'm very concerned about DNS entries. When should a DNS > > server -- or a > > > caching resolver -- return a site-local address? (If the > DNS never > > > returns such things, they're useless.) One suggestion > I've heard is > > > two-faced DNS servers -- only return site-local information if the > > > querier is within the same site. Apart from the fact > that I have no > > > idea how that determination can be made -- surely no one > > will suggest > > > putting site-local addresses into NS records -- RFC 2182 > > (aka BCP 0016) > > > specifically warns against putting all secondary servers > for a zone > > > within a site: > > > > > > Consequently, placing all servers at the local site, > > while easy to > > > arrange, and easy to manage, is not a good policy. > > Should a single > > > link fail, or there be a site, or perhaps even > building, or room, > > > power failure, such a configuration can lead to all > servers being > > > disconnected from the Internet. > > > > > > Secondary servers must be placed at both topologically and > > > geographically dispersed locations on the Internet, to > > minimise the > > > likelihood of a single failure disabling all of them. > > > > > > Etc. > > > > > > There will also be a lot of unnecessary pain in DNS maintenance as > > > "sites" are split or merged. v6 is designed to support > > easy renumbering > > > of global addresses, but those are designed to reflect topology. > > > Site-local addresses do not, which increases the probability of > > > address space collision during a merger. > > > > > > Philosophically, I think that the problem is that a > "site" is a new > > > (and deliberately poorly defined) concept. The DNS is > > designed to work > > > with administrative boundaries, while routing and > addressing reflect > > > topology. We now have a new concept that is neither > > administrative nor > > > topological, but one that must be supported by administrative and > > > topological mechanisms. > > > > > > Finally -- and perhaps least important -- I'm not sure > what problem > > > they solve. I can understand site-local multicast, since (most) > > > inter-site traffic traverses links that are not inherently > > > multicast-capable. There is thus considerable extra > > expense. But why > > > do I need site-local unicast addresses? > > > > > > --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 Thu Jun 13 17:22:15 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5E0MFk7003162; Thu, 13 Jun 2002 17:22:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5E0MEQu003161; Thu, 13 Jun 2002 17:22:14 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5E0MBk7003154 for ; Thu, 13 Jun 2002 17:22:11 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA15213 for ; Thu, 13 Jun 2002 17:22:17 -0700 (PDT) Received: from alicia.nttmcl.com (alicia.nttmcl.com [216.69.69.10]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA06156 for ; Thu, 13 Jun 2002 18:24:04 -0600 (MDT) Received: (from jj@localhost) by alicia.nttmcl.com (8.10.1/8.10.1) id g5E0M0D14846; Thu, 13 Jun 2002 17:22:00 -0700 (PDT) Date: Thu, 13 Jun 2002 17:21:59 -0700 From: JJ Behrens To: Michel Py Cc: Pekka Savola , Margaret Wasserman , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols Message-ID: <20020613172159.A10762@alicia.nttmcl.com> References: <2B81403386729140A3A899A8B39B046406C7F0@server2000.arneill-py.sacramento.ca.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <2B81403386729140A3A899A8B39B046406C7F0@server2000.arneill-py.sacramento.ca.us>; from michel@arneill-py.sacramento.ca.us on Mon, Jun 10, 2002 at 02:14:46AM -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Pekka Savola wrote > > You take one approach and disregard all the others. > > I don't. I just say that in this scenario site-local address helps. What > is the hacker knows the backdoor because he installed it himself and > cannot compromise the web server? Your argument is irrelevant. > > > Security is about finding the weakest links and strengthening them. > > You just looked at only one of them here.. > > Security is about plugging holes. There are hundreds to plug. Saying > that plugging a hole is useless because some other holes might be open > is the best way to get hacked. Michael, I am no security wizard. However, it seems to me that you are suggesting that site-local addresses add a small amount of security because there's no way to connect directly from the attacker's machine to the database machine. However, if the Web server has been compromised (which is a very reasonable proposition based on recent events), it seems just as easy for the attacker to mount his attack by first ssh'ing to the Web server, and then attacking the database server from there. I welcome your corrections if I have missed something. Thanks, -jj -- Users of C++ should consider hanging themselves rather than shooting their legs off--it's best not to use C++ simply as a better C. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 13 17:23:36 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5E0NZk7003182; Thu, 13 Jun 2002 17:23:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5E0NZ71003181; Thu, 13 Jun 2002 17:23:35 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5E0NUk7003171 for ; Thu, 13 Jun 2002 17:23:30 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA15756 for ; Thu, 13 Jun 2002 17:23:36 -0700 (PDT) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA17886 for ; Thu, 13 Jun 2002 17:23:36 -0700 (PDT) Received: from randy by rip.psg.com with local (Exim 4.04) id 17IesI-000Ido-00; Thu, 13 Jun 2002 17:23:34 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: "Tony Hain" Cc: "Bound, Jim" , "Randall Stewart" , "Steven M. Bellovin" , Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols References: <9C422444DE99BC46B3AD3C6EAFC9711B020B8A01@tayexc13.americas.cpqcorp.net> Message-Id: Date: Thu, 13 Jun 2002 17:23:34 -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > It is time to get off this thread and back to real work. Those who want > SL removed should get 1918 moved to historic first complete red herring. a socially better case of this herring would be to cure world hunger first. we may not like 1918, but that does not mean we should reproduce it to show our dislike. randy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 13 17:51:20 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5E0pKk7003370; Thu, 13 Jun 2002 17:51:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5E0pK2R003369; Thu, 13 Jun 2002 17:51:20 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5E0pGk7003362 for ; Thu, 13 Jun 2002 17:51:17 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA03168 for ; Thu, 13 Jun 2002 17:51:21 -0700 (PDT) Received: from tndh.net (evrtwa1-ar8-4-65-028-011.evrtwa1.dsl-verizon.net [4.65.28.11]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA24436 for ; Thu, 13 Jun 2002 18:51:20 -0600 (MDT) Received: from eagleswings (127.0.0.1) by localhost (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Thu, 13 Jun 2002 17:52:06 -0700 From: "Tony Hain" To: "Randy Bush" Cc: "Bound, Jim" , "Randall Stewart" , "Steven M. Bellovin" , Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols Date: Thu, 13 Jun 2002 17:50:31 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-Mimeole: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Randy Bush wrote: > > It is time to get off this thread and back to real work. > Those who want > > SL removed should get 1918 moved to historic first > > complete red herring. They are designed to serve the same purposes. Clearly the market has found several uses for 1918, so claiming any of those (except expanding the address space by reuse) are void in an IPv6 world is a bit academic. > > a socially better case of this herring would be to cure world > hunger first. > > we may not like 1918, but that does not mean we should > reproduce it to show > our dislike. There are uses for 1918, and life would have been good without NAT. We need to keep the real problem child in focus and not blame 1918 for the transgressions of NAT. Service providers and network managers clearly know the boundaries of their routing complex, and may find that using SL is a reasonable mechanism for SNMP and other management traffic, much as they use 1918 now. The issues raised on the thread have mostly focused on cases where the site boundary is not clear. When there is no clear boundary then SL shouldn't be used, just as you can't use 1918 in those cases now. Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 13 17:53:13 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5E0rDk7003391; Thu, 13 Jun 2002 17:53:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5E0rDQr003390; Thu, 13 Jun 2002 17:53:13 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5E0r8k7003383 for ; Thu, 13 Jun 2002 17:53:09 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA03568 for ; Thu, 13 Jun 2002 17:53:13 -0700 (PDT) Received: from mail8.nc.rr.com (fe8.southeast.rr.com [24.93.67.55]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA17203 for ; Thu, 13 Jun 2002 18:55:00 -0600 (MDT) Received: from mail pickup service by mail8.nc.rr.com with Microsoft SMTPSVC; Thu, 13 Jun 2002 20:43:18 -0400 Received: from ncmx01.mgw.rr.com ([24.93.67.251]) by mail8.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Wed, 12 Jun 2002 10:45:56 -0400 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ncmx01.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5CEjtbC005225 for ; Wed, 12 Jun 2002 10:45:56 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA17444; Wed, 12 Jun 2002 08:45:16 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA29553; Wed, 12 Jun 2002 07:43:26 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5CEfRk7015976; Wed, 12 Jun 2002 07:41:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5CEfRiL015975; Wed, 12 Jun 2002 07:41:27 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5CEfNk7015968 for ; Wed, 12 Jun 2002 07:41:23 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA29067 for ; Wed, 12 Jun 2002 07:41:25 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA16272; Wed, 12 Jun 2002 08:43:06 -0600 (MDT) Received: from kenawang ([147.11.72.26]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id HAA29911; Wed, 12 Jun 2002 07:39:49 -0700 (PDT) Message-Id: <4.2.2.20020612103350.022dca80@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 12 Jun 2002 10:38:24 -0400 To: Erik Nordmark From: Margaret Wasserman Subject: Re: IESG comments on draft-ietf-ipngwg-default-addr-select-06.txt Cc: Keith Moore , Thomas Narten , ipng@sunroof.eng.sun.com In-Reply-To: References: <"Your message with ID" <200206111704.g5BH4rn23548@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi All, >The proposed text is trying to say that temporary addresses are preferable >but that there might be issues (such as applications having problems) >which consistitute a good enough reason to not follow the default. >Thus there is significant freedom for implementors to use their best >judgement based on their knowledge about the applications. Is it optional for a vendor to implement temporary addresses? Is it optional for a user to configure site-local addresses on a box (or perhaps even for a vendor to support them)? One reason that has been put forth for having a fixed set of address selection rules is that it will be possible for implementations to know what addresses will be preferred, and override that behaviour if desired. I'm not quite sure how this works when it isn't clear that all vendors will implement all address types (temporary, site-local, etc.), or that all address types will be configured for a given system. This particularly becomes problematic when optional address types (temporary, perhaps site-local) are preferred over required address types (link-local and global). Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 13 19:31:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5E2Vbk7004073; Thu, 13 Jun 2002 19:31:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5E2Vbrl004072; Thu, 13 Jun 2002 19:31:37 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5E2VWk7004065 for ; Thu, 13 Jun 2002 19:31:33 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA23787 for ; Thu, 13 Jun 2002 19:31:38 -0700 (PDT) Received: from mail8.nc.rr.com (fe8.southeast.rr.com [24.93.67.55]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA29600 for ; Thu, 13 Jun 2002 19:31:37 -0700 (PDT) Received: from mail pickup service by mail8.nc.rr.com with Microsoft SMTPSVC; Thu, 13 Jun 2002 22:28:29 -0400 Received: from ncmx02.mgw.rr.com ([24.93.67.222]) by mail8.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Tue, 11 Jun 2002 19:30:44 -0400 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ncmx02.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5BNUja2024332 for ; Tue, 11 Jun 2002 19:30:45 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA03976; Tue, 11 Jun 2002 16:29:53 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA12734; Tue, 11 Jun 2002 16:29:50 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BNSLk7012210; Tue, 11 Jun 2002 16:28:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5BNSLQY012209; Tue, 11 Jun 2002 16:28:21 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BNSHk7012202 for ; Tue, 11 Jun 2002 16:28:17 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA13979 for ; Tue, 11 Jun 2002 16:28:21 -0700 (PDT) Received: from esunmail ([129.147.58.122]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA21177 for ; Tue, 11 Jun 2002 17:28:21 -0600 (MDT) Received: from xpa-fe2 (esunmail-ge0 [129.147.58.121]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 0.3 (built May 13 2002)) with ESMTP id <0GXK00KUWEJ7C6@edgemail1.Central.Sun.COM> for ipng@sunroof.eng.sun.com; Tue, 11 Jun 2002 17:28:20 -0600 (MDT) Received: from localhost ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 0.2 (built Apr 26 2002)) with ESMTPSA id <0GXK00F32EJ6H5@mail.sun.net> for ipng@sunroof.eng.sun.com; Tue, 11 Jun 2002 17:28:19 -0600 (MDT) Date: Tue, 11 Jun 2002 16:28:11 -0700 From: Alain Durand Subject: Re: IESG comments on draft-ietf-ipngwg-default-addr-select-06.txt In-reply-to: To: Erik Nordmark Cc: Keith Moore , Thomas Narten , ipng@sunroof.eng.sun.com Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.482) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tuesday, June 11, 2002, at 03:29 PM, Erik Nordmark wrote: > > The proposed text is trying to say that temporary addresses are > preferable > but that there might be issues (such as applications having problems) > which consistitute a good enough reason to not follow the default. > Thus there is significant freedom for implementors to use their best > judgement based on their knowledge about the applications. > > Do you see a problem with this approach? > If SA is a temporary address and SB is a public address, then prefer > SA. Similarly, if SB is a temporary address and SA is a public > address, then prefer SB. > An implementation MUST support a per-connection configuration > mechanism (for example, an API extension) to reverse the sense of > this preference and prefer public addresses over public > addresses. This proposed text means that all the existing clients that talks to server that uses reverse DNS lookup will need to be modified to use this new API extension to re-establish an existing behavior that would otherwise be broken. Until such an API is standardized and implemented, this seems to me an hazardous path. Also, this is asking exiting application who do not care about privacy to pay for the benefits of the new ones who desire privacy. I would be convinced this is worth doing if the number of applications that need to change is limited, and I'm afraid it is not. Does the IESG have data about this? And, last but not least, is having most of the traffic sent by client using this privacy extension such a good thing? Although I understand the desire from some applications for privacy, I'm afraid it would create network management nightmares when doing traffic analysis. Can you imagine a large site trying to do snoop/tcpdump when most of the traffic is RFC3041? - Alain. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 13 19:37:32 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5E2bWk7004558; Thu, 13 Jun 2002 19:37:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5E2bVwv004557; Thu, 13 Jun 2002 19:37:31 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5E2bPk7004550 for ; Thu, 13 Jun 2002 19:37:25 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA22170 for ; Thu, 13 Jun 2002 19:37:30 -0700 (PDT) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA07114; Thu, 13 Jun 2002 20:37:27 -0600 (MDT) Received: from randy by rip.psg.com with local (Exim 4.04) id 17Igxr-0002mn-00; Thu, 13 Jun 2002 19:37:27 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Alain Durand Cc: ipng@sunroof.eng.sun.com Subject: Re: IESG comments on draft-ietf-ipngwg-default-addr-select-06.txt References: Message-Id: Date: Thu, 13 Jun 2002 19:37:27 -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk for those who care, or can do anything about it, the mail loop is bkhabs@nc.rr.com > Received: from patan.sun.com ([192.18.98.43]) > by psg.com with esmtp (Exim 3.36 #1) > id 17IgtV-00065s-00 > for randy@psg.com; Thu, 13 Jun 2002 19:32:57 -0700 > Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) > by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA18092; > Thu, 13 Jun 2002 20:34:41 -0600 (MDT) > Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) > by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA24163; > Thu, 13 Jun 2002 19:32:51 -0700 (PDT) > Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) > by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5E2Vbk7004073; > Thu, 13 Jun 2002 19:31:37 -0700 (PDT) > Received: (from majordomo@localhost) > by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5E2Vbrl004072; > Thu, 13 Jun 2002 19:31:37 -0700 (PDT) > X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f > Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) > by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5E2VWk7004065 > for ; Thu, 13 Jun 2002 19:31:33 -0700 (PDT) > Received: from nwkea-mail-2.sun.com ([192.18.42.14]) > by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA23787 > for ; Thu, 13 Jun 2002 19:31:38 -0700 (PDT) ------------------------------------------------------------------------- > Received: from mail8.nc.rr.com (fe8.southeast.rr.com [24.93.67.55]) > by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA29600 > for ; Thu, 13 Jun 2002 19:31:37 -0700 (PDT) > Received: from mail pickup service by mail8.nc.rr.com with Microsoft SMTPSVC; > Thu, 13 Jun 2002 22:28:29 -0400 > Received: from ncmx02.mgw.rr.com ([24.93.67.222]) by mail8.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); > Tue, 11 Jun 2002 19:30:44 -0400 > Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) > by ncmx02.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5BNUja2024332 > for ; Tue, 11 Jun 2002 19:30:45 -0400 (EDT) ------------------------------------------------------------------------- > Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) > by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA03976; > Tue, 11 Jun 2002 16:29:53 -0700 (PDT) > Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) > by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA12734; > Tue, 11 Jun 2002 16:29:50 -0700 (PDT) > Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) > by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BNSLk7012210; > Tue, 11 Jun 2002 16:28:22 -0700 (PDT) > Received: (from majordomo@localhost) > by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5BNSLQY012209; > Tue, 11 Jun 2002 16:28:21 -0700 (PDT) > X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f > Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) > by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BNSHk7012202 > for ; Tue, 11 Jun 2002 16:28:17 -0700 (PDT) > Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) > by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA13979 > for ; Tue, 11 Jun 2002 16:28:21 -0700 (PDT) > Received: from esunmail ([129.147.58.122]) > by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA21177 > for ; Tue, 11 Jun 2002 17:28:21 -0600 (MDT) > Received: from xpa-fe2 (esunmail-ge0 [129.147.58.121]) > by edgemail1.Central.Sun.COM > (iPlanet Messaging Server 5.2 HotFix 0.3 (built May 13 2002)) > with ESMTP id <0GXK00KUWEJ7C6@edgemail1.Central.Sun.COM> for > ipng@sunroof.eng.sun.com; Tue, 11 Jun 2002 17:28:20 -0600 (MDT) > Received: from localhost ([66.93.78.11]) > by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 0.2 (built Apr 26 2002)) > with ESMTPSA id <0GXK00F32EJ6H5@mail.sun.net> for ipng@sunroof.eng.sun.com; > Tue, 11 Jun 2002 17:28:19 -0600 (MDT) > In-reply-to: > Message-id: > MIME-version: 1.0 > X-Mailer: Apple Mail (2.482) > Content-type: text/plain; charset=US-ASCII; format=flowed > Content-transfer-encoding: 7BIT > Sender: owner-ipng@sunroof.eng.sun.com > Precedence: bulk > Date: Tue, 11 Jun 2002 16:28:11 -0700 > From: Alain Durand > Subject: Re: IESG comments on draft-ietf-ipngwg-default-addr-select-06.txt > To: Erik Nordmark > Cc: Keith Moore , Thomas Narten , > ipng@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 Jun 13 19:47:03 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5E2l3k7004613; Thu, 13 Jun 2002 19:47:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5E2l3Ml004612; Thu, 13 Jun 2002 19:47:03 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5E2l0k7004605 for ; Thu, 13 Jun 2002 19:47:00 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA26324 for ; Thu, 13 Jun 2002 19:47:05 -0700 (PDT) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA09829 for ; Thu, 13 Jun 2002 20:47:03 -0600 (MDT) Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols Date: Thu, 13 Jun 2002 19:47:02 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046405E107@server2000.arneill-py.sacramento.ca.us> X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 X-MS-TNEF-Correlator: Thread-Topic: Fwd: IPv6 Scoped Addresses and Routing Protocols content-class: urn:content-classes:message Thread-Index: AcITOZuNUBbdLOZ6R/Kei2vlltUh3wADLuzA From: "Michel Py" To: "JJ Behrens" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5E2l0k7004606 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk JJ, > JJ Behrens wrote: > Michael, > I am no security wizard. However, it seems to me that you are > suggesting that site-local addresses add a small amount of > security because there's no way to connect directly from the > attacker's machine to the database machine. However, if the Web > server has been compromised (which is a very reasonable proposition > based on recent events), it seems just as easy for the attacker to > mount his attack by first ssh'ing to the Web server, and then > attacking the database server from there. > I welcome your corrections if I have missed something. You have perfectly understood. The point I was trying to make is not how easy or difficult it is to hack the web server, but that it is one extra step that the hacker has to take. If the database server has no access to the outside, the hacker needs to have enough access and skills to install some kind of a proxy server that will read the data from the database server to the web server, then send this data back to the hacker. This is no easy task. In other words: Yes it is possible to copy data from a machine that does not have access to the outside, but it does require skills that some hackers do not have. Let's say you know Windows, but the server you compromise is an obscure flavor of Unix. How much time is it going to take you to understand how that system is configured, write the software to proxy the data, compile it in a way that the host likes, install it, etc. All of that without being caught. Granted, that will not stop a good hacker, but that will stop the disgruntled employee that does not know jack but the passwords. I read somewhere that 80% of computer crime is committed by people that are nowhere near what you would call a hacker but have insider's info. If using SL keeps half of these 80% out, I'm more than happy with it. A significant part of securing a host or network is putting a large number of roadblocks in the hacker's way. None of the road blocks are impossible to pass, the goal is to get the hacker tired before the end. I have to insist that a host that has direct access to the Internet (such as an RFC 1918 host with NAT) is indeed less secure than a host that does not (such as a v6 host with a SL address only). Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 13 20:01:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5E31mk7004665; Thu, 13 Jun 2002 20:01:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5E31mVB004664; Thu, 13 Jun 2002 20:01:48 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5E31hk7004657 for ; Thu, 13 Jun 2002 20:01:44 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA29104 for ; Thu, 13 Jun 2002 20:01:49 -0700 (PDT) Received: from mail8.nc.rr.com (fe8.southeast.rr.com [24.93.67.55]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA12218 for ; Thu, 13 Jun 2002 21:01:49 -0600 (MDT) Received: from mail pickup service by mail8.nc.rr.com with Microsoft SMTPSVC; Thu, 13 Jun 2002 22:56:07 -0400 Received: from ncmx01.mgw.rr.com ([24.93.67.251]) by mail8.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Tue, 11 Jun 2002 19:40:32 -0400 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ncmx01.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5BNeXbC006707 for ; Tue, 11 Jun 2002 19:40:33 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA25856; Tue, 11 Jun 2002 17:40:17 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA13423; Tue, 11 Jun 2002 16:40:10 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BNcek7012344; Tue, 11 Jun 2002 16:38:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5BNcect012343; Tue, 11 Jun 2002 16:38:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BNcLk7012336 for ; Tue, 11 Jun 2002 16:38:36 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA12749 for ; Tue, 11 Jun 2002 16:38:17 -0700 (PDT) Received: from esunmail ([129.147.58.122]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA04252 for ; Tue, 11 Jun 2002 17:38:16 -0600 (MDT) Received: from xpa-fe1 (esunmail-ge1 [129.147.58.122]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 0.3 (built May 13 2002)) with ESMTP id <0GXK0033QEZRT4@edgemail1.Central.Sun.COM> for ipng@sunroof.eng.sun.com; Tue, 11 Jun 2002 17:38:16 -0600 (MDT) Received: from localhost ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 0.2 (built Apr 26 2002)) with ESMTPSA id <0GXK00016EZQRC@mail.sun.net> for ipng@sunroof.eng.sun.com; Tue, 11 Jun 2002 17:38:15 -0600 (MDT) Date: Tue, 11 Jun 2002 16:38:07 -0700 From: Alain Durand Subject: Re: IESG comments on draft-ietf-ipngwg-default-addr-select-06.txt In-reply-to: <200206112320.g5BNKZn27758@astro.cs.utk.edu> To: Keith Moore Cc: Erik Nordmark , Thomas Narten , ipng@sunroof.eng.sun.com Message-id: <480BE094-7D94-11D6-9BDA-00039376A6AA@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.482) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tuesday, June 11, 2002, at 04:20 PM, Keith Moore wrote: > I've got some other problems with the document also - specifically > the idea that link-local addresses are preferable to global addresses. > Global addresses are always preferable because all applications > can tolerate them. At most, LL addresses should be used only > when there is no other alternative, because some applications > need to treat them specially (this isn't as bad in v6 as in v4) > But LL addresses should probably be used only when they are > explicitly specified. I would agree there. If an application stores the IP address of its peer for future use, on a multi-interface node, if link-local addresses are used and the application did not kept track of the incoming interface, there would be some issues when it would like to reconnect to its peer. - Alain. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 13 20:03:16 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5E33Gk7004709; Thu, 13 Jun 2002 20:03:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5E33FKX004708; Thu, 13 Jun 2002 20:03:15 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5E33Bk7004695 for ; Thu, 13 Jun 2002 20:03:11 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA28056 for ; Thu, 13 Jun 2002 20:03:17 -0700 (PDT) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA10713 for ; Thu, 13 Jun 2002 20:03:16 -0700 (PDT) Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols Date: Thu, 13 Jun 2002 20:03:15 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046405E108@server2000.arneill-py.sacramento.ca.us> X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 X-MS-TNEF-Correlator: Thread-Topic: Fwd: IPv6 Scoped Addresses and Routing Protocols content-class: urn:content-classes:message Thread-Index: AcITPisQmqQB6au1SJKKVB0LGGXYpwAD75gQ From: "Michel Py" To: "Tony Hain" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5E33Ck7004696 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Tony Hain wrote: > There are uses for 1918, and life would have been good without NAT. > We need to keep the real problem child in focus and not blame 1918 > for the transgressions of NAT. I agree. > Service providers and network managers clearly know the boundaries > of their routing complex, and may find that using SL is a reasonable > mechanism for SNMP and other management traffic, much as they use > 1918 now. SNMP is a good example. In a large network, it is desirable (for operational purposes) to have numbered and routable addresses on each interface and a routable loopback interface as well. The loopback interface is used mainly for administrative and management purposes. If it is desirable to have public addresses on interfaces (for traceroutes), it is equally desirable to have a private address for the loopback, as the outside world has no business with it. Translation in the ipv6 lingo: private = site-local. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 13 20:08:32 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5E38Wk7005155; Thu, 13 Jun 2002 20:08:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5E38Vng005154; Thu, 13 Jun 2002 20:08:31 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5E38Sk7005147 for ; Thu, 13 Jun 2002 20:08:28 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA29453 for ; Thu, 13 Jun 2002 20:08:34 -0700 (PDT) Received: from mail8.nc.rr.com (fe8.southeast.rr.com [24.93.67.55]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA14586 for ; Thu, 13 Jun 2002 21:08:33 -0600 (MDT) Received: from mail pickup service by mail8.nc.rr.com with Microsoft SMTPSVC; Thu, 13 Jun 2002 23:01:19 -0400 Received: from ncmx01.mgw.rr.com ([24.93.67.251]) by mail8.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Wed, 12 Jun 2002 10:00:38 -0400 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ncmx01.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5CB3ebC001189 for ; Wed, 12 Jun 2002 07:03:40 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA01752; Wed, 12 Jun 2002 04:02:47 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA18653; Wed, 12 Jun 2002 04:02:41 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5CB0wk7013596; Wed, 12 Jun 2002 04:00:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5CB0wSS013595; Wed, 12 Jun 2002 04:00:58 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5CB0tk7013588 for ; Wed, 12 Jun 2002 04:00:55 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA20311 for ; Wed, 12 Jun 2002 04:00:57 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.96.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA05457 for ; Wed, 12 Jun 2002 05:02:28 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g5CB09M06865; Wed, 12 Jun 2002 18:00:10 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g5CAvfs19944; Wed, 12 Jun 2002 17:57:41 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Antonio Querubin cc: Jun-ichiro itojun Hagino , ipng@sunroof.eng.sun.com Subject: Re: Review of"Use of /127 Prefix Length Between Routers Considered Harmful" In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 12 Jun 2002 17:57:41 +0700 Message-ID: <19942.1023879461@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 12 Jun 2002 00:42:16 -1000 (HST) From: Antonio Querubin Message-ID: | a point to point link doesn't really | need a global address in many cases. Assuming this is true, the inference is that there are some cases where a global address is required. That's true: I know of one - munnari.oz.au has a P2P link for IPv6, and that's its only IPv6 connectivity. Assuming that it is to have a global v6 address (and it does) it has to be assigned to the P2P link, there is nothing else to assign it to (it isn't a router, just a host, and the p2p link is a tunnel, of course, not that that matters). Given that, the question is how the global address space should be used on P2P links when addresses are required, surely? The question of what to do when they're not required (and not wanted either) is not relevant, is it? So, can we please get off the rat hole issue of whether or not p2p links should be numbered, and return to discussing the draft, which gives some guidelines on how to number them (and how not to) when they are being numbered? (With, as I recall, though it has been a while since I looked, no statements at all saying that p2p links actually should be numbered). kre ps: there's no v6 DNS entry for munnari yet, so don't bother looking. Its v6 connectivity is weird, and I don't want to subject that path to the kind of traffic volumes that munnari tends to attract - and perhaps would, even over the 6bone. Its A6 record will appear once I get better connectivity, which means when the local academic network people manage to get themselves connected (they have the APNIC prefix ready...) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Jun 13 21:54:11 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5E4sBk7005955; Thu, 13 Jun 2002 21:54:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5E4sAJd005954; Thu, 13 Jun 2002 21:54:10 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5E4s7k7005947 for ; Thu, 13 Jun 2002 21:54:07 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA07871 for ; Thu, 13 Jun 2002 21:54:12 -0700 (PDT) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA13733 for ; Thu, 13 Jun 2002 22:54:11 -0600 (MDT) Subject: RE: back on track? [RE: Review of "Use of /127 Prefix Length BetweenRouters Considered Harmful"] Date: Thu, 13 Jun 2002 21:54:10 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046405E109@server2000.arneill-py.sacramento.ca.us> X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 X-MS-TNEF-Correlator: content-class: urn:content-classes:message Thread-Topic: back on track? [RE: Review of "Use of /127 Prefix Length BetweenRouters Considered Harmful"] Thread-Index: AcITFRvG2/Axs4oGT0u//medORJV7AAScvuA From: "Michel Py" To: "Pekka Savola" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5E4s8k7005948 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Pekka Savola wrote: > In addition to using a different prefix length, one could > also use only link-local addresses or "two /128's". I don't like the "or two /128's" part of this. Link-local addresses are not /128s. Link-local addresses are technically ok. Actually, I think that they should be #2 in the list of options. In a large network, they are a troubleshooting headache but in a small network there is nothing to say against them. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 13 23:20:01 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5E6K0k7006220; Thu, 13 Jun 2002 23:20:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5E6K0lI006219; Thu, 13 Jun 2002 23:20:00 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5E6Jvk7006212 for ; Thu, 13 Jun 2002 23:19:57 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA22119 for ; Thu, 13 Jun 2002 23:20:02 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA23597 for ; Fri, 14 Jun 2002 00:20:01 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g5E6Jvp22382; Fri, 14 Jun 2002 09:19:58 +0300 Date: Fri, 14 Jun 2002 09:19:57 +0300 (EEST) From: Pekka Savola To: Michel Py cc: ipng@sunroof.eng.sun.com Subject: RE: back on track? [RE: Review of "Use of /127 Prefix Length BetweenRouters Considered Harmful"] In-Reply-To: <2B81403386729140A3A899A8B39B046405E109@server2000.arneill-py.sacramento.ca.us> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 13 Jun 2002, Michel Py wrote: > > Pekka Savola wrote: > > In addition to using a different prefix length, one could > > also use only link-local addresses or "two /128's". > > I don't like the "or two /128's" part of this. Link-local addresses are > not /128s. Note that link-locals and two /128's are two separate cases. "two /128's" means an implementation (like KAME) where you can do this without link-local addresses. Obviously the wording is a bit off. But I couldn't figure out how to say it without getting into static routes or whatnot. Any ideas? > Link-local addresses are technically ok. Actually, I think that they > should be #2 in the list of options. In a large network, they are a > troubleshooting headache but in a small network there is nothing to say > against them. I've considered putting link-locals only in solutions 1), more or less equal with /64. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 14 00:19:36 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5E7JZk7006449; Fri, 14 Jun 2002 00:19:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5E7JZ2S006448; Fri, 14 Jun 2002 00:19:35 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5E7JWk7006441 for ; Fri, 14 Jun 2002 00:19:32 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA25851 for ; Fri, 14 Jun 2002 00:19:36 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.96.5]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA00211 for ; Fri, 14 Jun 2002 00:19:25 -0700 (PDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g5E7IkM08735; Fri, 14 Jun 2002 14:18:47 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g5E76S202618; Fri, 14 Jun 2002 14:06:31 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: "Bound, Jim" cc: sommerfeld@east.sun.com, "Michel Py" , "Bob Hinden" , "Steven M. Bellovin" , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B020B8A0C@tayexc13.americas.cpqcorp.net> References: <9C422444DE99BC46B3AD3C6EAFC9711B020B8A0C@tayexc13.americas.cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 14 Jun 2002 14:06:28 +0700 Message-ID: <2616.1024038388@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 13 Jun 2002 08:47:49 -0400 From: "Bound, Jim" Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B8A0C@tayexc13.americas.cpqcorp.net> | and this is my biggest fear for the Internet with IPv6. | These site-locals could undo all we did with IPv6 to restore | end-to-end architecture for the Internet. That's nonsense Jim. We lost the possibility of end to end because we didn't have enough addresses for everyone. As long as we have enough addresses that everyone can have one, then end to end remains. Having even more addresses cannot possibly prevent that, whatever their nature. Of course, there's nothing that you, or anyone, can do to force me to allow your systems to communicate with mine - that's completely independent of addressing. At MU, we have undergrad student labs, that we basically filter from the world - they have no end to end connectivity at all. And that has nothing at all to do with NAT (of which we have none at all) nor with 1918 addressing (of which we also have none at all). Nor will it have anything at all to do with site local addresses. The filtering (using global addressing everywhere) is because we want to protect the rest of the world from our students' activities (as most of these systems are in more or less open access labs, we have no reliable way to tell which person was using which system at any particular time, so if some system is used to break into somewhere out there, we have no way of deciding which person was responsible, so there's nothing we would ever be able to do about it). And secondly, because more traffic costs us more dollars, and we need to limit how much is being spent. These people all have indirect access to the whole net, via access ports that first verify who they are (for both forms of accountability, though we don't actually generate bills) - but nothing end to end, and addressing has nothing even slightly to do with it. Of course, there are people who would accuse me of being anti-social for using global IPv4 addresses for systems that could use 1918 addressing, and perhaps with some justification - but being able to return to the world a bunch of unrelated /26 subnets doesn't really seem like it would be useful enough for me to switch these systems from the global addresses they are now using. Let's try and keep the red herrings in the red sea, and away from this mailing list, please. 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 Fri Jun 14 00:25:55 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5E7Psk7006478; Fri, 14 Jun 2002 00:25:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5E7PsTN006477; Fri, 14 Jun 2002 00:25:54 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5E7Ppk7006470 for ; Fri, 14 Jun 2002 00:25:51 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA15704 for ; Fri, 14 Jun 2002 00:25:55 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.96.5]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA02531 for ; Fri, 14 Jun 2002 00:25:53 -0700 (PDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g5E7P8M13584; Fri, 14 Jun 2002 14:25:08 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g5E7D1202636; Fri, 14 Jun 2002 14:13:01 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: "Bound, Jim" cc: "JINMEI Tatuya / ????" , "Margaret Wasserman" , "Brian Haberman" , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B020B8A13@tayexc13.americas.cpqcorp.net> References: <9C422444DE99BC46B3AD3C6EAFC9711B020B8A13@tayexc13.americas.cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 14 Jun 2002 14:13:01 +0700 Message-ID: <2634.1024038781@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 13 Jun 2002 08:59:58 -0400 From: "Bound, Jim" Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B8A13@tayexc13.americas.cpqcorp.net> | Exactly. The entire IPv6 code base would be reduced in size and more | importantly the decision constructs and data struct lookups which is a | big win. Can you actually justify that, or is this just more nonsense? Remember that as long as link locals stay, and as long as their are apps that use them (doesn't BGP peering use LL's these days?) then all of the system support for scoped addresses has to remain, including the data structs, API's, ... What you would gain by removing them is the change from testing fe80::/9 into testing fe80::/10 when deciding if the address you have is one that also needs a scope. Beyond that it is essentially all the same if scopes are involved - are the scopes for source & destination the same, etc - regardless of whether it is fe80::/10 or fec0::/10 that the address happens to be. So, just where is this saving? 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 Fri Jun 14 00:37:51 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5E7bpk7006535; Fri, 14 Jun 2002 00:37:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5E7bpuO006534; Fri, 14 Jun 2002 00:37:51 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5E7blk7006527 for ; Fri, 14 Jun 2002 00:37:47 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA04528 for ; Fri, 14 Jun 2002 00:37:51 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.96.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA15016 for ; Fri, 14 Jun 2002 01:31:34 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g5E7T2M16494; Fri, 14 Jun 2002 14:29:02 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g5E7H9202649; Fri, 14 Jun 2002 14:17:09 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: "Bound, Jim" cc: "Randy Bush" , "Francis Dupont" , "Steven M. Bellovin" , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B020B8A14@tayexc13.americas.cpqcorp.net> References: <9C422444DE99BC46B3AD3C6EAFC9711B020B8A14@tayexc13.americas.cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 14 Jun 2002 14:17:09 +0700 Message-ID: <2647.1024039029@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 13 Jun 2002 09:04:33 -0400 From: "Bound, Jim" Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B8A14@tayexc13.americas.cpqcorp.net> | Also this is not the case for link-local. The reason is that the links | are hardwired in the implementation and treating them as zones works for | links. But sites are "virtual". More FUD... Sites are only "virtual" until someone decides which links belong to the site, and which do not, and configures things that way. They're no more virtual than an ATM based link level, where someone has to decide which ATM PVCs and SVCs perhaps are part of the link, and which are not, and/or any modern switch where someone has to decide which ports belong to which VLAN. Once configured, any and all of these things are just as real as each other. 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 Fri Jun 14 00:38:40 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5E7cek7006553; Fri, 14 Jun 2002 00:38:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5E7cek8006551; Fri, 14 Jun 2002 00:38:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5E7cZk7006540 for ; Fri, 14 Jun 2002 00:38:35 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA04694 for ; Fri, 14 Jun 2002 00:38:39 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.96.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA17815 for ; Fri, 14 Jun 2002 01:40:10 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g5E7bfM22820; Fri, 14 Jun 2002 14:37:41 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g5E7Pj202669; Fri, 14 Jun 2002 14:25:45 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: "Michel Py" cc: "Antonio Querubin" , ipng@sunroof.eng.sun.com Subject: Re: Review of"Use of /127 Prefix Length Between Routers ConsideredHarmful" In-Reply-To: <2B81403386729140A3A899A8B39B046406C81F@server2000.arneill-py.sacramento.ca.us> References: <2B81403386729140A3A899A8B39B046406C81F@server2000.arneill-py.sacramento.ca.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 14 Jun 2002 14:25:45 +0700 Message-ID: <2667.1024039545@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 13 Jun 2002 12:40:22 -0700 From: "Michel Py" Message-ID: <2B81403386729140A3A899A8B39B046406C81F@server2000.arneill-py.sacramento.ca.us> | The fact of the matter is that any prefix longer than /64 goes against | [ADDRARCH] But that spec has no business telling me how I use the addresses assigned to me - I will use them as I see fit, and there's nothing you can possibly do to prevent it. Pretending you can is absurd. 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 Fri Jun 14 00:46:18 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5E7kHk7006598; Fri, 14 Jun 2002 00:46:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5E7kHZt006597; Fri, 14 Jun 2002 00:46:17 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5E7kEk7006590 for ; Fri, 14 Jun 2002 00:46:14 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA01658 for ; Fri, 14 Jun 2002 00:46:17 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.96.5]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA09695 for ; Fri, 14 Jun 2002 01:46:11 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g5E7jMM28630; Fri, 14 Jun 2002 14:45:23 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g5E7XC202690; Fri, 14 Jun 2002 14:33:18 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Steve Blake cc: "Bound, Jim" , "Steven M. Bellovin" , "Pekka Savola" , "Ralph Droms" , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-Reply-To: <200206132126.RAA01182@castillo.torrentnet.com> References: <200206132126.RAA01182@castillo.torrentnet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 14 Jun 2002 14:33:12 +0700 Message-ID: <2688.1024039992@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 13 Jun 2002 17:26:21 -0400 From: Steve Blake Message-ID: <200206132126.RAA01182@castillo.torrentnet.com> | Ripping site-locals out of the specs will not prevent folks who perceive | the need for stable addresses (e.g., for internal use) from allocating them, | especially given that ~7/8 of the IPv6 address space is held in reserve. Yes, exactly. If site locals were made to go away, they'd simply be re-invented by sites all over the place, in totally un-coordinated ways, and the same pressures that led to reserving the 1918 address space will just reappear. That was really: "people are doing this ('borrowing' address space) anyway, we might as well tell them some numbers to use that will cause less problems than simply using arbitrary ones". Unless / until we come up with some way of avoiding even the possibility that sites will ever need to renumber (which I think is almost the same as asking for a guarantee that the routing people can route a 2^48 flat address space) then stable addresses for internal communications are a *requirement* for many sites, and whether that's achieved by simply "borrowing" some random prefix and using it forever, or whether it is done using "fec0::/10" is largely irrelevant - it will be done anyway. 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 Fri Jun 14 00:49:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5E7nlk7006624; Fri, 14 Jun 2002 00:49:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5E7nlqZ006623; Fri, 14 Jun 2002 00:49:47 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5E7nik7006616 for ; Fri, 14 Jun 2002 00:49:44 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA06463 for ; Fri, 14 Jun 2002 00:49:48 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA21981 for ; Fri, 14 Jun 2002 01:51:35 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g5E7nVE23214; Fri, 14 Jun 2002 10:49:32 +0300 Date: Fri, 14 Jun 2002 10:49:31 +0300 (EEST) From: Pekka Savola To: itojun@iijlab.net cc: Randy Bush , Subject: Re: Review of"Use of /127 Prefix Length Between Routers Considered Harmful" In-Reply-To: <3417.1024010297@itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 14 Jun 2002 itojun@iijlab.net wrote: > >> let me be clear - I usually use either /64 global address prefix, or > >> no global address (link-local only), on p2p link. both works just > >> fine. > >traceroute is my friend. this is an enemy of traceroute. and enemy of > >my friend is my enemy. > > as long as the following two condition holds, traceroute6 work fine. > - intermediate routers are using weak host model > - intermediate routers have at least one global address Up to some level of "fine". Practically, this works if the conditions hold: - network is small - you know the topology very well Reason for this is that global address assigned to loopback does not give as much information in traceroute as point-to-point links. For example, we embed the names of both ends' routers, the type of the link (implicitly its speed) and the interface slot numer etc. in reverse lookups for the P-t-P addresses, like: router1-ge321-router2 or router3-a1031-router4 (this is at router1's end connecting to router2, on GigaEthernet3/2/1; router3's end connecting to router4, with ATM1/0/3, subinterface 1). There is _no way_ loopbacks are going to give that debugging/tracing information to us :-). I guess there are many ways to use traceroute, and global addresses, coupled with nice reverse lookups are quite invaluable. In small networks especially if you know the topology, this feature is rather useless and link-locals + 1 global is definitely the easiest approach. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 14 00:50:06 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5E7o5k7006637; Fri, 14 Jun 2002 00:50:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5E7o586006636; Fri, 14 Jun 2002 00:50:05 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5E7o1k7006629 for ; Fri, 14 Jun 2002 00:50:01 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA19211 for ; Fri, 14 Jun 2002 00:50:05 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.96.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA22066 for ; Fri, 14 Jun 2002 01:51:51 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g5E7n9M01558; Fri, 14 Jun 2002 14:49:10 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g5E7bD202702; Fri, 14 Jun 2002 14:37:13 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Keith Moore cc: Steve Blake , "Bound, Jim" , "Steven M. Bellovin" , "Pekka Savola" , "Ralph Droms" , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-Reply-To: <200206132231.g5DMVEY08270@astro.cs.utk.edu> References: <200206132231.g5DMVEY08270@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 14 Jun 2002 14:37:13 +0700 Message-ID: <2700.1024040233@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 13 Jun 2002 18:31:14 -0400 From: Keith Moore Message-ID: <200206132231.g5DMVEY08270@astro.cs.utk.edu> | seems like you really want some address space that | - is unique | - isn't provider-based | - can be routed between private nets "provider based" is wrong, "isn't topologically based" is what would be needed, so I get to retain the same addresses regardless of how my connectivity to the net happened to change. And the third needs to be "can be routed" without qualification. All that you need to do is come up with the address space and routing solution that meets those criteria (kind of like IPv4 addresses were in the 80's and before) and then I'll certainly agree that we don't need site local addresses, or some other replacement for them. Until then however, we do. 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 Fri Jun 14 00:55:23 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5E7tMk7006676; Fri, 14 Jun 2002 00:55:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5E7tMwo006675; Fri, 14 Jun 2002 00:55:22 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5E7tJk7006668 for ; Fri, 14 Jun 2002 00:55:19 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA19919 for ; Fri, 14 Jun 2002 00:55:23 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.96.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA23786 for ; Fri, 14 Jun 2002 01:56:26 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g5E7rjM04742; Fri, 14 Jun 2002 14:53:45 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g5E7fp202719; Fri, 14 Jun 2002 14:41:51 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Randy Bush cc: Steve Blake , "Bound, Jim" , "Steven M. Bellovin" , "Pekka Savola" , "Ralph Droms" , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-Reply-To: References: <9C422444DE99BC46B3AD3C6EAFC9711B020B8A10@tayexc13.americas.cpqcorp.net> <200206132126.RAA01182@castillo.torrentnet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 14 Jun 2002 14:41:51 +0700 Message-ID: <2717.1024040511@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 13 Jun 2002 14:32:01 -0700 From: Randy Bush Message-ID: | that is what folk said about chunks of v4 space and then got into deep | doo doo when it was allocated, another site with which they merged had | also grabbed it, ... occasionally, the goddesses are just. And that is exactly why 1918 was written, and as the need hasn't changed in the slightest, exactly why site locals (or something equivalent) are needed now. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 14 02:42:02 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5E9g1k7006966; Fri, 14 Jun 2002 02:42:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5E9g1MI006965; Fri, 14 Jun 2002 02:42:01 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5E9fwk7006958 for ; Fri, 14 Jun 2002 02:41:58 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA06860 for ; Fri, 14 Jun 2002 02:42:03 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.96.5]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA26625 for ; Fri, 14 Jun 2002 03:41:56 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g5E9fHM24138; Fri, 14 Jun 2002 16:41:17 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g5E9TO203157; Fri, 14 Jun 2002 16:29:24 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Keith Moore cc: Thomas Narten , JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= , ipng@sunroof.eng.sun.com Subject: Re: IESG comments on draft-ietf-ipngwg-default-addr-select-06.txt In-Reply-To: <200206131301.g5DD1qY01532@astro.cs.utk.edu> References: <200206131301.g5DD1qY01532@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 14 Jun 2002 16:29:24 +0700 Message-ID: <3155.1024046964@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 13 Jun 2002 09:01:52 -0400 From: Keith Moore Message-ID: <200206131301.g5DD1qY01532@astro.cs.utk.edu> | I've come to the opposite conclusion - that it's completely unreasonable | to expect apps (or hosts) to assume the burdens of: Keith, what matters is that unless the burdens (and their underlying causes) are removed, someone has to do it. Of course, everyone would prefer that it be someone else, and not "me" but regardless of that, the burden remains, and has to be dealt with somehow. All the points you made about the problems that exist are valid, but unfortunately we can't simply wish them away. Like it or not, the nature of the net has changed in the past 20 years, and "it was better 20 years ago" is not a useful thing to say. It would be nice to go back in time, or perhaps better stated, to revert the protocols to all work the way they did then - but the reasons that things changed haven't gone away. That's largely that the net got a lot bigger, and what we had 20 years ago simply didn't scale well. Now it doesn't actually matter whether it is the apps that deal with this, or something else lower down the stack - in the API (library routines or whatever), in the transport stacks, or even in the network layer, though down that low seems to be too low - there's no enough idea about the needs of the application down there, so bad choices would be made as often as good ones. But something has to deal with temporary addresses, as these days, *all* (global) addresses are temporary, and trying to pretend otherwise is folly. The only difference between one kind of temporary address and another is the expected validity period. Something has to cope with that, and as long as apps keep looking at addresses at all, it seems that the apps have to be able to handle this complication. Having the apps just keep on pretending that the world hasn't changed in the past 20 years is doing a disservice to everyone. 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 Fri Jun 14 03:39:11 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5EAdAk7007343; Fri, 14 Jun 2002 03:39:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5EAdA45007342; Fri, 14 Jun 2002 03:39:10 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5EAd7k7007335 for ; Fri, 14 Jun 2002 03:39:07 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA15815 for ; Fri, 14 Jun 2002 03:39:07 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.96.5]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA24414 for ; Fri, 14 Jun 2002 04:38:48 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g5EAc6M06278; Fri, 14 Jun 2002 17:38:06 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g5EAQA203273; Fri, 14 Jun 2002 17:26:13 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: itojun@iijlab.net cc: ipng@sunroof.eng.sun.com Subject: Re: Review of"Use of /127 Prefix Length Between Routers Considered Harmful" In-Reply-To: <5459.1023973532@itojun.org> References: <5459.1023973532@itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 14 Jun 2002 17:26:10 +0700 Message-ID: <3271.1024050370@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 13 Jun 2002 22:05:32 +0900 From: itojun@iijlab.net Message-ID: <5459.1023973532@itojun.org> | read RFC3041 again carefully. it assumes 64bit interface identifier, | therefore it assumes /64 subnet prefix. I know. But I said nothing about 3041, all I said was "temporary address". The changes needed to 3041 to handle other sizes for temporary address allocation would be trivial, there's nothing in 3041 that actually depends upon having 64 bits to assign (other than the number of bits and the birthday paradox combining to make the chances of an addr clash very small - which on a p2p link is meaningless). That is, if there was any point in actually standardising a method to use for this, which there almost certainly isn't. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 14 06:07:19 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5ED7Ik7007694; Fri, 14 Jun 2002 06:07:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5ED7Ius007693; Fri, 14 Jun 2002 06:07:18 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5ED7Fk7007686 for ; Fri, 14 Jun 2002 06:07:15 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA16475 for ; Fri, 14 Jun 2002 06:07:20 -0700 (PDT) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA18784 for ; Fri, 14 Jun 2002 07:07:19 -0600 (MDT) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 78EA26ADA; Fri, 14 Jun 2002 09:07:19 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Fri, 14 Jun 2002 09:07:19 -0400 x-mimeole: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Securing Neighbor Discovery BOF Date: Fri, 14 Jun 2002 09:07:18 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B01A9B4C8@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Securing Neighbor Discovery BOF Thread-Index: AcIS/v8xVwAMTZVaSICjOVxgtpXwDwApAedg From: "Bound, Jim" To: "James Kempf" , X-OriginalArrivalTime: 14 Jun 2002 13:07:19.0041 (UTC) FILETIME=[69CD1F10:01C213A4] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5ED7Fk7007687 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi James, > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Thursday, June 13, 2002 1:21 PM > To: Bound, Jim; ipng@sunroof.eng.sun.com > Subject: Re: Securing Neighbor Discovery BOF > > > Hi Jim, > > > What is the point of this meeting. We have so many > meetings to go to. > > > > Just turn on IPsec whats not in ND to support this? > > > > What problem are you trying to solve? > > > > IPsec works for ND? > > > > We are interested in discussing how to secure IPv6 Neighbor > Discovery in > a way that would work well for public access networks (but not > exclusively confined to that). So your talking about either coming on a public link or over PPP and there is ND and you want IPsec right? If so just use IPsec? I still don't know what your missing. If you mean folks don't like the keying or have not figured that out I agree. But then it is a misnomer to say it is an IPsec problem. It is an IPsec Keying problem and this is a different statement. IPsec does work over ND. > > RFC 2461 specifies that IPsec should be used to secure the signaling > involved in ND, but does not provide any details about how this should > be done, and, specifically, how key distribution would be done. IKE > won't work because it requires ND so there is a bootstrapping problem. > Manual keying would work for a small private network, and > possibly even > for a larger enterprise network, but it would be extremely > inconvenient > for public access networks. There have also been some proposals to use > other security protocols rather than IPsec for ND security. OK so it is a Keying problem. We as architects have very important responsiblity here.k Saying in public mail "IPsec don't work on ND" is bad thing. Keying is of course an issue and all of us who have implemented IPsec are well aware of this issue and real time in the market place. We work around it via 3rd party Certificate Keying ISVs in that business and get the job done. Once that happens it works for ND and other parts of IPv6. Yes I can see AAA working and advantages of PANA exactly for this purpose for sure as an alternative solution. And probably will perform better IMO. (unless IPsec and keys can be downloaded to a smartcard or net processor). > > The immediate need for this work comes out of plans by ISPs, > especially > in Asia, to deploy public access IPv6 wireless networks (NTT > Communications is running a prototype deployment in Kyoto at the > moment). While the problem of ND security is not, in principle, any > better or worse with wireless than with wireline, current > wireline links > tend to have less of a problem because they typically are > point to point > rather than multi-access, so the issue doesn't arise, though it might > also be a problem with wireline multi-access links that do > not use PPPoE > or other solutions to make the link look point to point. Agreed and I would also argue it needs to work between wireline and wireless as the user sticks their handheld back in the docking station at work or home. > > If you are interested in the potential threats, I'd suggest reading > draft-kempf-netaccess-threats-01.txt, which I've just > resubmitted to the > Internet drafts editor (it had timed out in April), and if you have > something specific you would like to speak about, please let either > Pekka or myself know. Well you know me James I am very secure individual and think the paranoid have way to much influence over our technology :---) But I will read this spec on my todo list as a professional and if have questions will get back to you privately or Pekka or both. thanks /jim > > jak > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 14 06:10:07 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5EDA6k7007739; Fri, 14 Jun 2002 06:10:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5EDA6L2007738; Fri, 14 Jun 2002 06:10:06 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5EDA3k7007731 for ; Fri, 14 Jun 2002 06:10:03 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA26338 for ; Fri, 14 Jun 2002 06:10:08 -0700 (PDT) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA18367 for ; Fri, 14 Jun 2002 07:10:07 -0600 (MDT) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 7CCD7381E; Fri, 14 Jun 2002 09:10:07 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Fri, 14 Jun 2002 09:10:07 -0400 x-mimeole: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Securing Neighbor Discovery BOF Date: Fri, 14 Jun 2002 09:10:06 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B8A63@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Securing Neighbor Discovery BOF Thread-Index: AcITDsUV8CmvD6kJSrq5H9ozerFuVAAlfCAg From: "Bound, Jim" To: Cc: "James Kempf" , X-OriginalArrivalTime: 14 Jun 2002 13:10:07.0285 (UTC) FILETIME=[CE151E50:01C213A4] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5EDA3k7007732 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bill, I agree see my response to James I just sent. Just wanted to flush our IPsec protocol vs Keying which I think we just did. thanks /jim > -----Original Message----- > From: Bill Sommerfeld [mailto:sommerfeld@east.sun.com] > Sent: Thursday, June 13, 2002 3:16 PM > To: Bound, Jim > Cc: James Kempf; ipng@sunroof.eng.sun.com > Subject: Re: Securing Neighbor Discovery BOF > > > > What problem are you trying to solve? > > securing neighbor discovery exchanges. > > > IPsec works for ND? > > Using AH/ESP to protect ND works fine once the SA's exist. > > However, there's a chicken & egg problem if you want to use IKE, and > manually configuring N*(N-1) SA's across N machines on the link is not > deployable. > > So if you want to use IPsec to protect ND, you need to solve the key > management problem for ND. > > - 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 Jun 14 06:13:02 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5EDD2k7007767; Fri, 14 Jun 2002 06:13:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5EDD17c007766; Fri, 14 Jun 2002 06:13:01 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5EDCwk7007759 for ; Fri, 14 Jun 2002 06:12:58 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA17417 for ; Fri, 14 Jun 2002 06:13:03 -0700 (PDT) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA19689 for ; Fri, 14 Jun 2002 07:13:03 -0600 (MDT) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id DC5418F43; Fri, 14 Jun 2002 09:13:02 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Fri, 14 Jun 2002 09:13:02 -0400 x-mimeole: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: IESG comments on draft-ietf-ipngwg-default-addr-select-06.txt Date: Fri, 14 Jun 2002 09:13:02 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B8A64@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IESG comments on draft-ietf-ipngwg-default-addr-select-06.txt Thread-Index: AcITEzHem3oBSiPTShajJtcky/luiwAkdNLg From: "Bound, Jim" To: "Alberto Escudero-Pascual" Cc: "Erik Nordmark" , "Keith Moore" , "Thomas Narten" , X-OriginalArrivalTime: 14 Jun 2002 13:13:02.0349 (UTC) FILETIME=[366DC3D0:01C213A5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5EDCxk7007760 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Alberto, I understand but that is not a valid logic argument to cause us to break many things in our boxes that is coming out now. I also think as Jinmei stated it is not a per application issue but per user issue. That means it cannot be a default from my view. /jim > -----Original Message----- > From: Alberto Escudero-Pascual [mailto:aep@it.kth.se] > Sent: Thursday, June 13, 2002 3:45 PM > To: Bound, Jim > Cc: Erik Nordmark; Keith Moore; Thomas Narten; > ipng@sunroof.eng.sun.com > Subject: RE: IESG comments on > draft-ietf-ipngwg-default-addr-select-06.txt > > > > Hi Jim! > > If only the users that have concerns about privacy will end > up using temp > addresses (RFC3041) we will end up with a minority group of > techno-geeks > or as you call us 'paranoids' highly observable and easy to > identify from > the crowd. > > I firmly beleive that RFC3041 should be the default option > and only the > nodes that require a fixed address should enable that option. > 'Privacy' > should be the default option. I don't want to be sorrounded > by boxes with > EUI-64 based addresses and be myself the only one running RFC3041. > > /aep > > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 14 06:45:10 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5EDjAk7008017; Fri, 14 Jun 2002 06:45:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5EDjA96008016; Fri, 14 Jun 2002 06:45:10 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5EDj6k7008009 for ; Fri, 14 Jun 2002 06:45:07 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA16827 for ; Fri, 14 Jun 2002 06:45:10 -0700 (PDT) From: rbrabson@us.ibm.com Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA04688 for ; Fri, 14 Jun 2002 07:45:09 -0600 (MDT) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.us.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.12.2/8.12.2) with ESMTP id g5EDgGRY076390; Fri, 14 Jun 2002 09:42:17 -0400 Received: from d04nm200.raleigh.ibm.com (d04nm200.raleigh.ibm.com [9.67.226.57]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5EDgFs149778; Fri, 14 Jun 2002 09:42:15 -0400 Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols To: Robert Elz Cc: "Brian Haberman" , ipng@sunroof.eng.sun.com, "Bound, Jim" , "JINMEI Tatuya / ????" , "Margaret Wasserman" X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Fri, 14 Jun 2002 09:42:00 -0400 X-MIMETrack: Serialize by Router on D04NM200/04/M/IBM(Build M13TT_06062002 Pre-release 2|June 06, 2002) at 06/14/2002 09:42:15 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=0ABBE14BDFD460418f9e8a93df938690918c0ABBE14BDFD46041" Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --0__=0ABBE14BDFD460418f9e8a93df938690918c0ABBE14BDFD46041 Content-type: text/plain; charset=US-ASCII On Friday, 06/14/2002 at 02:13 ZE7, Robert Elz wrote: > | Exactly. The entire IPv6 code base would be reduced in size and more > | importantly the decision constructs and data struct lookups which is a > | big win. > > Can you actually justify that, or is this just more nonsense? > > Remember that as long as link locals stay, and as long as their are > apps that use them (doesn't BGP peering use LL's these days?) then all > of the system support for scoped addresses has to remain, including the > data structs, API's, ... > > What you would gain by removing them is the change from testing > fe80::/9 into testing fe80::/10 when deciding if the address you > have is one that also needs a scope. Beyond that it is essentially > all the same if scopes are involved - are the scopes for source & > destination the same, etc - regardless of whether it is fe80::/10 or > fec0::/10 that the address happens to be. > > So, just where is this saving? I can think of plenty of savings in my protduct if I restrict it so that it only supports a single site. Support for simultaneous connectivity to multiple sites requires updates to my routing table, so that I now support multiple "logical" routing tables, one for each site I'm connected to and one for global addresses. Support for this takes new configuration (to define the multiple sites) and new code within the stack. But the TCP/IP stack changes are just the tip of the iceberg. Support for simultaneous connections to multiple sites requires changes to the DNS name server and resolver, routing daemons, and potentially applications. While I have no doubt all of this can be architected and made to work, but it isn't here today and it isn't going to be free and, I suspect, neither is it going to be easy. If I only support connecting to a single site, then I no longer need the configuration, nor do I need a site zone index to differentiate between two site-local addresses. I no longer need to support multiple "logical" routing tables, and my DNS resolver doesn't need to understand which interfaces are connected to which sites. I don't have to update RIP and OSPF to add support for multiple sites. I still need to run a two faced DNS, but that is business as usual for customers who want to use a mixture of private and public addressing. Link-local, on the other hand, is different. I don't need to use the routing table in selecting where to send the packet, as the destination must (by default) be on a directly attached link. I simply need to identify the link onto which to place the packet, and can use the scope zone to index into the link on which the outgoing packet needs to be sent. No route table lookups are used or required, and no changes to the routing table are needed. So, from my perspective, the complexity of site-local and link-local are quite different. And, while it wouldn't pain me to see SL simply disappear, restricting hosts to connecting to a single site would alleviate much of the complexity surrounding the use of private addresses. Roy --0__=0ABBE14BDFD460418f9e8a93df938690918c0ABBE14BDFD46041 Content-type: text/html; charset=US-ASCII Content-Disposition: inline On Friday, 06/14/2002 at 02:13 ZE7, Robert Elz <kre@munnari.OZ.AU> wrote:
>   | Exactly.  The entire IPv6 code base would be reduced in size and more
>   | importantly the decision constructs and data struct lookups which is a
>   | big win.
>
> Can you actually justify that, or is this just more nonsense?
>
> Remember that as long as link locals stay, and as long as their are
> apps that use them (doesn't BGP peering use LL's these days?) then all
> of the system support for scoped addresses has to remain, including the
> data structs, API's, ...
>
> What you would gain by removing them is the change from testing
> fe80::/9 into testing fe80::/10 when deciding if the address you
> have is one that also needs a scope.   Beyond that it is essentially
> all the same if scopes are involved - are the scopes for source &
> destination the same, etc - regardless of whether it is fe80::/10 or
> fec0::/10 that the address happens to be.
>
> So, just where is this saving?

I can think of plenty of savings in my protduct if I restrict it so that
it only supports a single site.  Support for simultaneous connectivity to
multiple sites requires updates to my routing table, so that I now support
multiple "logical" routing tables, one for each site I'm connected to and
one for global addresses.  Support for this takes new configuration (to
define the multiple sites) and new code within the stack.

But the TCP/IP stack changes are just the tip of the iceberg.  Support for
simultaneous connections to multiple sites requires changes to the DNS name
server and resolver, routing daemons, and potentially applications.  While
I have no doubt all of this can be architected and made to work, but it
isn't here today and it isn't going to be free and, I suspect, neither is
it going to be easy.

If I only support connecting to a single site, then I no longer need the
configuration, nor do I need a site zone index to differentiate between
two site-local addresses.  I no longer need to support multiple "logical"
routing tables, and my DNS resolver doesn't need to understand which
interfaces are connected to which sites.  I don't have to update RIP and
OSPF to add support for multiple sites.  I still need to run a two faced
DNS, but that is business as usual for customers who want to use a mixture
of private and public addressing.

Link-local, on the other hand, is different.  I don't need to use the
routing table in selecting where to send the packet, as the destination
must (by default) be on a directly attached link.  I simply need to
identify the link onto which to place the packet, and can use the scope
zone to index into the link on which the outgoing packet needs to be sent.  
No route table lookups are used or required, and no changes to the routing
table are needed.

So, from my perspective, the complexity of site-local and link-local are
quite different.  And, while it wouldn't pain me to see SL simply
disappear, restricting hosts to connecting to a single site would
alleviate much of the complexity surrounding the use of private addresses.

Roy --0__=0ABBE14BDFD460418f9e8a93df938690918c0ABBE14BDFD46041-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 14 06:55:15 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5EDtEk7008056; Fri, 14 Jun 2002 06:55:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5EDtExM008055; Fri, 14 Jun 2002 06:55:14 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5EDtBk7008048 for ; Fri, 14 Jun 2002 06:55:11 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA18836 for ; Fri, 14 Jun 2002 06:55:15 -0700 (PDT) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA08206 for ; Fri, 14 Jun 2002 06:55:15 -0700 (PDT) Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.194.24]) by e31.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id g5EDqbcx054704; Fri, 14 Jun 2002 09:52:37 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.9.21]) by westrelay03.boulder.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5EDqaQ12766; Fri, 14 Jun 2002 07:52:36 -0600 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id g5EDoZu15476; Fri, 14 Jun 2002 09:50:35 -0400 Message-Id: <200206141350.g5EDoZu15476@rotala.raleigh.ibm.com> To: Robert Elz cc: ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-Reply-To: Message from "Fri, 14 Jun 2002 14:33:12 +0700." <2688.1024039992@munnari.OZ.AU> Date: Fri, 14 Jun 2002 09:50:35 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > If site locals were made to go away, they'd simply be re-invented by > sites all over the place, in totally un-coordinated ways, and the same > pressures that led to reserving the 1918 address space will just > reappear. Just because people do something that we feel is unwise, doesn't mean we should encourge such behavior (either explicitly, or by silence). Saying "don't do that" is one of the things that the IETF can do. If the real feeling here is that site locals are bad if they end up reproducing some of the same problems as private addresses, then we should produce documents that explain when site-locals can safely be used (i.e., an applicability statement that describes when the IETF recommends their use). For other uses that people imagine (or that we expect they will imagine), but for which we think is a bad idea, we should say *why* its a bad idea *and* we should suggest a better way of doing it, so that folks who have a particular problem can choose an appropriate solution. For example, we could arrange to allow sites to obtain globally unique address space (though non-routable globally) if they want it for internal numbering. That would address some of the issues that private addresses of led to. Note that this is something we can't do in IPv4 because there just aren't enough address for this; IPv6 doesn't have that constraint. 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 Jun 14 07:01:13 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5EE1Ck7008097; Fri, 14 Jun 2002 07:01:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5EE1CM5008096; Fri, 14 Jun 2002 07:01:12 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5EE19k7008089 for ; Fri, 14 Jun 2002 07:01:09 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA05657 for ; Fri, 14 Jun 2002 07:01:13 -0700 (PDT) Received: from emerson.torrentnet.com (emerson.torrentnet.com [198.78.51.110]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA11531 for ; Fri, 14 Jun 2002 07:01:12 -0700 (PDT) Received: from imperial.torrentnet.com (imperial.torrentnet.com [198.78.51.109]) by emerson.torrentnet.com (8.11.2/8.11.2) with ESMTP id g5EE17V89024; Fri, 14 Jun 2002 10:01:07 -0400 (EDT) Received: from castillo.torrentnet.com (castillo.torrentnet.com [4.18.161.34]) by imperial.torrentnet.com (8.11.2/8.11.2) with ESMTP id g5EE16E43221; Fri, 14 Jun 2002 10:01:06 -0400 (EDT) Received: from castillo.torrentnet.com (localhost.torrentnet.com [127.0.0.1]) by castillo.torrentnet.com (8.9.3/8.9.3) with ESMTP id KAA09626; Fri, 14 Jun 2002 10:01:06 -0400 (EDT) Message-Id: <200206141401.KAA09626@castillo.torrentnet.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Robert Elz cc: ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-reply-to: Your message of "Fri, 14 Jun 2002 14:41:51 +0700." <2717.1024040511@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 14 Jun 2002 10:01:06 -0400 From: Steve Blake Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert Elz wrote: > And that is exactly why 1918 was written, and as the need hasn't changed > in the slightest, exactly why site locals (or something equivalent) are > needed now. A simple proposal: FEC0::/48 good enough for (most) home nets, SOHO, etc. FEE<36-bit random#>/48 NUSLA FEFF<4-byte AS#>/48 for sites that absolutely, positively care about global uniqueness Any special casing for site-locals in the stack and the API should be removed. Use at your own risk, just like rfc1918 addresses. The latter (FEFF/48) are portable global addresses. If you can pay someone enough to announce them for you in the DFZ, hooray for you. Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven L. Blake Ericsson IP Infrastructure 919-472-9913 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 14 07:39:00 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5EEcxk7008193; Fri, 14 Jun 2002 07:38:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5EEcxdD008192; Fri, 14 Jun 2002 07:38:59 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5EEcuk7008185 for ; Fri, 14 Jun 2002 07:38:56 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA14006 for ; Fri, 14 Jun 2002 07:39:00 -0700 (PDT) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA02530 for ; Fri, 14 Jun 2002 07:38:59 -0700 (PDT) Subject: RE: back on track? [RE: Review of "Use of /127 Prefix LengthBetweenRouters Considered Harmful"] Date: Fri, 14 Jun 2002 07:38:58 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046405E10A@server2000.arneill-py.sacramento.ca.us> X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 X-MS-TNEF-Correlator: Thread-Topic: back on track? [RE: Review of "Use of /127 Prefix LengthBetweenRouters Considered Harmful"] content-class: urn:content-classes:message Thread-Index: AcITa6IuqsfAXhQERViyoB0mlzXITQARNZug From: "Michel Py" To: "Pekka Savola" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5EEcuk7008186 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Pekka Savola wrote: > Note that link-locals and two /128's are two separate cases. > "two /128's" means an implementation (like KAME) where you can do > this without link-local addresses. > Obviously the wording is a bit off. But I couldn't figure out how to > say it without getting into static routes or whatnot. Any ideas? There needs to be something about the route install, as it is specific to the implementation. Seriously, I don't think that two /128s would ever be considered on a large network. >> Link-local addresses are technically ok. Actually, I think that they >> should be #2 in the list of options. In a large network, they are a >> troubleshooting headache but in a small network there is nothing to say >> against them. > I've considered putting link-locals only in solutions 1), more or less > equal with /64. Makes sense also, as /64s and LLs are the only two options that do not violate [addrarch]. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 14 07:50:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5EEonk7008228; Fri, 14 Jun 2002 07:50:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5EEongE008227; Fri, 14 Jun 2002 07:50:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5EEojk7008220 for ; Fri, 14 Jun 2002 07:50:45 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA00521 for ; Fri, 14 Jun 2002 07:50:49 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.96.5]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA26358 for ; Fri, 14 Jun 2002 08:50:48 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g5EEmHM06416; Fri, 14 Jun 2002 21:48:17 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g5EEmB208402; Fri, 14 Jun 2002 21:48:12 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: rbrabson@us.ibm.com cc: "Brian Haberman" , ipng@sunroof.eng.sun.com, "Bound, Jim" , "JINMEI Tatuya / ????" , "Margaret Wasserman" Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 14 Jun 2002 21:48:11 +0700 Message-ID: <8400.1024066091@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 14 Jun 2002 09:42:00 -0400 From: rbrabson@us.ibm.com Message-ID: | I can think of plenty of savings in my protduct if I restrict it so that | it only supports a single site. Yes, a router with multiple connected sites is certainly the case where the biggest savings from eliminating or restricting site locals would be found. | Support for simultaneous connectivity to | multiple sites requires updates to my routing table, so that I now support | multiple "logical" routing tables, one for each site I'm connected to and | one for global addresses. That's one usable technique I imagine. Another might be to simply have one routing table/algorithm, and mark the addresses with a site flag (essentially make them 128+n bits long, with the extra n bits at the most significant end). With that, SL's look to the routing table just like globals, except (because the marks are only added this way) you can only ever see routes to them out the appropiate interfaces, and there's implicit filtering of them when sending routes. Which method would work out to be more effective/easier I don't know, but most likely the multiple routing table approach would be better as it seems to offer more room for better flexibility and control. | Support for this takes new configuration (to | define the multiple sites) and new code within the stack. Yes, that's certainly going to be true, but just how much in comparison to all the other code that's there, and are there really no other benefits from cleaning up/enhancing the code? My expectation would be that simply having done the work to allow multiple routing tables might be a benefit worth having, regardless of whether they're used for site locals or not. | But the TCP/IP stack changes are just the tip of the iceberg. Support for | simultaneous connections to multiple sites requires changes to the DNS name | server Please *NO*. The very last thing I want is any mention of a site local address in any (globally reachable) nameserver, anywhere. If we can't find a better way to manage them than that, then I'd agree, ditch the things. But I believe that we can. | and resolver, Perhaps some there, yes, but nothing very difficult I suspect. | routing daemons, Yes, routing code needs to know about them (that's the same as above isn't it) | and potentially applications. Yes, but for the vast majority of applications the extra code they're going to need is going to be there anyway, as they need to support link locals, and they're also addresses that need a scope indicator. Routing has the special property that the meaning of the address needs to be understood, not just its syntax, for other apps, that's not true, and any address with a scope is an address with a scope, and needs to be dealt with in essentially the same way. Apps need the ability to use link local addresses, even if it is just so I can "telnet fe80::1%link" or similar, when they have that, they can also handle scopes in site locals. Keith's examples of apps that send addresses around, and will get confused if they're sending addresses to places where they might not be meaningful are the few cases where the app might care - but again, it needs to care about LL addresses just as much as SL - the general rule should probably be to send an address to another node only if its scope is at least as large as (and the same value if it is limited) the address you're using to talk to the other node - so it is OK to send a SL to someone if "someone" is identified by a SL in the same site as the address, but not if they're identified by a global. I haven't analysed this, but at first glance it looks safe. Not many applications are going to care however. | If I only support connecting to a single site, then I no longer need the | configuration, nor do I need a site zone index to differentiate between | two site-local addresses. That's true, but you need it for LL addresses. Routing would simplify as LL's don't get routed, but the rest of the complications largely remain. | I still need to run a two faced | DNS, but that is business as usual for customers who want to use a mixture | of private and public addressing. It may be, but that is evil - let's just create a better way (not easily possible for v4 I suspect, but the "magic" properties we have given SL's in v6 make things much easier). | And, while it wouldn't pain me to see SL simply | disappear, restricting hosts to connecting to a single site would | alleviate much of the complexity surrounding the use of private addresses. If the complexity is too much to deal with, just supporting a single site only in your product (whatever it is) would be just fine as far as I'm concerned. If that becomes common, then the approach to SL's that required a DMZ between sites (no nodes in 2 sites) may become the standard way to operate. As I said in an earlier message, I half recollect (but might be mistaken) that that was the approach I initially supported when SL's were first created, but now I'm not sure that the savings are really worth the limitations it imposes. On the other hand, if common consensus among implementors is that that's the only way to make things work reasonably, so that's all that gets implemented in most implementations, then that's going to be enough evidence I think... 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 Fri Jun 14 07:53:07 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5EEr7k7008254; Fri, 14 Jun 2002 07:53:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5EEr7VH008253; Fri, 14 Jun 2002 07:53:07 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5EEr3k7008246 for ; Fri, 14 Jun 2002 07:53:03 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA00959 for ; Fri, 14 Jun 2002 07:53:07 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA27406 for ; Fri, 14 Jun 2002 08:53:07 -0600 (MDT) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g5EEj7Hs006693; Fri, 14 Jun 2002 07:45:07 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ABW28101; Fri, 14 Jun 2002 07:42:08 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA12640; Fri, 14 Jun 2002 07:45:01 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15626.365.508904.395619@thomasm-u1.cisco.com> Date: Fri, 14 Jun 2002 07:45:01 -0700 (PDT) To: Robert Elz Cc: "Bound, Jim" , sommerfeld@east.sun.com, "Michel Py" , "Bob Hinden" , "Steven M. Bellovin" , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-Reply-To: <2616.1024038388@munnari.OZ.AU> References: <9C422444DE99BC46B3AD3C6EAFC9711B020B8A0C@tayexc13.americas.cpqcorp.net> <2616.1024038388@munnari.OZ.AU> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert Elz writes: > At MU, we have undergrad student labs, that we basically filter from > the world - they have no end to end connectivity at all. And that has > nothing at all to do with NAT (of which we have none at all) nor with > 1918 addressing (of which we also have none at all). Nor will it have > anything at all to do with site local addresses. Robert, Color me clueless, but why can't you give them a global prefix, but just not advertise their route past the administrative boundary you choose (eg, the lab)? Why is an IETF sanctioned "don't route this prefix beyond where you should route it -- which, by the way, you decide where ``beyond'' is" better than just blackholing the actual prefixes you want to contain? To my mind that seems easier in some sense because it's reactive: ie globally number first, determine who the l00zers are later -- a capability you probably need to have anyway. I guess I don't see what being proactive with special addresses really buys since it's _your_ definition of site -- and its containment thereof that's important. Indeed, site-locals don't really seem to buy much on the manageability front since you still need to decide who gets them and why, and where the boundaries of the site are. And of course, if you ever decide to change your policy (or part of your policy), you don't need to renumber with global prefixes (eg, you want to allow part of your lab to be global visible so they can show the world their new cold fusion results). Mike -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 14 08:00:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5EF09k7008318; Fri, 14 Jun 2002 08:00:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5EF09No008317; Fri, 14 Jun 2002 08:00:09 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5EF06k7008307 for ; Fri, 14 Jun 2002 08:00:06 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA18904 for ; Fri, 14 Jun 2002 08:00:09 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.96.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA24224 for ; Fri, 14 Jun 2002 09:01:57 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g5EExSM06698; Fri, 14 Jun 2002 21:59:28 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g5EExM209063; Fri, 14 Jun 2002 21:59:25 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Thomas Narten cc: ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-Reply-To: <200206141350.g5EDoZu15476@rotala.raleigh.ibm.com> References: <200206141350.g5EDoZu15476@rotala.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 14 Jun 2002 21:59:22 +0700 Message-ID: <9061.1024066762@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 14 Jun 2002 09:50:35 -0400 From: Thomas Narten Message-ID: <200206141350.g5EDoZu15476@rotala.raleigh.ibm.com> | Just because people do something that we feel is unwise, doesn't mean | we should encourge such behavior (either explicitly, or by | silence). Saying "don't do that" is one of the things that the IETF | can do. Of course. But what here is something that we feel to be unwise. Use of NAT to make 1918 addresses "work" in v4 is one, but no-one is suggesting that for v6. Use of 2 faced DNS is another, but while some are suggesting that (why???) that's also something we should do without. But stable addresses ??? | For example, we could arrange to allow sites to obtain globally unique | address space (though non-routable globally) if they want it for | internal numbering. That would address some of the issues that private | addresses of led to. Note that this is something we can't do in IPv4 | because there just aren't enough address for this; IPv6 doesn't have | that constraint. Yes, that would be fine, and that's just what Steve Blake suggested in a message sent a few minute after yours. Stable addressing is what's needed - the bit pattern that identifies it isn't important. But note the bit patterns suggested in Steve's message - his suggestion becomes pretty much the same as the suggestion that I made a long time ago, to stick identifiers in the upper bits of the SL address (he also has NUSLA's in there, just to keep everyone happy - and retains current SL addresses, though I'm not sure why on that) - this suggestion was thrown out when suggested, the NUSLA suggestion was essentially abandoned, and every time anyone suggests putting IDs of any kind in those bits, the suggestion gets laughed at (with no actual technical rationale at all). So my suspicion is that this kind of approach isn't going to work. Your suggestion, which is essentially the same as the one I made a long time ago for all practical purposes, raises the question (or this is what was put to me) of just who is going to administer this extra address space, and wouldn't that be a bunch of extra work that no-one wants to do. At the time (and still) I personally think this is a pathetic excuse for an argument, but it seemed to be the one that convinced people more than anything else - fear of creating another ICANN look-like bureaucracy (or giving that one even more things to make a mess of). kre ps: one final comment on Steve's suggestions - I'm not sure that AS numbers are the ideal thing to use here - for two reasons. One they're already carried around in the routing system, which might lead some people to try and use them to make these addresses globally routable, which would be a big mistake, and second, because they are a routing identifier, I think it would be best not to confuse things by also making them an addressing identifier - allocating numbers is such a trivial task that I think we can just create a new set, or could, if there was any chance of a proposal like this being adopted, which I doubt. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 14 08:00:18 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5EF0Ik7008328; Fri, 14 Jun 2002 08:00:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5EF0Ite008327; Fri, 14 Jun 2002 08:00:18 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5EF0Ck7008320 for ; Fri, 14 Jun 2002 08:00:12 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA18959 for ; Fri, 14 Jun 2002 08:00:16 -0700 (PDT) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA01307 for ; Fri, 14 Jun 2002 09:00:15 -0600 (MDT) Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.04) id 17IsYg-000Ccz-00; Fri, 14 Jun 2002 08:00:15 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: Michael Thomas Cc: ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols References: <9C422444DE99BC46B3AD3C6EAFC9711B020B8A0C@tayexc13.americas.cpqcorp.net> <2616.1024038388@munnari.OZ.AU> <15626.365.508904.395619@thomasm-u1.cisco.com> Message-Id: Date: Fri, 14 Jun 2002 08:00:15 -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Color me clueless, but why can't you give them a > global prefix, but just not advertise their route > past the administrative boundary you choose (eg, > the lab)? Why is an IETF sanctioned "don't route > this prefix beyond where you should route it -- > which, by the way, you decide where ``beyond'' is" > better than just blackholing the actual prefixes > you want to contain? From: Randy Bush To: "Steven M. Bellovin" Cc: ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols Date: Thu, 06 Jun 2002 11:24:57 -0700 > My strong preference would be to drop site-local addresses completely. > I think they're an administrative and technical nightmare. trying to solve a routing problem by an ill-understood addressing hack. randy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 14 08:02:52 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5EF2qk7008370; Fri, 14 Jun 2002 08:02:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5EF2qrW008369; Fri, 14 Jun 2002 08:02:52 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5EF2Xk7008356 for ; Fri, 14 Jun 2002 08:02:33 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA19693 for ; Fri, 14 Jun 2002 08:02:37 -0700 (PDT) Received: from mail6.nc.rr.com (fe6.southeast.rr.com [24.93.67.53]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA25957 for ; Fri, 14 Jun 2002 09:04:27 -0600 (MDT) Received: from mail pickup service by mail6.nc.rr.com with Microsoft SMTPSVC; Fri, 14 Jun 2002 10:39:01 -0400 Received: from ncmx02.mgw.rr.com ([24.93.67.222]) by mail6.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Tue, 11 Jun 2002 19:53:10 -0400 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ncmx02.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5BNr9a2001498 for ; Tue, 11 Jun 2002 19:53:09 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA12555; Tue, 11 Jun 2002 16:52:19 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA19328; Tue, 11 Jun 2002 16:52:16 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BNoqk7012426; Tue, 11 Jun 2002 16:50:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5BNoqBp012425; Tue, 11 Jun 2002 16:50:52 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BNomk7012418 for ; Tue, 11 Jun 2002 16:50:48 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA18888 for ; Tue, 11 Jun 2002 16:50:52 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA05071; Tue, 11 Jun 2002 17:50:51 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5BNoon28264; Tue, 11 Jun 2002 19:50:50 -0400 (EDT) Message-Id: <200206112350.g5BNoon28264@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Alain Durand cc: Keith Moore , Erik Nordmark , Thomas Narten , ipng@sunroof.eng.sun.com Subject: Re: IESG comments on draft-ietf-ipngwg-default-addr-select-06.txt In-reply-to: (Your message of "Tue, 11 Jun 2002 16:38:07 PDT.") <480BE094-7D94-11D6-9BDA-00039376A6AA@sun.com> Date: Tue, 11 Jun 2002 19:50:49 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I would agree there. If an application stores the IP address of its peer > for future use, on a multi-interface node, if link-local addresses are > used and the application did not kept track of the incoming interface, > there would be some issues when it would like to reconnect to its peer. that, and any kind of limited-scope addresses are a pain for apps for which any of the components of that app are not in the same scope as all of the others. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 14 08:13:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5EFD9k7008773; Fri, 14 Jun 2002 08:13:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5EFD87X008772; Fri, 14 Jun 2002 08:13:08 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5EFD5k7008762 for ; Fri, 14 Jun 2002 08:13:05 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA22803 for ; Fri, 14 Jun 2002 08:13:09 -0700 (PDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA02772 for ; Fri, 14 Jun 2002 09:14:59 -0600 (MDT) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g5EF5AIZ015078; Fri, 14 Jun 2002 08:05:32 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ABW28402; Fri, 14 Jun 2002 08:02:14 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA12643; Fri, 14 Jun 2002 08:05:08 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15626.1572.137059.882450@thomasm-u1.cisco.com> Date: Fri, 14 Jun 2002 08:05:08 -0700 (PDT) To: Thomas Narten Cc: Robert Elz , ipng@sunroof.eng.sun.com Subject: Scoped Addresses and Renumbering In-Reply-To: <200206141350.g5EDoZu15476@rotala.raleigh.ibm.com> References: <2688.1024039992@munnari.OZ.AU> <200206141350.g5EDoZu15476@rotala.raleigh.ibm.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas Narten writes: > If the real feeling here is that site locals are bad if they end up > reproducing some of the same problems as private addresses, then we > should produce documents that explain when site-locals can safely be > used (i.e., an applicability statement that describes when the IETF > recommends their use). For other uses that people imagine (or that we > expect they will imagine), but for which we think is a bad idea, we > should say *why* its a bad idea *and* we should suggest a better way > of doing it, so that folks who have a particular problem can choose an > appropriate solution. To my mind, one of the key failure modes of overlay addressing is collisions when the original assumptions of the overlay cease to be true -- like when you get two companies who merge, say, and their net 10 address spaces collide. This drives integration attempts to a great deal of distraction and a Quick Fix NAT(tm) is almost certainly the result. What you'd really like in that situation is to renumber, but color me skeptical that renumbering will ever be "easy" or "automatic", especially when you consider the widespread conflation of addresses as routing tags and as identity. Thus, I think site locals will still beg the Quick Fix NAT(tm). Badness. If we instead say that you should just blackhole otherwise globally routed prefixes at the site boundary, we don't run into this problem. If you have a change of policy, you just change some or all of the prefix that gets blackholed instead of renumbering. Just as easy, if not easier than setting up NAT's, IMHO. Mike -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 14 08:16:29 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5EFGTk7008822; Fri, 14 Jun 2002 08:16:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5EFGTA2008821; Fri, 14 Jun 2002 08:16:29 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5EFGQk7008814 for ; Fri, 14 Jun 2002 08:16:26 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA07758 for ; Fri, 14 Jun 2002 08:16:30 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.96.5]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA25518 for ; Fri, 14 Jun 2002 08:16:29 -0700 (PDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g5EFFnM07166; Fri, 14 Jun 2002 22:15:49 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g5EFFj209644; Fri, 14 Jun 2002 22:15:45 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Michael Thomas cc: "Bound, Jim" , sommerfeld@east.sun.com, "Michel Py" , "Bob Hinden" , "Steven M. Bellovin" , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-Reply-To: <15626.365.508904.395619@thomasm-u1.cisco.com> References: <15626.365.508904.395619@thomasm-u1.cisco.com> <9C422444DE99BC46B3AD3C6EAFC9711B020B8A0C@tayexc13.americas.cpqcorp.net> <2616.1024038388@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 14 Jun 2002 22:15:45 +0700 Message-ID: <9642.1024067745@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 14 Jun 2002 07:45:01 -0700 (PDT) From: Michael Thomas Message-ID: <15626.365.508904.395619@thomasm-u1.cisco.com> | Color me clueless, but why can't you give them a | global prefix, but just not advertise their route | past the administrative boundary you choose (eg, | the lab)? That is (essentially) exactly what we do (though for obscure reasons we can't fix this using routing, and instead use packet filtering). You seem to have misunderstood the point of my message (perhaps I wasn't clear), but it was just to show that it isn't (not that it is) the existence of site local addresses (private addresses) that defeats end to end - it is the absence of global addresses, and/or filtering. | And of course, if you ever decide to change your | policy (or part of your policy), you don't need to | renumber with global prefixes (eg, you want to | allow part of your lab to be global visible so | they can show the world their new cold fusion | results). No no - I'd never do that. My philosphy is that *everything* gets a global address, no matter what (disconnected sites that have no ISP to provide them being the one exception). If a site wants, its nodes also get site local addresses, as an additional address. Access control is done based upon filtering (at routers, and at the nodes themselves where possible) - packet filtering &/or route filtering. Certainly not based upon address - the occasional suggestions that private addressing provides any kind of security or control are just ludicrous. What they provide is internal address stability. That's why I don't want to lose them (unless something equivalent replaces them, or we achieve address stability some other way). 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 Fri Jun 14 08:22:54 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5EFMrk7008945; Fri, 14 Jun 2002 08:22:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5EFMrhC008944; Fri, 14 Jun 2002 08:22:53 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5EFMok7008937 for ; Fri, 14 Jun 2002 08:22:50 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA26371 for ; Fri, 14 Jun 2002 08:22:55 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.96.5]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA01954 for ; Fri, 14 Jun 2002 08:22:53 -0700 (PDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g5EFMCM07418; Fri, 14 Jun 2002 22:22:12 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g5EFM5209795; Fri, 14 Jun 2002 22:22:09 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Randy Bush cc: Michael Thomas , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-Reply-To: References: <9C422444DE99BC46B3AD3C6EAFC9711B020B8A0C@tayexc13.americas.cpqcorp.net> <2616.1024038388@munnari.OZ.AU> <15626.365.508904.395619@thomasm-u1.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 14 Jun 2002 22:22:05 +0700 Message-ID: <9793.1024068125@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 14 Jun 2002 08:00:15 -0700 From: Randy Bush Message-ID: | trying to solve a routing problem by an ill-understood addressing | hack. This is the second time you have said that, and it doesn't get any more accurate with the re-telling. SL addresses are only a second order symptom of a routing problem, and are most certainly not any kind of attempt to solve it. The closest they come to that is that they're an attempt to cope with the current best solution to the routing problem that anyone has been able to find - that is, to solve routing, we're requiring topologically meaningful addresses, and as topology isn't stable, addresses can't be stable either. If you have some other solution to the routing problem, and can even suggest a direction that might allow non-topological routing of an address space of the order of 2^48 entries, then we're all waiting to hear it. In the meantime, please recognise that those of us who have to live with the consequences of the best solution currently available and if there's no sanctioned way of getting at least local stable addresses, then we will simply invent our own - "stealing" whatever address space is needed to make it work. 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 Fri Jun 14 08:37:31 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5EFbVk7009031; Fri, 14 Jun 2002 08:37:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5EFbVnD009030; Fri, 14 Jun 2002 08:37:31 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5EFbSk7009023 for ; Fri, 14 Jun 2002 08:37:28 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA00021 for ; Fri, 14 Jun 2002 08:37:32 -0700 (PDT) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA07790 for ; Fri, 14 Jun 2002 08:37:32 -0700 (PDT) Subject: RE: Scoped Addresses and Renumbering Date: Fri, 14 Jun 2002 08:37:31 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046405E10D@server2000.arneill-py.sacramento.ca.us> X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 X-MS-TNEF-Correlator: Thread-Topic: Scoped Addresses and Renumbering content-class: urn:content-classes:message Thread-Index: AcITt3qh4qM1OTYVRJi47K5b3he93QAAFmSA From: "Michel Py" To: "Michael Thomas" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5EFbSk7009024 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Michael has very good points here: It would be a lot better to have globally unique addresses rather than re-usable SLs. But how do we do that? Well, if we could allocate a /3 and make: 001x:xxxx:yyyy:SLA:E:U:I:64 = my address 010x:xxxx:yyyy:SLA:E:U:I:64 = corresponding private, 010::/3 blackholed by policy. That would be nice, and I'd drop SLs in a heartbeat, but how realistic is that? Michel. > Michael Thomas wrote: > To my mind, one of the key failure modes of > overlay addressing is collisions when the original > assumptions of the overlay cease to be true -- > like when you get two companies who merge, say, > and their net 10 address spaces collide. This > drives integration attempts to a great deal of > distraction and a Quick Fix NAT(tm) is almost > certainly the result. > What you'd really like in that situation is to > renumber, but color me skeptical that renumbering > will ever be "easy" or "automatic", especially > when you consider the widespread conflation of > addresses as routing tags and as identity. Thus, > I think site locals will still beg the Quick > Fix NAT(tm). Badness. > If we instead say that you should just blackhole > otherwise globally routed prefixes at the site > boundary, we don't run into this problem. If you > have a change of policy, you just change some or > all of the prefix that gets blackholed instead of > renumbering. Just as easy, if not easier than > setting up NAT's, IMHO. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 14 08:39:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5EFdZk7009069; Fri, 14 Jun 2002 08:39:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5EFdYNs009068; Fri, 14 Jun 2002 08:39:34 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5EFdVk7009059 for ; Fri, 14 Jun 2002 08:39:31 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA14587 for ; Fri, 14 Jun 2002 08:39:36 -0700 (PDT) Received: from emerson.torrentnet.com (emerson.torrentnet.com [198.78.51.110]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA10666 for ; Fri, 14 Jun 2002 09:39:35 -0600 (MDT) Received: from imperial.torrentnet.com (imperial.torrentnet.com [198.78.51.109]) by emerson.torrentnet.com (8.11.2/8.11.2) with ESMTP id g5EFdTB90033; Fri, 14 Jun 2002 11:39:30 -0400 (EDT) Received: from castillo.torrentnet.com (castillo.torrentnet.com [4.18.161.34]) by imperial.torrentnet.com (8.11.2/8.11.2) with ESMTP id g5EFdTx44535; Fri, 14 Jun 2002 11:39:29 -0400 (EDT) Received: from castillo.torrentnet.com (localhost.torrentnet.com [127.0.0.1]) by castillo.torrentnet.com (8.9.3/8.9.3) with ESMTP id LAA11227; Fri, 14 Jun 2002 11:39:28 -0400 (EDT) Message-Id: <200206141539.LAA11227@castillo.torrentnet.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Robert Elz cc: Thomas Narten , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-reply-to: Your message of "Fri, 14 Jun 2002 21:59:22 +0700." <9061.1024066762@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 14 Jun 2002 11:39:28 -0400 From: Steve Blake Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert Elz wrote: > Yes, that would be fine, and that's just what Steve Blake suggested in > a message sent a few minute after yours. Stable addressing is what's > needed - the bit pattern that identifies it isn't important. > > But note the bit patterns suggested in Steve's message - his suggestion > becomes pretty much the same as the suggestion that I made a long time > ago, to stick identifiers in the upper bits of the SL address (he also No claims of originality on my part. > has NUSLA's in there, just to keep everyone happy - and retains current > SL addresses, though I'm not sure why on that) - this suggestion was They are out-of-the-box, for those (the majority of users, probably) who can't be bothered to configure a NUSLA. > thrown out when suggested, the NUSLA suggestion was essentially abandoned, > and every time anyone suggests putting IDs of any kind in those bits, the > suggestion gets laughed at (with no actual technical rationale at all). > > So my suspicion is that this kind of approach isn't going to work. > > Your suggestion, which is essentially the same as the one I made a long > time ago for all practical purposes, raises the question (or this is what > was put to me) of just who is going to administer this extra address space, > and wouldn't that be a bunch of extra work that no-one wants to do. > > At the time (and still) I personally think this is a pathetic excuse for > an argument, but it seemed to be the one that convinced people more than > anything else - fear of creating another ICANN look-like bureaucracy (or > giving that one even more things to make a mess of). > > kre > > ps: one final comment on Steve's suggestions - I'm not sure that AS > numbers are the ideal thing to use here - for two reasons. One they're > already carried around in the routing system, which might lead some people > to try and use them to make these addresses globally routable, which would > be a big mistake, and second, because they are a routing identifier, I > think it would be best not to confuse things by also making them an > addressing identifier - allocating numbers is such a trivial task that > I think we can just create a new set, or could, if there was any chance of > a proposal like this being adopted, which I doubt. AS numbers have an existing infrastructure for allocation, and they are unique. The set of nets that would ever care about true uniqueness probably intersects heavily with the set that would own an AS# anyway (although the first set might be the null-set for all I know). As to whether they are ever globally routable: that is a business issue between a customer and his provider. Any IETF prohibitions on this would be so much hot air. Note that draft-hain-ipv6-pi-addr-02.txt addresses are a perfectly suitable alternative to my proposal (at least in some cases), but they aren't zero-cost to acquire either. Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven L. Blake Ericsson IP Infrastructure 919-472-9913 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 14 08:57:51 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5EFvok7009209; Fri, 14 Jun 2002 08:57:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5EFvoY3009208; Fri, 14 Jun 2002 08:57:50 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5EFvkk7009201 for ; Fri, 14 Jun 2002 08:57:47 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA19430; Fri, 14 Jun 2002 11:57:49 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g5EFvnZs020596; Fri, 14 Jun 2002 11:57:49 -0400 (EDT) Message-Id: <200206141557.g5EFvnZs020596@thunk.east.sun.com> From: Bill Sommerfeld To: Robert Elz cc: rbrabson@us.ibm.com, "Brian Haberman" , ipng@sunroof.eng.sun.com, "Bound, Jim" , "JINMEI Tatuya / ????" , "Margaret Wasserman" Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-Reply-To: Your message of "Fri, 14 Jun 2002 21:48:11 +0700." <8400.1024066091@munnari.OZ.AU> Reply-to: sommerfeld@east.sun.com Date: Fri, 14 Jun 2002 11:57:49 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Yes, a router with multiple connected sites is certainly the case > where the biggest savings from eliminating or restricting site locals > would be found. Hosts have routing tables, too. A host connected to multiple sites needs nearly all of the mechanisms that a multi-site router needs. If that becomes common, then the approach to SL's that required a DMZ between sites (no nodes in 2 sites) may become the standard way to operate. I don't think such a requirement will be meaningful because "node" is underspecified -- someone will argue that you can meet this requirement in a single box running a single OS image by supporting two virtual nodes connected by a virtual DMZ, and we're back to where we started. - 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 Jun 14 09:02:34 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5EG2Yk7009248; Fri, 14 Jun 2002 09:02:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5EG2YDa009247; Fri, 14 Jun 2002 09:02:34 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5EG2Vk7009240 for ; Fri, 14 Jun 2002 09:02:31 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA21805 for ; Fri, 14 Jun 2002 09:02:36 -0700 (PDT) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA28543 for ; Fri, 14 Jun 2002 10:02:35 -0600 (MDT) Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.05) id 17ItX1-000FzW-00; Fri, 14 Jun 2002 09:02:35 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Robert Elz Cc: ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols References: <8400.1024066091@munnari.OZ.AU> Message-Id: Date: Fri, 14 Jun 2002 09:02:35 -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > then the approach to SL's that required a DMZ between sites (no > nodes in 2 sites) may become the standard way to operate. nice way to sell un-needed extra routers randy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 14 09:14:29 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5EGESk7009304; Fri, 14 Jun 2002 09:14:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5EGES8u009303; Fri, 14 Jun 2002 09:14:28 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5EGEPk7009296 for ; Fri, 14 Jun 2002 09:14:25 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA25716 for ; Fri, 14 Jun 2002 09:14:30 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.96.5]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA01536 for ; Fri, 14 Jun 2002 09:14:16 -0700 (PDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g5EGDbM09054; Fri, 14 Jun 2002 23:13:37 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g5EGDW211264; Fri, 14 Jun 2002 23:13:33 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Steve Blake cc: Thomas Narten , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-Reply-To: <200206141539.LAA11227@castillo.torrentnet.com> References: <200206141539.LAA11227@castillo.torrentnet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 14 Jun 2002 23:13:32 +0700 Message-ID: <11262.1024071212@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 14 Jun 2002 11:39:28 -0400 From: Steve Blake Message-ID: <200206141539.LAA11227@castillo.torrentnet.com> | They are out-of-the-box, for those (the majority of users, probably) who | can't be bothered to configure a NUSLA. OK, but then all the "problems" that people keep complaining about remain. | AS numbers have an existing infrastructure for allocation, and they are | unique. Yes, but they're not allocated to all sites normally - I have never been at a site that had its own AS# I think, even back in the old days when I was assisting the first version of AARnet, there was no AS# (for the net which linked all of Aus...) - that's changed of course, but most end user sites currently don't need an AS#, so allocating them for this would vastly change the dynamics (and 32 bits might not be enough). | The set of nets that would ever care about true uniqueness probably | intersects heavily with the set that would own an AS# anyway (although the | first set might be the null-set for all I know). Possibly, but that assumes that the NUSLA part remains, and that stuff seems to have been written off previously (for whatever reason). | Note that draft-hain-ipv6-pi-addr-02.txt addresses are a perfectly suitable | alternative to my proposal (at least in some cases), but they aren't | zero-cost to acquire either. Ah yes, Tony's draft has some very interesting ideas, and is almost certainly worthy of much more discussion that it seems to have elicited (for which I apologise to him as one of those who never found the time to comment, though I have read it as new versions appeared). Unfortunately, while it might make a nice alternative to provider based addressing as a global address method (for some) if it can be made to work (which largely depends upon the routing people managing to support the address space at a fine enough resolution to make it feasible to use), it isn't an alternative to site locals at all. Addresses there are still constrained - I don't get allocated one which I get to keep forever, no matter what, which is what SL addresses give me (with or without some higher layer identifier embedded in them). So, as an alternative to SL, they don't work, regardless of how good they may be as global addresses. Of course, they also weren't designed (I believe) as an alternative to SL, so this is probably no surprise. 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 Fri Jun 14 09:25:16 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5EGPFk7009363; Fri, 14 Jun 2002 09:25:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5EGPFSo009362; Fri, 14 Jun 2002 09:25:15 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5EGPCk7009352 for ; Fri, 14 Jun 2002 09:25:12 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA19244 for ; Fri, 14 Jun 2002 09:25:17 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.96.5]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA11465 for ; Fri, 14 Jun 2002 10:25:15 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g5EGOZM09321; Fri, 14 Jun 2002 23:24:35 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g5EGOW211912; Fri, 14 Jun 2002 23:24:32 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: sommerfeld@east.sun.com cc: ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-Reply-To: <200206141557.g5EFvnZs020596@thunk.east.sun.com> References: <200206141557.g5EFvnZs020596@thunk.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 14 Jun 2002 23:24:32 +0700 Message-ID: <11910.1024071872@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 14 Jun 2002 11:57:49 -0400 From: Bill Sommerfeld Message-ID: <200206141557.g5EFvnZs020596@thunk.east.sun.com> | Hosts have routing tables, too. Yes, but it is the routing protocols where the worst of the extra mechanism is required I believe, and hosts generally don't, or shouldn't, be running those. | I don't think such a requirement will be meaningful because "node" is | underspecified -- someone will argue that you can meet this | requirement in a single box running a single OS image by supporting | two virtual nodes connected by a virtual DMZ, and we're back to where | we started. I didn't mention requirement - in general unless there's a good reason, I don't like requirements, I like flexibility. If someone wants to set up something like that (or simply support what we currently define as the way SL's work) then fine - the issue here remember is the apparent implementation complexity of making all that work properly. Anyone who can cope with all of that ought to be free to do so, they're not going to harm anyone else. Whether they do it using a virtual DMZ, or any other way, shouldn't bother us. 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 Fri Jun 14 09:39:26 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5EGdQk7009468; Fri, 14 Jun 2002 09:39:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5EGdPSe009467; Fri, 14 Jun 2002 09:39:25 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5EGdMk7009460 for ; Fri, 14 Jun 2002 09:39:22 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA24862 for ; Fri, 14 Jun 2002 09:39:27 -0700 (PDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA28730 for ; Fri, 14 Jun 2002 10:39:26 -0600 (MDT) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g5EGVrIZ022963; Fri, 14 Jun 2002 09:31:53 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ABW30277; Fri, 14 Jun 2002 09:28:59 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA12655; Fri, 14 Jun 2002 09:31:53 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15626.6777.20313.190032@thomasm-u1.cisco.com> Date: Fri, 14 Jun 2002 09:31:53 -0700 (PDT) To: Robert Elz Cc: Steve Blake , Thomas Narten , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-Reply-To: <11262.1024071212@munnari.OZ.AU> References: <200206141539.LAA11227@castillo.torrentnet.com> <11262.1024071212@munnari.OZ.AU> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert Elz writes: > Addresses there are still constrained - I don't get allocated one which > I get to keep forever, no matter what, which is what SL addresses give me > (with or without some higher layer identifier embedded in them). > So, as an alternative to SL, they don't work, regardless of how good > they may be as global addresses. Of course, they also weren't designed > (I believe) as an alternative to SL, so this is probably no surprise. In the good old days, wasn't it rather common for clueless newbies to slavishly number their networks 192.6 or somesuch which was what they found in the network administrator manual examples? They worked just great up until the time they wanted to connect to the real net, right? Assuming that you _never_ want to globally advertise that prefix -- which is what site locals are intended for -- does it actually make any difference which prefix you choose? Why does IETF have to sanction one? Why not just let people make their own decisions? It's not like there's any more or less work if they change their minds, right? BTW: isn't there already an implicit "site local" address space for v6 with net 10 v4 mapped address? Mike -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 14 09:47:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5EGldk7009551; Fri, 14 Jun 2002 09:47:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5EGldDi009550; Fri, 14 Jun 2002 09:47: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.12.4/8.12.4) with ESMTP id g5EGlak7009543 for ; Fri, 14 Jun 2002 09:47:36 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA07149 for ; Fri, 14 Jun 2002 09:47:41 -0700 (PDT) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA27914; Fri, 14 Jun 2002 10:49:31 -0600 (MDT) Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.05) id 17IuEe-000DxB-00; Fri, 14 Jun 2002 09:47:40 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Bill Sommerfeld Cc: ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols References: <8400.1024066091@munnari.OZ.AU> <200206141557.g5EFvnZs020596@thunk.east.sun.com> Message-Id: Date: Fri, 14 Jun 2002 09:47:40 -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Hosts have routing tables, too. hosts have forwarding tables. a very few end hosts have routing tables. of those which have routing tables, a very few of those, usually researchers' boxes, learn more than default. randy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 14 10:01:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5EH1ik7009600; Fri, 14 Jun 2002 10:01:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5EH1iJh009599; Fri, 14 Jun 2002 10:01:44 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5EH1fk7009592 for ; Fri, 14 Jun 2002 10:01:41 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA27672 for ; Fri, 14 Jun 2002 10:01:46 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.96.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA06053 for ; Fri, 14 Jun 2002 11:03:31 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g5EH10M10275; Sat, 15 Jun 2002 00:01:00 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g5EH0t213078; Sat, 15 Jun 2002 00:00:55 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Michael Thomas cc: Steve Blake , Thomas Narten , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-Reply-To: <15626.6777.20313.190032@thomasm-u1.cisco.com> References: <15626.6777.20313.190032@thomasm-u1.cisco.com> <200206141539.LAA11227@castillo.torrentnet.com> <11262.1024071212@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 15 Jun 2002 00:00:55 +0700 Message-ID: <13076.1024074055@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 14 Jun 2002 09:31:53 -0700 (PDT) From: Michael Thomas Message-ID: <15626.6777.20313.190032@thomasm-u1.cisco.com> | In the good old days, wasn't it rather common | for clueless newbies to slavishly number their | networks 192.6 or somesuch which was what they | found in the network administrator manual examples? Yes (that wasn't the number, it used to be imprinted on my brain, but fortunately these days it is seen so rarely that I have forgotten the value - I think it had a 200 in it though, not that it matters - 192.9.200 ??). It was this kind of thing that led to 1918 addresses - the IETF invented (allocated) them precisely because of the problems that this (and other number "borrowing") caused. | They worked just great up until the time they | wanted to connect to the real net, right? yes. | Assuming that you _never_ want to globally | advertise that prefix -- which is what site | locals are intended for -- does it actually | make any difference which prefix you choose? Yes. Because if you happen to choose a prefix that is someone else's globally allocated prefix, you can never talk to them. Or more likely, you find you have to renumber because you want to talk to them (if you're lucky, and never do, there's no issue). If you're ever going to be in the position of having to renumber then the address you have isn't stable. Of course, if "you" happen to be a large ISP, instead of an end-site, then not only can "you" not communicate with the true assignee of the address, but nor can anyone else who uses you for connectivity. | Why does IETF have to sanction one? One, as distinct from two or three or ... it doesn't. One as distinct from zero, so you know the address that you're going to be using will never be one that someone else uses (and you might need to use to communicate with them - their using it as a private address is harmless of course). | Why not just let people make their own decisions? They don't have enough information to make a good decision. Allocate several prefixes (like was done in 1918) and allow people to choose which they want to use if you like, that's fine - but they need to be prefixes reserved for the purpose. | BTW: isn't there already an implicit "site local" | address space for v6 with net 10 v4 mapped | address? If you mean the ::/80 address space (::/96 and ::FFFF:/96) then if there's any addresses that it would be nice to see vanish, it would be those (and one hopes that they will do so once v4 has finally departed - sometime in the far future). In any case these ones don't work, because you don't get a /48 prefix out of them, If you mean 2002:0A00::/24 (which aren't usually called v4 mapped addresses I thought) then that's certainly a possibility, but it is also just a bit pattern variation on fec0::/10, and I thought we'd all agreed that bit patterns cannot possibly be what's important here. I don't care what the bit pattern is, just as long as it exists (but since fec0::/10 already exists, I'd want to see a good justification to alter it). I would also expect 2002::/16 to vanish, sometime in the far future, as well of course, that one may even happen before the other as 2002 remains viable only while the IPv4 global routing system works, ::/80 (the two sub-groups of that of relevance) is still usable while there's any IPv4 left anywhere. 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 Fri Jun 14 10:34:36 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5EHYZk7009684; Fri, 14 Jun 2002 10:34:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5EHYZIc009683; Fri, 14 Jun 2002 10:34:35 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5EHYWk7009676 for ; Fri, 14 Jun 2002 10:34:32 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA16492 for ; Fri, 14 Jun 2002 10:34:35 -0700 (PDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA22096 for ; Fri, 14 Jun 2002 10:34:35 -0700 (PDT) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g5EHQfuF022824; Fri, 14 Jun 2002 10:26:41 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ABW32039; Fri, 14 Jun 2002 10:23:51 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA12664; Fri, 14 Jun 2002 10:26:45 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15626.10068.955615.342647@thomasm-u1.cisco.com> Date: Fri, 14 Jun 2002 10:26:44 -0700 (PDT) To: Robert Elz Cc: Michael Thomas , Steve Blake , Thomas Narten , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-Reply-To: <13076.1024074055@munnari.OZ.AU> References: <15626.6777.20313.190032@thomasm-u1.cisco.com> <200206141539.LAA11227@castillo.torrentnet.com> <11262.1024071212@munnari.OZ.AU> <13076.1024074055@munnari.OZ.AU> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert Elz writes: > It was this kind of thing that led to 1918 addresses - the IETF > invented (allocated) them precisely because of the problems that > this (and other number "borrowing") caused. But the real problem was renumbering. That still hasn't gone away. > | Assuming that you _never_ want to globally > | advertise that prefix -- which is what site > | locals are intended for -- does it actually > | make any difference which prefix you choose? > > Yes. Because if you happen to choose a prefix that is someone > else's globally allocated prefix, you can never talk to them. > Or more likely, you find you have to renumber because you want > to talk to them (if you're lucky, and never do, there's no issue). Uh, except you can't talk to them anyway because all you have is a non-globally-routable address, right? > If you're ever going to be in the position of having to renumber > then the address you have isn't stable. See above. > | Why does IETF have to sanction one? > > One, as distinct from two or three or ... it doesn't. One as > distinct from zero, so you know the address that you're going to > be using will never be one that someone else uses (and you might > need to use to communicate with them - their using it as a private > address is harmless of course). Except you can't communicate with them unless you renumber or NAT anyway. > | Why not just let people make their own decisions? > > They don't have enough information to make a good decision. > Allocate several prefixes (like was done in 1918) and allow > people to choose which they want to use if you like, that's > fine - but they need to be prefixes reserved for the purpose. Except neither does IETF, it seems. There's no such thing as an long term stable globally routable prefix. If you want a globally routable address, you have to deal with renumbering, regardless of whether you got your "private" prefix from RFC 1918, or the back of an old Ultrix manual. > | BTW: isn't there already an implicit "site local" > | address space for v6 with net 10 v4 mapped > | address? > > If you mean the ::/80 address space (::/96 and ::FFFF:/96) then [] > If you mean 2002:0A00::/24 (which aren't usually called v4 mapped [] I'm not sure which one I mean, honestly, and am too lazy to look it up. However, it seems that if you have any v6 prefix which maps the v4 space, you automatically get net 10's for the bargain, and all of the hassles they entail, including dealing with the v4 overlay network routing. Keeping "private" addresses as a v4 artifact -- which are still accessible to v6 if you are so inclined -- may be a way out of this... Mike -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 14 10:58:19 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5EHwIk7009835; Fri, 14 Jun 2002 10:58:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5EHwI9d009834; Fri, 14 Jun 2002 10:58:18 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5EHwFk7009827 for ; Fri, 14 Jun 2002 10:58:15 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA26743 for ; Fri, 14 Jun 2002 10:58:18 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.96.5]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA03810 for ; Fri, 14 Jun 2002 11:58:13 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g5EHvYM11963; Sat, 15 Jun 2002 00:57:34 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g5EHvQ214820; Sat, 15 Jun 2002 00:57:26 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Michael Thomas cc: Steve Blake , Thomas Narten , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-Reply-To: <15626.10068.955615.342647@thomasm-u1.cisco.com> References: <15626.10068.955615.342647@thomasm-u1.cisco.com> <15626.6777.20313.190032@thomasm-u1.cisco.com> <200206141539.LAA11227@castillo.torrentnet.com> <11262.1024071212@munnari.OZ.AU> <13076.1024074055@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 15 Jun 2002 00:57:26 +0700 Message-ID: <14818.1024077446@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 14 Jun 2002 10:26:44 -0700 (PDT) From: Michael Thomas Message-ID: <15626.10068.955615.342647@thomasm-u1.cisco.com> | But the real problem was renumbering. That | still hasn't gone away. No, and that's why we need these things - so when renumbering happens, our internal addresses (the ones I use to mount my filesystems from the fileserver, etc, which stay in use for months or years between reboots) don't alter. | Uh, except you can't talk to them anyway because | all you have is a non-globally-routable | address, right? No, not at all. That was what happened for v4, but here we're talking about an address you have in addition to your globally reachable address, not instead of it. | Except neither does IETF, it seems. There's | no such thing as an long term stable | globally routable prefix. No, but we're talking about SL here, nothing globally routable about it at all. And while a globally routable permanent static address would be nice to have, at the minute that doesn't look to be feasible. Again, that's exactly why we (I anyway) want SL addresses. | If you want a | globally routable address, you have to deal | with renumbering, regardless of whether you | got your "private" prefix from RFC 1918, or the | back of an old Ultrix manual. Sure, but that other address remains working just fine, for all the internal connections - no need to change it, ever. That is, provided it is an address that no-one else will ever be using for their global communications, which is another way of saying, providing it is a reserved address. | I'm not sure which one I mean, honestly, and am | too lazy to look it up. However, it seems that | if you have any v6 prefix which maps the | v4 space, you automatically get net 10's for | the bargain, and all of the hassles they | entail, Yes, you do. That's 2002:0A00::/24 But 2002::/16 will remain allocated only as long as the v4 global routing system remains to make it feasible, then it will vanish back to unallocated space, as it would no longer serve any function (it will probably take a long time before it gets reused, but eventually I'd expect it to be). Then 2002:0axx:... will just be someone else's global address. | Keeping "private" addresses | as a v4 artifact -- which are still accessible | to v6 if you are so inclined -- may be a way | out of this... But aside from being a different bit pattern than fec0::/10 what's the difference supposed to be? (Ignoring for now that 2002::/16 will not always be available for the purpose). 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 Fri Jun 14 11:24:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5EIOtk7010091; Fri, 14 Jun 2002 11:24:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5EIOtrF010090; Fri, 14 Jun 2002 11:24:55 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5EIOpk7010083 for ; Fri, 14 Jun 2002 11:24:51 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA13597 for ; Fri, 14 Jun 2002 11:24:55 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA08996 for ; Fri, 14 Jun 2002 12:24:55 -0600 (MDT) Received: from kenawang ([147.11.233.39]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id LAA07149; Fri, 14 Jun 2002 11:23:20 -0700 (PDT) Message-Id: <4.2.2.20020614141439.02548370@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 14 Jun 2002 14:23:26 -0400 To: Robert Elz From: Margaret Wasserman Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols Cc: ipng@sunroof.eng.sun.com In-Reply-To: <11910.1024071872@munnari.OZ.AU> References: <200206141557.g5EFvnZs020596@thunk.east.sun.com> <200206141557.g5EFvnZs020596@thunk.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > | Hosts have routing tables, too. > >Yes, but it is the routing protocols where the worst of the extra >mechanism is required I believe, and hosts generally don't, or >shouldn't, be running those. There is additional complexity in a multi-sited host, even if it doesn't forward or run routing protocols. Even if a multi-sited host has no routing protocols and a primitive forwarding table (i.e. an ICMP redirect cache), there will still be increased implementation complexity. The multi-sited host will need to maintain multiple forwarding tables (one for the global scope, and one for each attached site), will need to choose the correct table as part of the next-hop lookup for outbound traffic, and will need to make sure that ICMP redirects are applied to the correct table when received. And what do we actually get for this added complexity? Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 14 11:46:02 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5EIk1k7010247; Fri, 14 Jun 2002 11:46:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5EIk12E010246; Fri, 14 Jun 2002 11:46:01 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5EIjvk7010239 for ; Fri, 14 Jun 2002 11:45:57 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA07908 for ; Fri, 14 Jun 2002 11:46:00 -0700 (PDT) Received: from esunmail ([129.147.58.122]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA02361 for ; Fri, 14 Jun 2002 12:47:51 -0600 (MDT) Received: from xpa-fe1 (esunmail-ge1 [129.147.58.122]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 0.3 (built May 13 2002)) with ESMTP id <0GXP00404LGMNL@edgemail1.Central.Sun.COM> for ipng@sunroof.eng.sun.com; Fri, 14 Jun 2002 12:46:00 -0600 (MDT) Received: from sun.com ([129.146.85.69]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 0.2 (built Apr 26 2002)) with ESMTPSA id <0GXP001XYLGMXP@mail.sun.net> for ipng@sunroof.eng.sun.com; Fri, 14 Jun 2002 12:45:59 -0600 (MDT) Date: Fri, 14 Jun 2002 11:45:16 -0700 From: Alain Durand Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols To: Robert Elz Cc: Michael Thomas , Steve Blake , Thomas Narten , ipng@sunroof.eng.sun.com Message-id: <3D0A39BC.69743C67@sun.com> MIME-version: 1.0 X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) Content-type: text/plain; charset=iso-8859-15 Content-transfer-encoding: 7BIT X-Accept-Language: en References: <15626.10068.955615.342647@thomasm-u1.cisco.com> <15626.6777.20313.190032@thomasm-u1.cisco.com> <200206141539.LAA11227@castillo.torrentnet.com> <11262.1024071212@munnari.OZ.AU> <13076.1024074055@munnari.OZ.AU> <14818.1024077446@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert Elz wrote: > Date: Fri, 14 Jun 2002 10:26:44 -0700 (PDT) > From: Michael Thomas > Message-ID: <15626.10068.955615.342647@thomasm-u1.cisco.com> > > | But the real problem was renumbering. That > | still hasn't gone away. > > No, and that's why we need these things - so when renumbering happens, > our internal addresses (the ones I use to mount my filesystems from > the fileserver, etc, which stay in use for months or years between > reboots) don't alter. Site local addresses save your from renumbering if you change ISP. They don't help if you merge two networks. Subnet ID may collide. - 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 Jun 14 11:51:40 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5EIpek7010305; Fri, 14 Jun 2002 11:51:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5EIpdiT010304; Fri, 14 Jun 2002 11:51:39 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5EIpak7010297 for ; Fri, 14 Jun 2002 11:51:37 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA10129 for ; Fri, 14 Jun 2002 11:51:41 -0700 (PDT) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA05156; Fri, 14 Jun 2002 12:53:31 -0600 (MDT) Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.05) id 17IwAe-000Foq-00; Fri, 14 Jun 2002 11:51:40 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Alain Durand Cc: ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols References: <15626.10068.955615.342647@thomasm-u1.cisco.com> <15626.6777.20313.190032@thomasm-u1.cisco.com> <200206141539.LAA11227@castillo.torrentnet.com> <11262.1024071212@munnari.OZ.AU> <13076.1024074055@munnari.OZ.AU> <14818.1024077446@munnari.OZ.AU> <3D0A39BC.69743C67@sun.com> Message-Id: Date: Fri, 14 Jun 2002 11:51:40 -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Site local addresses save your from renumbering if you change ISP. help with renumbering is good. help which non-trivially complicates addressing, forwarding, and routing is very bad. the long-run cost in complexity, bugs, unreliability, ... of the latter will overweigh the savings of the former. randy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 14 17:33:28 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5F0XSk7011637; Fri, 14 Jun 2002 17:33:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5F0XR36011636; Fri, 14 Jun 2002 17:33:27 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5F0XOk7011629 for ; Fri, 14 Jun 2002 17:33:25 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA21220 for ; Fri, 14 Jun 2002 17:33:28 -0700 (PDT) Received: from web21009.mail.yahoo.com (web21009.mail.yahoo.com [216.136.227.63]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with SMTP id SAA01796 for ; Fri, 14 Jun 2002 18:33:28 -0600 (MDT) Message-ID: <20020615003327.49554.qmail@web21009.mail.yahoo.com> Received: from [128.107.253.37] by web21009.mail.yahoo.com via HTTP; Fri, 14 Jun 2002 17:33:27 PDT Date: Fri, 14 Jun 2002 17:33:27 -0700 (PDT) From: Daniel Ng Subject: Is IPv6 Tiny Fragment Attack possible? To: ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk RFC 3128 described the way to attack IPv4 network using tiny fragment. Can the same thing happen to IPv6 network? Thanks, Daniel __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 14 18:00:05 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5F105k7011708; Fri, 14 Jun 2002 18:00:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5F105p3011707; Fri, 14 Jun 2002 18:00:05 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5F101k7011700 for ; Fri, 14 Jun 2002 18:00:01 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA04255 for ; Fri, 14 Jun 2002 18:00:05 -0700 (PDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA17478 for ; Fri, 14 Jun 2002 19:00:04 -0600 (MDT) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g5F0qUIZ019689; Fri, 14 Jun 2002 17:52:30 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ABW43512; Fri, 14 Jun 2002 17:49:35 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id RAA12721; Fri, 14 Jun 2002 17:52:29 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15626.36812.886269.733294@thomasm-u1.cisco.com> Date: Fri, 14 Jun 2002 17:52:28 -0700 (PDT) To: Robert Elz Cc: Michael Thomas , Steve Blake , Thomas Narten , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-Reply-To: <14818.1024077446@munnari.OZ.AU> References: <15626.10068.955615.342647@thomasm-u1.cisco.com> <15626.6777.20313.190032@thomasm-u1.cisco.com> <200206141539.LAA11227@castillo.torrentnet.com> <11262.1024071212@munnari.OZ.AU> <13076.1024074055@munnari.OZ.AU> <14818.1024077446@munnari.OZ.AU> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert Elz writes: > Date: Fri, 14 Jun 2002 10:26:44 -0700 (PDT) > From: Michael Thomas > Message-ID: <15626.10068.955615.342647@thomasm-u1.cisco.com> > > | But the real problem was renumbering. That > | still hasn't gone away. > > No, and that's why we need these things - so when renumbering happens, > our internal addresses (the ones I use to mount my filesystems from > the fileserver, etc, which stay in use for months or years between > reboots) don't alter. I guess I get off the merry-go-round here because I'm having a hard time imagining a deployment where it's OK to hose general internet connectivity, so long as other local services are kept up. Somehow I don't expect that the user population counting on their pr0n will be mollifed to find out that they can still download their PHB's powerpoints. YMMV. Mike -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 14 18:49:53 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5F1nqk7011950; Fri, 14 Jun 2002 18:49:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5F1nq6H011949; Fri, 14 Jun 2002 18:49:52 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5F1nnk7011942 for ; Fri, 14 Jun 2002 18:49:49 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA12390 for ; Fri, 14 Jun 2002 18:49:54 -0700 (PDT) Received: from drugs.dv.isc.org (drugs.dv.isc.org [130.155.191.236]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA28524 for ; Fri, 14 Jun 2002 18:49:52 -0700 (PDT) Received: from drugs.dv.isc.org (localhost.dv.isc.org [127.0.0.1]) by drugs.dv.isc.org (8.12.3/8.12.3) with ESMTP id g5F1nUm0033319; Sat, 15 Jun 2002 11:49:30 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200206150149.g5F1nUm0033319@drugs.dv.isc.org> To: Michael Thomas Cc: Robert Elz , Steve Blake , Thomas Narten , ipng@sunroof.eng.sun.com From: Mark.Andrews@isc.org Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-reply-to: Your message of "Fri, 14 Jun 2002 17:52:28 MST." <15626.36812.886269.733294@thomasm-u1.cisco.com> Date: Sat, 15 Jun 2002 11:49:30 +1000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Robert Elz writes: > > Date: Fri, 14 Jun 2002 10:26:44 -0700 (PDT) > > From: Michael Thomas > > Message-ID: <15626.10068.955615.342647@thomasm-u1.cisco.com> > > > > | But the real problem was renumbering. That > > | still hasn't gone away. > > > > No, and that's why we need these things - so when renumbering happens, > > our internal addresses (the ones I use to mount my filesystems from > > the fileserver, etc, which stay in use for months or years between > > reboots) don't alter. > > I guess I get off the merry-go-round here because > I'm having a hard time imagining a deployment where > it's OK to hose general internet connectivity, so > long as other local services are kept up. Somehow > I don't expect that the user population counting on > their pr0n will be mollifed to find out that they > can still download their PHB's powerpoints. > > YMMV. > > Mike Well you have a very poor imagination and understanding of typical connection patterns. 99.99% of external connections are short lived. Those that arn't short lived take a hit when the address renumbers. This is why certian providers can get away with *forcing* a address change every 24 hours today. However if you put a NFS server on a machine that has its address change every 24 hours then have a 10000 mounts off that server spread over 1000 machines and see what happens. NFS isn't the only protocol where long running connections are the norm *inside* a site. Things like SSH/X11/TELNET all tend to have much longer running sessions intra site. Mark > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@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 Jun 14 20:02:28 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5F32Sk7012071; Fri, 14 Jun 2002 20:02:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5F32S09012070; Fri, 14 Jun 2002 20:02:28 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5F32Nk7012063 for ; Fri, 14 Jun 2002 20:02:24 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA04599 for ; Fri, 14 Jun 2002 20:02:29 -0700 (PDT) Received: from mail6.nc.rr.com (fe6.southeast.rr.com [24.93.67.53]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA07042 for ; Fri, 14 Jun 2002 21:02:28 -0600 (MDT) Received: from mail pickup service by mail6.nc.rr.com with Microsoft SMTPSVC; Fri, 14 Jun 2002 23:01:38 -0400 Received: from ncmx01.mgw.rr.com ([24.93.67.251]) by mail6.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Mon, 10 Jun 2002 18:11:46 -0400 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ncmx01.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5AMBjtH018018 for ; Mon, 10 Jun 2002 18:11:46 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA25463; Mon, 10 Jun 2002 15:10:50 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA09664; Mon, 10 Jun 2002 15:10:45 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5AM8tk7008597; Mon, 10 Jun 2002 15:08:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5AM8srS008596; Mon, 10 Jun 2002 15:08:54 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5AM8ok7008589 for ; Mon, 10 Jun 2002 15:08:50 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA16543 for ; Mon, 10 Jun 2002 15:08:54 -0700 (PDT) Received: from esunmail ([129.147.58.122]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA10381 for ; Mon, 10 Jun 2002 16:08:54 -0600 (MDT) Received: from xpa-fe1 (esunmail-ge0 [129.147.58.121]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 0.3 (built May 13 2002)) with ESMTP id <0GXI00AERG6S07@edgemail1.Central.Sun.COM> for ipng@sunroof.eng.sun.com; Mon, 10 Jun 2002 16:08:53 -0600 (MDT) Received: from localhost ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 0.2 (built Apr 26 2002)) with ESMTPSA id <0GXI00MECG6RX0@mail.sun.net> for ipng@sunroof.eng.sun.com; Mon, 10 Jun 2002 16:08:52 -0600 (MDT) Date: Mon, 10 Jun 2002 15:08:50 -0700 From: Alain Durand Subject: Re: IPv6 Scoped Addresses and Routing Protocols In-reply-to: <4.3.2.7.2.20020607110536.02f48db0@mailhost.iprg.nokia.com> To: Bob Hinden Cc: ipng@sunroof.eng.sun.com Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.482) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Friday, June 7, 2002, at 03:56 PM, Bob Hinden wrote: > I think the w.g. has some choices to make regarding site-local > addresses. > > 1) Remove site-local from the IPv6. > > This would involve remove it from the IPv6 addressing documents and > find all other documents that mention them and update these. Some of > these may require significant modification if use site-local as a basic > part of their mechanisms. There will also be an impact to shipping > IPv6 implementations. This would have to be sorted out. A good > understanding of what different vendors plan here would be useful. > > 2) Keep site-local but limit it's scope of usage. > > This would be something like writing an applicability document that > defines it usage and for example restricts it use to sites not > connected to the Internet. Other usage would be for future study. > This would be consistent with most of the current specifications. It > would make completing the scoped address architecture document > simpler. There might be other specifications to update if they were > using site-local and didn't have any provision to move to global > addresses. A potential drawback is that the day those sites connect to the Internet, they will have to renumber. Until the renumbering story is significantly better, there will be temptations to use IPv6 NAT... > 3) Keep site-local and allow full usage > > This would mean fully specifying how to use site-local, documenting the > router and DNS issues, completing the scoped addressing architecture > document, perhaps enhancing IPv6 routing protocols to have more > knowledge of site-local addresses, etc. > > The working group has been going down 3) for some time now. I think > your email is a good start at seeing if should continue in this > direction or change course. This path is expensive, as seen in the current thread. - Alain. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 14 20:56:00 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5F3u0k7012699; Fri, 14 Jun 2002 20:56:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5F3u0QQ012698; Fri, 14 Jun 2002 20:56:00 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5F3tuk7012691 for ; Fri, 14 Jun 2002 20:55:56 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA11974 for ; Fri, 14 Jun 2002 20:56:01 -0700 (PDT) Received: from mail6.nc.rr.com (fe6.southeast.rr.com [24.93.67.53]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA00935 for ; Fri, 14 Jun 2002 21:56:01 -0600 (MDT) Received: from mail pickup service by mail6.nc.rr.com with Microsoft SMTPSVC; Fri, 14 Jun 2002 23:55:19 -0400 Received: from ncmx01.mgw.rr.com ([24.93.67.251]) by mail6.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Tue, 11 Jun 2002 19:22:41 -0400 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ncmx01.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5BNMebC002721 for ; Tue, 11 Jun 2002 19:22:40 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA18752; Tue, 11 Jun 2002 17:22:26 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA10636; Tue, 11 Jun 2002 16:22:20 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BNKbk7012178; Tue, 11 Jun 2002 16:20:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5BNKbnf012177; Tue, 11 Jun 2002 16:20:37 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BNKXk7012170 for ; Tue, 11 Jun 2002 16:20:33 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA10057 for ; Tue, 11 Jun 2002 16:20:36 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA26494; Tue, 11 Jun 2002 17:20:36 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5BNKZn27758; Tue, 11 Jun 2002 19:20:35 -0400 (EDT) Message-Id: <200206112320.g5BNKZn27758@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Erik Nordmark cc: Keith Moore , Thomas Narten , ipng@sunroof.eng.sun.com Subject: Re: IESG comments on draft-ietf-ipngwg-default-addr-select-06.txt In-reply-to: (Your message of "Wed, 12 Jun 2002 00:29:14 +0200.") Date: Tue, 11 Jun 2002 19:20:35 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > I respect the desire for temporary addresses (and AFAIK I was one of > > the first people to raise concerns about embedding tracable information > > in an IPv6 address) but I don't think it's a good idea to effectively > > change the API in a way that would break apps at this late date. > > The proposed text is trying to say that temporary addresses are preferable > but that there might be issues (such as applications having problems) > which consistitute a good enough reason to not follow the default. > Thus there is significant freedom for implementors to use their best > judgement based on their knowledge about the applications. > > Do you see a problem with this approach? absolutely. it encourages the API to deviate from one vendor to another, and from one installation to another. application coders thus can't count on predictable behavior from one platform to another - if they care at all what kind of address they want, they always have to do explicit binds of both source and destination addresses. worse, it introduces subtle failure modes where an application that works fine in one environment will fail in a different but apparently similar environment, even though the network seems to be working find otherwise. The idea that hosts, or administrators, can make reasonable address selections without input from the application is just wrong. The application, no the host, knows what kinds of addresses it needs - for some, temporary addresses will do just fine, but others needs stable, public, globally-scoped addresses. If this is not communicated explicitly then every application will have to do its own address selection in order to work reliably. Being able to alter the policy on a per-host basis is not a good solution, because it makes the platform less predictable (see above), and because multiple applications needing different policies will often run on the same host. I'd far rather see an approach like the following: 1. the API default is to use stable addresses 2. to request a temporary address, do it this way 3. applicatons that don't need stable addresses SHOULD request temporary addresses I've got some other problems with the document also - specifically the idea that link-local addresses are preferable to global addresses. Global addresses are always preferable because all applications can tolerate them. At most, LL addresses should be used only when there is no other alternative, because some applications need to treat them specially (this isn't as bad in v6 as in v4) But LL addresses should probably be used only when they are explicitly specified. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 14 22:39:23 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5F5dMk7013341; Fri, 14 Jun 2002 22:39:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5F5dMUd013340; Fri, 14 Jun 2002 22:39:22 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5F5dJk7013333 for ; Fri, 14 Jun 2002 22:39:19 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA23788 for ; Fri, 14 Jun 2002 22:39:24 -0700 (PDT) From: john.loughney@nokia.com Received: from mail6.nc.rr.com (fe6.southeast.rr.com [24.93.67.53]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA08261 for ; Fri, 14 Jun 2002 22:39:23 -0700 (PDT) Received: from mail pickup service by mail6.nc.rr.com with Microsoft SMTPSVC; Sat, 15 Jun 2002 01:37:56 -0400 Received: from ncmx01.mgw.rr.com ([24.93.67.251]) by mail6.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Mon, 10 Jun 2002 23:14:47 -0400 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ncmx01.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5B3EltH029996 for ; Mon, 10 Jun 2002 23:14:48 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA14021; Mon, 10 Jun 2002 20:13:51 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA00095; Mon, 10 Jun 2002 20:13:48 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5B3CFk7009208; Mon, 10 Jun 2002 20:12:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5B3CFJL009207; Mon, 10 Jun 2002 20:12:15 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5B3CAk7009200 for ; Mon, 10 Jun 2002 20:12:11 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA29817 for ; Mon, 10 Jun 2002 20:12:14 -0700 (PDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA25561 for ; Mon, 10 Jun 2002 20:12:13 -0700 (PDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g5B3Cdi11279 for ; Tue, 11 Jun 2002 06:12:39 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 11 Jun 2002 06:12:12 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 11 Jun 2002 06:12:12 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: finalizing cellular hosts document, version -03 now out Date: Tue, 11 Jun 2002 06:12:11 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC653C7@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: finalizing cellular hosts document, version -03 now out Thread-Index: AcIQrQtTyTua/pL/S/SlYMG3b1u4EgASLPxw To: , X-OriginalArrivalTime: 11 Jun 2002 03:12:12.0340 (UTC) FILETIME=[C7B5AF40:01C210F5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5B3CBk7009201 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, Actually, it was announced yesterday, so it can now be found here: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-cellular-host-03.txt John > -----Original Message----- > From: ext Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: 07 June, 2002 16:18 > To: ipng@sunroof.eng.sun.com > Subject: finalizing cellular hosts document, version -03 now out > > > > Version -03 of the cellular host document has now been published. > You can download it from > > http://www-nrc.nokia.com/sua/draft-ietf-ipv6-cellular-host-03.txt > > http://www-nrc.nokia.com/sua/draft-ietf-ipv6-cellular-host-03- > pa10.doc (with edits) > > Jari > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 15 00:19:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5F7Jik7014251; Sat, 15 Jun 2002 00:19:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5F7Ji7Z014250; Sat, 15 Jun 2002 00:19:44 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5F7Jdk7014243 for ; Sat, 15 Jun 2002 00:19:39 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA24389 for ; Sat, 15 Jun 2002 00:19:43 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA04385 for ; Sat, 15 Jun 2002 01:19:41 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id 1EC946A905; Sat, 15 Jun 2002 10:19:33 +0300 (EEST) Received: from ericsson.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 229A56A904; Sat, 15 Jun 2002 10:19:30 +0300 (EEST) Message-ID: <3D0AEAD3.2070506@ericsson.fi> Date: Sat, 15 Jun 2002 10:20:51 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Daniel Ng Cc: ipng@sunroof.eng.sun.com Subject: Re: Is IPv6 Tiny Fragment Attack possible? References: <20020615003327.49554.qmail@web21009.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-0.1 required=5.0 tests=SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Daniel Ng wrote: > RFC 3128 described the way to attack IPv4 network > using tiny fragment. Can the same thing happen to > IPv6 network? It would seem so, IPv6 fragment headers can also be forged to overlap each other. And I can't find anything in RFC 2460 to forbid this. The same cure as described in RFC 3128 would also apply. But filtering mechanisms must take in account the additional complication of the unfragmentable part i.e. hop-by-hop headers and such. Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jun 15 03:06:21 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5FA6Lk7014471; Sat, 15 Jun 2002 03:06:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5FA6LUf014470; Sat, 15 Jun 2002 03:06:21 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5FA6Ik7014463 for ; Sat, 15 Jun 2002 03:06:18 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA12387 for ; Sat, 15 Jun 2002 03:06:21 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA03324 for ; Sat, 15 Jun 2002 04:06:20 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g5FA6EV03555; Sat, 15 Jun 2002 13:06:15 +0300 Date: Sat, 15 Jun 2002 13:06:14 +0300 (EEST) From: Pekka Savola To: James Kempf cc: ipng@sunroof.eng.sun.com Subject: netaccess-threats-01 [Re: Securing Neighbor Discovery BOF] In-Reply-To: <009c01c212fe$afdf10e0$256015ac@T23KEMPF> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 13 Jun 2002, James Kempf wrote: > If you are interested in the potential threats, I'd suggest reading > draft-kempf-netaccess-threats-01.txt, which I've just resubmitted to the > Internet drafts editor (it had timed out in April), [...] It would have been nice to include the things I pointed out on the list (and Cc: to you) on 23rd Nov, and an issue pointed out privately to you and Erik on 19th Dec. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jun 15 08:02:57 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5FF2vk7015148; Sat, 15 Jun 2002 08:02:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5FF2uDl015147; Sat, 15 Jun 2002 08:02:56 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5FF2rk7015140 for ; Sat, 15 Jun 2002 08:02:53 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA09110 for ; Sat, 15 Jun 2002 08:02:57 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA01472 for ; Sat, 15 Jun 2002 09:04:50 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g5FF2pZ08389; Sat, 15 Jun 2002 18:02:52 +0300 Date: Sat, 15 Jun 2002 18:02:51 +0300 (EEST) From: Pekka Savola To: Michel Py cc: ipng@sunroof.eng.sun.com Subject: RE: back on track? [RE: Review of "Use of /127 Prefix LengthBetweenRouters Considered Harmful"] In-Reply-To: <2B81403386729140A3A899A8B39B046405E10A@server2000.arneill-py.sacramento.ca.us> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 14 Jun 2002, Michel Py wrote: > > Pekka Savola wrote: > > Note that link-locals and two /128's are two separate cases. > > "two /128's" means an implementation (like KAME) where you can do > > this without link-local addresses. > > Obviously the wording is a bit off. But I couldn't figure out how to > > say it without getting into static routes or whatnot. Any ideas? > > There needs to be something about the route install, as it is specific > to the implementation. Seriously, I don't think that two /128s would > ever be considered on a large network. I don't want to get to implementation specifics here.. > >> Link-local addresses are technically ok. Actually, I think that they > >> should be #2 in the list of options. In a large network, they are a > >> troubleshooting headache but in a small network there is nothing to > say > >> against them. > > > I've considered putting link-locals only in solutions 1), more or less > > > equal with /64. > > Makes sense also, as /64s and LLs are the only two options that do not > violate [addrarch]. That's mostly irrelevant though, as people who read the draft chose not to do as addrarch says anyway. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jun 15 08:11:19 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5FFBJk7015171; Sat, 15 Jun 2002 08:11:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5FFBJ5m015170; Sat, 15 Jun 2002 08:11:19 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5FFBGk7015163 for ; Sat, 15 Jun 2002 08:11:16 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA10092 for ; Sat, 15 Jun 2002 08:11:19 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA03421 for ; Sat, 15 Jun 2002 09:11:18 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g5FFB8V08465; Sat, 15 Jun 2002 18:11:08 +0300 Date: Sat, 15 Jun 2002 18:11:08 +0300 (EEST) From: Pekka Savola To: Jari Arkko cc: sommerfeld@east.sun.com, "Bound, Jim" , James Kempf , , Subject: Re: Securing Neighbor Discovery BOF In-Reply-To: <3D08F5E0.5010701@kolumbus.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 13 Jun 2002, Jari Arkko wrote: > Bill Sommerfeld wrote: > > > > Using AH/ESP to protect ND works fine once the SA's exist. > > > > However, there's a chicken & egg problem if you want to use IKE, and > > manually configuring N*(N-1) SA's across N machines on the link is not > > deployable. > > > Actually, it's worse. ND uses e.g. the solicited node multicast > address and the unicast address -- even if each node had a single > address. Since the RFC 2401 SAs are indexed through , > you'll need _multiple_ SAs between two machines, even in one > direction. So, your formula should be more like 2*M*N*(N-1) where > M is the number of addresses per node. I'm only grasping at straws here, but the logical approach at keying would be requiring manual keying with a router in the subnet, through which the rest of the keys would then be negotiated (somehow). Even that may be unscalable, but manually keying like 2-4 keys is may be problematic also, but that might be workable. There are some issues here (like when performing DAD for link-locals, and someone telling that address is already in use, verifying whether that is legit or not as one has not been able to contact the router yet) though. I haven't really thought about this enough, but I wonder if anyone else has tried to follow this path, and seen where it leads. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jun 15 18:17:52 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5G1Hpk7016369; Sat, 15 Jun 2002 18:17:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5G1HpTv016368; Sat, 15 Jun 2002 18:17:51 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5G1Hmk7016361 for ; Sat, 15 Jun 2002 18:17:48 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA10859 for ; Sat, 15 Jun 2002 18:17:52 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.96.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA03090 for ; Sat, 15 Jun 2002 19:19:46 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g5G1H4M15401; Sun, 16 Jun 2002 08:17:04 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g5G1Gh228610; Sun, 16 Jun 2002 08:16:44 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Alain Durand cc: Michael Thomas , Steve Blake , Thomas Narten , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-Reply-To: <3D0A39BC.69743C67@sun.com> References: <3D0A39BC.69743C67@sun.com> <15626.10068.955615.342647@thomasm-u1.cisco.com> <15626.6777.20313.190032@thomasm-u1.cisco.com> <200206141539.LAA11227@castillo.torrentnet.com> <11262.1024071212@munnari.OZ.AU> <13076.1024074055@munnari.OZ.AU> <14818.1024077446@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 16 Jun 2002 08:16:43 +0700 Message-ID: <28608.1024190203@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 14 Jun 2002 11:45:16 -0700 From: Alain Durand Message-ID: <3D0A39BC.69743C67@sun.com> | Site local addresses save your from renumbering if you change ISP. They don't avoid renumbering, but they save my internal network connections from the side-effects of he renumbering. | They don't help if you merge two networks. Subnet ID may collide. That's certainly true - but a merge like this can be, and needs to be planned, and can take as long as required to be executed. What's more I get to decide which internal bits of the two (or more) nets get renumbered, and which bits get to retain their old numbers. And of course, this only ever happens when the site owner chooses to have it happen (two organisations that merge can run their net as two separate IPv6 "sites" if they choose), unlike an external renumbering, which could be caused by your ISP altering its point of connection to the topology and having to renumber itself, and all its clients (and going to a different ISP doesn't save you in many cases, as you'd have to renumber to do that as well). 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 Jun 15 18:30:07 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5G1U6k7016412; Sat, 15 Jun 2002 18:30:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5G1U6EJ016411; Sat, 15 Jun 2002 18:30:06 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5G1U3k7016404 for ; Sat, 15 Jun 2002 18:30:03 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA11936 for ; Sat, 15 Jun 2002 18:30:07 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.96.5]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA22585 for ; Sat, 15 Jun 2002 18:30:06 -0700 (PDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g5G1TTM15680; Sun, 16 Jun 2002 08:29:29 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g5G1TA228634; Sun, 16 Jun 2002 08:29:11 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Margaret Wasserman cc: ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-Reply-To: <4.2.2.20020614141439.02548370@mail.windriver.com> References: <4.2.2.20020614141439.02548370@mail.windriver.com> <200206141557.g5EFvnZs020596@thunk.east.sun.com> <200206141557.g5EFvnZs020596@thunk.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 16 Jun 2002 08:29:10 +0700 Message-ID: <28632.1024190950@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 14 Jun 2002 14:23:26 -0400 From: Margaret Wasserman Message-ID: <4.2.2.20020614141439.02548370@mail.windriver.com> | Even if a multi-sited host has no routing protocols and a primitive | forwarding table (i.e. an ICMP redirect cache), there will still be | increased implementation complexity. The multi-sited host will | need to maintain multiple forwarding tables (one for the global | scope, and one for each attached site), will need to choose the | correct table as part of the next-hop lookup for outbound traffic, Yes, and it also needs to do that for link local addressing as well. That's the point I am trying to make - not that site locals are free, but that they're not all that expensive given that almost all the same mechanism is required for link locals anyway. The insides of the routing processes are the one major exception (as link locals never participate in those). | and will need to make sure that ICMP redirects are applied to the | correct table when received. I'm not sure it isn't possible in some obscure setups to get redirects for link locals, which would require just the same - but in any case, the interface (which is a more specific form of the scope) needs to be checked when processing redirects in all cases, to make sure that a redirect is coming from a router on the link that you're sending the packets to for the destination involved (the redirect will be from a link local addr, which should normally be the same one as the LL addr of the next hop for the route, and the LL addr has scope already, and is a subset of a site scope). | And what do we actually get for this added complexity? I think this has been answered enough. People are ignoring the benefit as no-one is actually being made to renumber their IPv6 sites currently. When Bob Fink made a suggestion on the 6bone list to change the 6bone addresses (the prefix length actually) I suggested also taking back all the current assigned prefixes, and reassigning them using the new rules, just so everyone (using 3ffe::/15 anyway) would actually experience renumbering their nets - from which we could perhaps learn something. But people are still pretending (hoping) that no-one is ever going to have to renumber their nets, and so don't want to actually test any of this part of IPv6. The desire to do away with SL is based upon much the same misconception. The costs are obvious to implementors, and the benefits are currently invisible. 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 Jun 17 01:00:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5H80Nk7020418; Mon, 17 Jun 2002 01:00:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5H80NV8020417; Mon, 17 Jun 2002 01:00:23 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5H80Jk7020405 for ; Mon, 17 Jun 2002 01:00:19 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA19591 for ; Mon, 17 Jun 2002 01:00:24 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA25956; Mon, 17 Jun 2002 01:00:23 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g5H80J932249; Mon, 17 Jun 2002 11:00:19 +0300 Date: Mon, 17 Jun 2002 11:00:19 +0300 (EEST) From: Pekka Savola To: Julien Laganier cc: Jari Arkko , , "Bound, Jim" , James Kempf , , Subject: Re: Securing Neighbor Discovery BOF In-Reply-To: <20020617074936.GA1059@klee> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 17 Jun 2002, Julien Laganier wrote: > It is logic. But how do you handle the case of public hospitality > networks, like those which could be found in airports, conference > rooms, etc., where there is no subscription (public wireless networks > are an example)? This problem is too generic (IMO) to be solved properly in its full form. If we want any work to be accomplished, we must be able to make some assumptions. One such (very valid IMO) assumption _could_ be that there is at least one router with fixed connectivity in such a network, and the user can (at least to some extent) trust it. > IMHO, manual keying only solves a few security threats in ND for a few > networks policies. It is not appropriate for public access networks, it > has a poor scalability, and so on. I idea was to perform manual keying with the router _only_, and automatic for the rest. This is a bit unscalable still, but not nearly as much as manually keying everything. How router is configured with a new node's manual keys in a subscription-less system is more of a challenge though. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 17 04:32:14 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5HBWEk7020809; Mon, 17 Jun 2002 04:32:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5HBWDeY020808; Mon, 17 Jun 2002 04:32:13 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5HBWAk7020801 for ; Mon, 17 Jun 2002 04:32:10 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA16323 for ; Mon, 17 Jun 2002 04:32:14 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA00029 for ; Mon, 17 Jun 2002 05:34:14 -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 HAA26531; Mon, 17 Jun 2002 07:31:33 -0400 (EDT) Message-Id: <200206171131.HAA26531@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-ipv6-dns-discovery-05.txt Date: Mon, 17 Jun 2002 07:31:33 -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 IP Version 6 Working Group Working Group of the IETF. Title : Well known site local unicast addresses for DNS resolver Author(s) : A. Durand, J. Hagino, D. Thaler Filename : draft-ietf-ipv6-dns-discovery-05.txt Pages : 12 Date : 14-Jun-02 This documents specifies a method for nodes to find a DNS resolver with minimum configuration in the network and without running a discovery protocol on the nodes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-dns-discovery-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipv6-dns-discovery-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-ipv6-dns-discovery-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: <20020614131226.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-dns-discovery-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-dns-discovery-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020614131226.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 Jun 17 05:44:03 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5HCi2k7020915; Mon, 17 Jun 2002 05:44:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5HCi2Uv020914; Mon, 17 Jun 2002 05:44:02 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5HChxk7020907 for ; Mon, 17 Jun 2002 05:43:59 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA25123 for ; Mon, 17 Jun 2002 05:44:04 -0700 (PDT) Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.211]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA26743 for ; Mon, 17 Jun 2002 06:46:04 -0600 (MDT) Received: from tarski.cs.uni-bonn.de (tarski.cs.uni-bonn.de [131.220.4.200]) by theory.cs.uni-bonn.de (8.9.1a/8.9.1) with ESMTP id OAA22135 for ; Mon, 17 Jun 2002 14:44:01 +0200 (MET DST) Received: (from ignatios@localhost) by tarski.cs.uni-bonn.de (8.9.1a/8.9.1) id OAA19012 for ipng@sunroof.eng.sun.com; Mon, 17 Jun 2002 14:43:19 +0200 (CEST) Date: Mon, 17 Jun 2002 14:43:19 +0200 From: Ignatios Souvatzis Cc: ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols Message-ID: <20020617144319.C18900@tarski.cs.uni-bonn.de> References: <20020606173628.3E1DE7B4B@berkshire.research.att.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="+g7M9IMkV8truYOl" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020606173628.3E1DE7B4B@berkshire.research.att.com>; from smb@research.att.com on Thu, Jun 06, 2002 at 01:36:28PM -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --+g7M9IMkV8truYOl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jun 06, 2002 at 01:36:28PM -0400, Steven M. Bellovin wrote: >=20 > My strong preference would be to drop site-local addresses completely. = =20 > I think they're an administrative and technical nightmare. What will people use instead of site-local addresses to build auto-configur= ation=20 of structured networks? I'm thinking of approaches like IPv6 Stateless Address Autoconfiguration for Hierarchical Mobile Ad Hoc Net= works When you're done detecting internal structure, and assigning internal addre= sses, just advertise a global prefix and get external connectivity, just like link-loc= al addresses are used for flat network auto-configuration, and router advertizements are= used later to add a prefix that is externally routed. Without site-locals you'd need to use a global address prefix to do so - bu= t need the network first to learn of it. Regards, -is --+g7M9IMkV8truYOl Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: 2.6.i iQEVAgUBPQ3ZZDCn4om+4LhpAQEyXggAkGXhOm2tawTV+46THSWgqFgInWk56nXV OjMYeuyz7e5iyYW8+vum48rcD/EJvbJR/fJfNMU73npIyry6Eca4lDBPcQhYZ+JS DEIATMz5RF+piKqLSUgB5IDHZul/jgoQljQKV+rY2Kxu+0tG2XLGlrUEOxBtuOVj uctaMwimJlzDGVsTDAflL1k8T9VPWJB8R5PbJA32yEb2c13W49qTjGwYumBf5g5r XYWIyau0q39Pe++z9fw+gzjlNWH+FEjuFjbkg+vrZbczIDj+VF/WmjAZ2v1wcaqS mrqi0c7sXCnaxDrQ6nGZAOHkhm+SZNRwaoS+69jhTl9AG98QFu+zmg== =1SSm -----END PGP SIGNATURE----- --+g7M9IMkV8truYOl-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 17 07:19:11 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5HEJBk7021348; Mon, 17 Jun 2002 07:19:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5HEJAVQ021344; Mon, 17 Jun 2002 07:19:10 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5HEJ4k7021321 for ; Mon, 17 Jun 2002 07:19:04 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA13407 for ; Mon, 17 Jun 2002 07:19:08 -0700 (PDT) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA22264 for ; Mon, 17 Jun 2002 08:19:07 -0600 (MDT) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 7A0433954; Mon, 17 Jun 2002 10:19:07 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 17 Jun 2002 10:19:07 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols Date: Mon, 17 Jun 2002 10:19:06 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B022D2C1F@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Fwd: IPv6 Scoped Addresses and Routing Protocols Thread-Index: AcITL5fpnL9eRfWpSU2TGjzEZQR5hAC09FNQ From: "Bound, Jim" To: "Randy Bush" Cc: "Bill Fenner" , X-OriginalArrivalTime: 17 Jun 2002 14:19:07.0332 (UTC) FILETIME=[F0FB6840:01C21609] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5HEJ5k7021324 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I will have to buy Dave a beer for this then. Plus I would buy him a beer anyway as he is a good guy. /jim > -----Original Message----- > From: Randy Bush [mailto:randy@research.att.com] > Sent: Thursday, June 13, 2002 3:58 PM > To: Bound, Jim > Cc: Bill Fenner; ipng@sunroof.eng.sun.com > Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols > > > > Read the latest architectural Internet doc by Bush et al. > > from the credit where due department: dave meyer was the > principal author > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Jun 17 07:19:29 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5HEJSk7021396; Mon, 17 Jun 2002 07:19:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5HEJRAU021395; Mon, 17 Jun 2002 07:19:27 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5HEJ7k7021333 for ; Mon, 17 Jun 2002 07:19:07 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA13403 for ; Mon, 17 Jun 2002 07:19:07 -0700 (PDT) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA07194 for ; Mon, 17 Jun 2002 08:19:06 -0600 (MDT) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id F08BC6AB4; Mon, 17 Jun 2002 10:19:05 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 17 Jun 2002 10:19:05 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: IESG comments on draft-ietf-ipngwg-default-addr-select-06.txt Date: Mon, 17 Jun 2002 10:19:05 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B022D2C1D@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IESG comments on draft-ietf-ipngwg-default-addr-select-06.txt Thread-Index: AcITKnirRxhqCZCiSM6RViECbKoz5wC2J/1A From: "Bound, Jim" To: "Keith Moore" , "Tony Hain" Cc: "Alberto Escudero-Pascual" , "Erik Nordmark" , "Thomas Narten" , X-OriginalArrivalTime: 17 Jun 2002 14:19:05.0914 (UTC) FILETIME=[F02309A0:01C21609] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5HEJ8k7021334 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Kieth, IMO that should be a new API doc. /jim > -----Original Message----- > From: Keith Moore [mailto:moore@cs.utk.edu] > Sent: Thursday, June 13, 2002 6:34 PM > To: Tony Hain > Cc: Keith Moore; Alberto Escudero-Pascual; Bound, Jim; Erik Nordmark; > Thomas Narten; ipng@sunroof.eng.sun.com > Subject: Re: IESG comments on > draft-ietf-ipngwg-default-addr-select-06.txt > > > > get off the soap box... IPv6 requires a new API, so there > is no valid > > argument that we are not changing it. If you want to argue that we > > should minimize the changes, I would agree. > > believe it or not there are already lots of progams using the > v6 API... > many of which were very slight modifications to v4 programs. > > I'm happy that IESG has decided not to insist on temp addresses as > the default and has backed the idea that there should be an API > to request them. Now, who's going to define the API extension? > > Keith > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 17 07:19:34 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5HEJYk7021399; Mon, 17 Jun 2002 07:19:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5HEJXBG021398; Mon, 17 Jun 2002 07:19:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5HEJ9k7021340 for ; Mon, 17 Jun 2002 07:19:09 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA11278 for ; Mon, 17 Jun 2002 07:19:13 -0700 (PDT) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA27396 for ; Mon, 17 Jun 2002 08:19:12 -0600 (MDT) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id E73BD6976; Mon, 17 Jun 2002 10:19:11 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 17 Jun 2002 10:19:11 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols Date: Mon, 17 Jun 2002 10:19:11 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B022D2C21@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Fwd: IPv6 Scoped Addresses and Routing Protocols Thread-Index: AcITOboFwKQqOEDtQNK+R32lQKNPPgCygHGw From: "Bound, Jim" To: "Randy Bush" , "Tony Hain" Cc: "Randall Stewart" , "Steven M. Bellovin" , X-OriginalArrivalTime: 17 Jun 2002 14:19:11.0598 (UTC) FILETIME=[F38658E0:01C21609] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5HEJAk7021341 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Also no one said get rid of 1918 that is abursd and impossible IMO. But if we don't have to propogate this to v6 is the issue. The logic that we should keep SLs because of 1918 is completely bogus. /jim > -----Original Message----- > From: Randy Bush [mailto:randy@research.att.com] > Sent: Thursday, June 13, 2002 8:24 PM > To: Tony Hain > Cc: Bound, Jim; Randall Stewart; Steven M. Bellovin; > ipng@sunroof.eng.sun.com > Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols > > > > It is time to get off this thread and back to real work. > Those who want > > SL removed should get 1918 moved to historic first > > complete red herring. > > a socially better case of this herring would be to cure world > hunger first. > > we may not like 1918, but that does not mean we should > reproduce it to show > our dislike. > > randy > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 17 07:19:25 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5HEJOk7021393; Mon, 17 Jun 2002 07:19:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5HEJNHC021392; Mon, 17 Jun 2002 07:19:23 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5HEJ4k7021319 for ; Mon, 17 Jun 2002 07:19:04 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA13405 for ; Mon, 17 Jun 2002 07:19:07 -0700 (PDT) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA27364 for ; Mon, 17 Jun 2002 08:19:07 -0600 (MDT) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id D4A7A45D6; Mon, 17 Jun 2002 10:19:06 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 17 Jun 2002 10:19:06 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: IESG comments on draft-ietf-ipngwg-default-addr-select-06.txt Date: Mon, 17 Jun 2002 10:19:06 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B022D2C1E@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IESG comments on draft-ietf-ipngwg-default-addr-select-06.txt Thread-Index: AcITK4/W9LwSTJUNQC+rwtS1NTPpgwC168bA From: "Bound, Jim" To: , "Tony Hain" Cc: X-OriginalArrivalTime: 17 Jun 2002 14:19:06.0789 (UTC) FILETIME=[F0A88D50:01C21609] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5HEJ4k7021320 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Itojun, I am glad to here I am not the only one who has been embarassed. This as I said to Keith should be new API doc if it is in fact needed. /jim > -----Original Message----- > From: itojun@iijlab.net [mailto:itojun@iijlab.net] > Sent: Thursday, June 13, 2002 6:35 PM > To: Tony Hain > Cc: ipng@sunroof.eng.sun.com > Subject: Re: IESG comments on > draft-ietf-ipngwg-default-addr-select-06.txt > > > >get off the soap box... IPv6 requires a new API, so there is no valid > >argument that we are not changing it. If you want to argue that we > >should minimize the changes, I would agree. > > no more changes, *please*. we have spent more than > reasonable amount > of years to settle down to RFC2553/bis. and people are > now using it. > > I would quote words from sendmail people - "first > gethostbyname2, > then gethostbyname3, then getipnodebyname, then you want us to > switch to getaddrinfo? how can we know that it will be > the final one?" > I was so embarrassed when i heard this. > > 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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 17 07:19:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5HEJdk7021405; Mon, 17 Jun 2002 07:19:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5HEJcCY021402; Mon, 17 Jun 2002 07:19:38 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5HEJBk7021351 for ; Mon, 17 Jun 2002 07:19:12 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA11290 for ; Mon, 17 Jun 2002 07:19:15 -0700 (PDT) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA10890 for ; Mon, 17 Jun 2002 07:19:15 -0700 (PDT) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 90820698E; Mon, 17 Jun 2002 10:19:14 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 17 Jun 2002 10:19:14 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols Date: Mon, 17 Jun 2002 10:19:13 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B022D2C24@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Fwd: IPv6 Scoped Addresses and Routing Protocols Thread-Index: AcITdQ17lgTJh5pNRX28za33o1Hf6ACj3d8A From: "Bound, Jim" To: "Robert Elz" Cc: "JINMEI Tatuya / ????" , "Margaret Wasserman" , "Brian Haberman" , X-OriginalArrivalTime: 17 Jun 2002 14:19:14.0332 (UTC) FILETIME=[F52785C0:01C21609] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5HEJCk7021353 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > -----Original Message----- > From: Robert Elz [mailto:kre@munnari.OZ.AU] > Sent: Friday, June 14, 2002 3:13 AM > To: Bound, Jim > Cc: JINMEI Tatuya / ????; Margaret Wasserman; Brian Haberman; > ipng@sunroof.eng.sun.com > Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols > > > Date: Thu, 13 Jun 2002 08:59:58 -0400 > From: "Bound, Jim" > Message-ID: > <9C422444DE99BC46B3AD3C6EAFC9711B020B8A13@tayexc13.americas.cp > qcorp.net> > > | Exactly. The entire IPv6 code base would be reduced in > size and more > | importantly the decision constructs and data struct > lookups which is a > | big win. > > Can you actually justify that, or is this just more nonsense? Sure. But I don't respond well to the work nonsense or your tone. So I won't to you. Don't start a fight with your attitude with me but if you want to lets take it offline. Be civil Robert. > > Remember that as long as link locals stay, and as long as their are > apps that use them (doesn't BGP peering use LL's these days?) then all > of the system support for scoped addresses has to remain, > including the > data structs, API's, ... Link-Locals do not have the same properties to implement as site-locals. > > What you would gain by removing them is the change from testing > fe80::/9 into testing fe80::/10 when deciding if the address you > have is one that also needs a scope. Beyond that it is essentially > all the same if scopes are involved - are the scopes for source & > destination the same, etc - regardless of whether it is fe80::/10 or > fec0::/10 that the address happens to be. Site causes logic beyond the link and causes more errors for TCP, SCTP, and Anycast. BGP peers using LLs is fine that is a link. /jim > > So, just where is this saving? > > kre > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 17 07:19:40 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5HEJdk7021404; Mon, 17 Jun 2002 07:19:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5HEJcfc021401; Mon, 17 Jun 2002 07:19:38 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5HEJBk7021349 for ; Mon, 17 Jun 2002 07:19:11 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA11284 for ; Mon, 17 Jun 2002 07:19:14 -0700 (PDT) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA10876 for ; Mon, 17 Jun 2002 07:19:14 -0700 (PDT) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 906E6A93; Mon, 17 Jun 2002 10:19:13 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 17 Jun 2002 10:19:13 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols Date: Mon, 17 Jun 2002 10:19:12 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B022D2C23@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Fwd: IPv6 Scoped Addresses and Routing Protocols Thread-Index: AcITdF+kJxCQpRB8S1GBEGHSLaijdwCj6xLQ From: "Bound, Jim" To: "Robert Elz" Cc: , "Michel Py" , "Bob Hinden" , "Steven M. Bellovin" , X-OriginalArrivalTime: 17 Jun 2002 14:19:13.0461 (UTC) FILETIME=[F4A29E50:01C21609] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5HEJBk7021352 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > -----Original Message----- > From: Robert Elz [mailto:kre@munnari.OZ.AU] > Sent: Friday, June 14, 2002 3:06 AM > To: Bound, Jim > Cc: sommerfeld@east.sun.com; Michel Py; Bob Hinden; Steven M. > Bellovin; > ipng@sunroof.eng.sun.com > Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols > > > Date: Thu, 13 Jun 2002 08:47:49 -0400 > From: "Bound, Jim" > Message-ID: > <9C422444DE99BC46B3AD3C6EAFC9711B020B8A0C@tayexc13.americas.cp > > We lost the possibility of end to end because we didn't have enough > addresses for everyone. As long as we have enough addresses that > everyone can have one, then end to end remains. I am saying remove any chance of private addresses unless users want to invent their own. Or do what we did with Net 10 and not have them as part of the IPv6 scoping architecture which I believe is a technical flaw for deployment and not needed. /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 Jun 17 07:19:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5HEJik7021415; Mon, 17 Jun 2002 07:19:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5HEJhC4021412; Mon, 17 Jun 2002 07:19:43 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5HEJGk7021379 for ; Mon, 17 Jun 2002 07:19:16 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA08207 for ; Mon, 17 Jun 2002 07:19:19 -0700 (PDT) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA07286 for ; Mon, 17 Jun 2002 08:19:18 -0600 (MDT) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id E239E45D6; Mon, 17 Jun 2002 10:19:17 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 17 Jun 2002 10:19:17 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols Date: Mon, 17 Jun 2002 10:19:17 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B022D2C27@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Fwd: IPv6 Scoped Addresses and Routing Protocols Thread-Index: AcIUD1zkTWW9bQrvTkaE8oYjUoAKdQB91Krg From: "Bound, Jim" To: , "Michael Thomas" Cc: "Robert Elz" , "Steve Blake" , "Thomas Narten" , X-OriginalArrivalTime: 17 Jun 2002 14:19:17.0836 (UTC) FILETIME=[F73E30C0:01C21609] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5HEJHk7021383 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mark, That was not quite fair to Michael. Because I use a global address does not mean I can't do what you say even with a renumbering event. CPE - provides new prefix to edge cpe router. Edge CPE router begats router renumbering link router - advertises new prefix and deprecates old address the NFS server gracefully moves to new address. users will have time to reconnect. /jim > -----Original Message----- > From: Mark.Andrews@isc.org [mailto:Mark.Andrews@isc.org] > Sent: Friday, June 14, 2002 9:50 PM > To: Michael Thomas > Cc: Robert Elz; Steve Blake; Thomas Narten; ipng@sunroof.eng.sun.com > Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols > > > > > Robert Elz writes: > > > Date: Fri, 14 Jun 2002 10:26:44 -0700 (PDT) > > > From: Michael Thomas > > > Message-ID: <15626.10068.955615.342647@thomasm-u1.cisco.com> > > > > > > | But the real problem was renumbering. That > > > | still hasn't gone away. > > > > > > No, and that's why we need these things - so when > renumbering happens, > > > our internal addresses (the ones I use to mount my > filesystems from > > > the fileserver, etc, which stay in use for months or > years between > > > reboots) don't alter. > > > > I guess I get off the merry-go-round here because > > I'm having a hard time imagining a deployment where > > it's OK to hose general internet connectivity, so > > long as other local services are kept up. Somehow > > I don't expect that the user population counting on > > their pr0n will be mollifed to find out that they > > can still download their PHB's powerpoints. > > > > YMMV. > > > > Mike > > Well you have a very poor imagination and understanding of > typical connection patterns. 99.99% of external connections > are short lived. Those that arn't short lived take a hit > when the address renumbers. This is why certian providers > can get away with *forcing* a address change every 24 hours > today. > > However if you put a NFS server on a machine that has its > address change every 24 hours then have a 10000 mounts off > that server spread over 1000 machines and see what happens. > > NFS isn't the only protocol where long running connections > are the norm *inside* a site. Things like SSH/X11/TELNET > all tend to have much longer running sessions intra site. > > Mark > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > -- > Mark Andrews, Internet Software Consortium > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 17 07:19:42 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5HEJfk7021407; Mon, 17 Jun 2002 07:19:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5HEJdkK021403; Mon, 17 Jun 2002 07:19:39 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5HEJDk7021357 for ; Mon, 17 Jun 2002 07:19:13 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA11272 for ; Mon, 17 Jun 2002 07:19:12 -0700 (PDT) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA24025 for ; Mon, 17 Jun 2002 07:19:11 -0700 (PDT) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 24A144791; Mon, 17 Jun 2002 10:19:11 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 17 Jun 2002 10:19:10 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols Date: Mon, 17 Jun 2002 10:19:10 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B022D2C20@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Fwd: IPv6 Scoped Addresses and Routing Protocols Thread-Index: AcITOPOtY2M+plzeT6KsFSTIK30DTQCyqenQ From: "Bound, Jim" To: "Tony Hain" , "Randall Stewart" , "Steven M. Bellovin" Cc: X-OriginalArrivalTime: 17 Jun 2002 14:19:10.0945 (UTC) FILETIME=[F322B510:01C21609] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5HEJDk7021361 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I don't agree. Steve brought up a valid question and it is coming up again I agree. Many are not comfortable with them. I say we continue to hear the issues. /jim > -----Original Message----- > From: Tony Hain [mailto:alh-ietf@tndh.net] > Sent: Thursday, June 13, 2002 8:17 PM > To: Bound, Jim; Randall Stewart; Steven M. Bellovin > Cc: ipng@sunroof.eng.sun.com > Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols > > > It is time to get off this thread and back to real work. > Those who want > SL removed should get 1918 moved to historic first, get all products > using that off the market, then come back and raise the > issue. Since we > know that won't happen, the constructive thing to do is for those that > don't think they can support SL to leave it out of their > implementation, > while those that have figured out how to use it as a > differentiator can > leave it in. Yes that might cause interoperability problems, > but only in > the case where a site was running with SL as its only prefix. When a > node doesn't support SL, it will be hard pressed to register an SL > address in whatever name resolution system is being used, and if a > product can't respond correctly to an SL address, an administrator > shouldn't register it. Every node should be able to work when only a > global address is returned, so in any realistic scenario, where is the > interoperability problem? > > On the topic of documenting when and how SL interacts with > DNS or SIP or > your favorite name-to-address-mapper, yes more work is needed. I would > argue this belongs in the DNS WGs, but if their approach is > to ignore it > because it is different from current operation, then the IPv6 > community > will have to corner some DNS experts long enough to learn the > issues. In > any case it doesn't make sense to waste time arguing that 'XYZ > configuration will not work', when no sane network manager would > configure a network that way. When particular configurations > don't work, > pointing that out in documentation makes sense, but demanding to throw > out the mechanism because an obscure corner case fails is not good > engineering. > > One issue that I am surprised has not been raised here is the > case where > a node has administrative restrictions on which prefixes it can learn > from an RA (specifically so that it will only work on the > home network), > and that list includes SL. If that node appeared on a foreign net, it > would ignore the globals, but would happly accept any SL and > may be wide > open. One could argue that it shouldn't happen, but consider the case > where enterprise-A uses 802.11, and a laptop with it built-in (and no > administrative rights to the user to turn it off) were to show up at > enterprise-B. The sys-admin may have thought the machine was > reasonably > protected by the filter list on the RA, but by using SL left that node > wide open when it was away from home. This is not an argument that SL > shoudl be dropped, just that it is not appropriate in all contexts. > > One case where it does make sense is in consumer electronics that are > intended for local in-home use, and have no reason for global > addressibility (say a light switch). Those who want SL removed are > arguing that the average consumer will be required to manage > a firewall > to keep the global address of the light switch from being reached > externally. Many of them can't even get self-configuring NATs to work > with help from a support desk, so forget any hope that they will do > something more complex. While having the light switch accessed by a > control unit could be done with LL, does it make sense to > have a control > unit connect to every possible link technology in a home, or does it > make more sense to use SL from a stand-alone control unit and have a > routing device attach to the different segments? We typically define > control and routing jobs as separate functions, so why would someone > expect that they now magically show up in the same box? The router > should be a cheap box with nothing but connectors, while the control > unit has a fancy UI and may be replicated in multiple locations. > > As I scan through this thread, it started by questioning the lack of > documentation about how SL should work in a particular context, but > quickly degraded into an attack on change. The IETF is about managing > the consistent change that has been taking place in networking, so > standing up and saying 'take this out because it requires us to change > the way we have done it forever' is counter to our role. Documenting > that a mechanims works in configuration A, not at all in configuration > B, and we haven't figured out configuraion C, is what we need to do > here, so lets get on with it. > > Tony > > > > Jim Bound wrote: > > As all know I wanted these dreaded site-locals gone since we > > invented them in IPv6. > > This has been discussed before if we can revisit this again > > that is a very good thing. > > Steve and Randy are 100% correct. > > > > I would also add they break lots of stuff. > > > > /jim > > > > > -----Original Message----- > > > From: Randall Stewart [mailto:randall@stewart.chicago.il.us] > > > Sent: Thursday, June 06, 2002 2:46 PM > > > To: Steven M. Bellovin > > > Cc: ipng@sunroof.eng.sun.com > > > Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols > > > > > > > > > Steve: > > > > > > Having implemented SCTP and IPv6 together I could not > agree with you > > > more. > > > I know in our work on scoping of addresses it got very very > > tricky on > > > attempting to figure out which set of addresses to tell the other > > > SCTP endpoint about to avoid black hole conditions. So in the end > > > the only way you could handle it is if the destination address > > > of your INIT packet (consider it a SYN) was TO a site-local then > > > you could include your site-locals... This means that if the user > > > sent the INIT to the global address then the peer NEVER > > gets informed > > > of site locals.... maybe something not desired but unavoidable... > > > > > > > > > Now with the new addition of site-scoping even this will > break since > > > one must all of a sudden be cognizant of what site the peer > > is on and > > > only send a sub-set of the site-local addresses (gak!!). > > > > > > In all of this I have tried to figure out what use these > site locals > > > are? > > > > > > If I have a global address why would I ever want to use a > > site-local? > > > If no global-addresses are available and I am not attached to the > > > public inter-net I could possibly see using a > site-local.. maybe but > > > I would think this is more the 'dentists' office scenario where in > > > link-local will suffice... If the 'dentist' wants to talk to the > > > insurance company I doubt that it would be in the > > 'dentist's' site... > > > so he would need a connection to the global address > space... and the > > > problem goes away.... > > > > > > Only in a large company would I see a site-local being > > applied.. but > > > in such a company why not just use a global address? What does it > > > buy me to have this extra address? I already know my > > assigned address > > > space... I can have my company border routers prevent spoofing of > > > my address into my network... so I can use the source being the > > > global address that is assigned to me to "know" that I am in the > > > same company...if thats what I want... > > > > > > I may be able to see (maybe) that a large company wants to NOT > > > connect to the global address space... so here site-local MIGHT be > > > something I could use... but adding in scoped site-locals I > > just can't > > > see a use for... It just causes all sorts of fun problems. > > > > > > I would much rather see the company that is NOT going to want to > > > connect to the global address space just have a way to get some > > > global address space.... I realize with the current number scheme > > > this is not possible so maybe a site-local does make sense in > > > this one strange instance... but in this case the company > > > does not need > > > to worry about global mixed with site-local :> > > > > > > So maybe site-local (if allowed) should only be valid if NO global > > > address is defined :> > > > > > > R > > > > > > "Steven M. Bellovin" wrote: > > > > > > > > In message > > > <4.2.2.20020605134805.0245def0@mail.windriver.com>, > Margaret Wasserm > > > > an writes: > > > > > > > > > >I sent the attached message to the routing area discussion > > > list. I thought th > > > > >at people on > > > > >the IPv6 list might be interested in this discussion, so I > > > will forward a mess > > > > >age containing > > > > >the responses after this one. I suppose I just should > > > have cc:ed the IPv6 gro > > > > >up in the > > > > >first place... > > > > > > > > > > > > > My strong preference would be to drop site-local addresses > > > completely. > > > > I think they're an administrative and technical nightmare. > > > > > > > > Margaret has pointed out that our routing protocols > don't support > > > > site-local addresses. The only alternative suggestion I've > > > seen thus > > > > far is to run multiple instances of, say, OSPF on all > > > routers within a > > > > site. But how are these distinguished from each other? > > > OSPF runs with > > > > an IP protocol number, not a port number, so we can't > > have multiple > > > > instances that way. And RFC 2740's specification of > the necessary > > > > multicast addresses notes that they're all link-local. > > > Still, there's > > > > apparently running code; I look forward to seeing the details. > > > > > > > > I'm very concerned about DNS entries. When should a DNS > > > server -- or a > > > > caching resolver -- return a site-local address? (If the > > DNS never > > > > returns such things, they're useless.) One suggestion > > I've heard is > > > > two-faced DNS servers -- only return site-local > information if the > > > > querier is within the same site. Apart from the fact > > that I have no > > > > idea how that determination can be made -- surely no one > > > will suggest > > > > putting site-local addresses into NS records -- RFC 2182 > > > (aka BCP 0016) > > > > specifically warns against putting all secondary servers > > for a zone > > > > within a site: > > > > > > > > Consequently, placing all servers at the local site, > > > while easy to > > > > arrange, and easy to manage, is not a good policy. > > > Should a single > > > > link fail, or there be a site, or perhaps even > > building, or room, > > > > power failure, such a configuration can lead to all > > servers being > > > > disconnected from the Internet. > > > > > > > > Secondary servers must be placed at both topologically and > > > > geographically dispersed locations on the Internet, to > > > minimise the > > > > likelihood of a single failure disabling all of them. > > > > > > > > Etc. > > > > > > > > There will also be a lot of unnecessary pain in DNS > maintenance as > > > > "sites" are split or merged. v6 is designed to support > > > easy renumbering > > > > of global addresses, but those are designed to reflect topology. > > > > Site-local addresses do not, which increases the probability of > > > > address space collision during a merger. > > > > > > > > Philosophically, I think that the problem is that a > > "site" is a new > > > > (and deliberately poorly defined) concept. The DNS is > > > designed to work > > > > with administrative boundaries, while routing and > > addressing reflect > > > > topology. We now have a new concept that is neither > > > administrative nor > > > > topological, but one that must be supported by > administrative and > > > > topological mechanisms. > > > > > > > > Finally -- and perhaps least important -- I'm not sure > > what problem > > > > they solve. I can understand site-local multicast, since (most) > > > > inter-site traffic traverses links that are not inherently > > > > multicast-capable. There is thus considerable extra > > > expense. But why > > > > do I need site-local unicast addresses? > > > > > > > > --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 Mon Jun 17 07:19:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5HEJik7021414; Mon, 17 Jun 2002 07:19:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5HEJhgZ021411; Mon, 17 Jun 2002 07:19:43 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5HEJDk7021359 for ; Mon, 17 Jun 2002 07:19:13 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA13423 for ; Mon, 17 Jun 2002 07:19:13 -0700 (PDT) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA10850 for ; Mon, 17 Jun 2002 07:19:13 -0700 (PDT) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 97D353954; Mon, 17 Jun 2002 10:19:12 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 17 Jun 2002 10:19:12 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols Date: Mon, 17 Jun 2002 10:19:12 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B022D2C22@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Fwd: IPv6 Scoped Addresses and Routing Protocols Thread-Index: AcITPZ13G4NA+N5URxiFJ33XFTkXSQCxkmMg From: "Bound, Jim" To: "Tony Hain" , "Randy Bush" Cc: "Randall Stewart" , "Steven M. Bellovin" , X-OriginalArrivalTime: 17 Jun 2002 14:19:12.0473 (UTC) FILETIME=[F40BDC90:01C21609] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5HEJDk7021363 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk the markets for v6 and v4 are different not the same. /jim > -----Original Message----- > From: Tony Hain [mailto:alh-ietf@tndh.net] > Sent: Thursday, June 13, 2002 8:51 PM > To: Randy Bush > Cc: Bound, Jim; Randall Stewart; Steven M. Bellovin; > ipng@sunroof.eng.sun.com > Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols > > > Randy Bush wrote: > > > It is time to get off this thread and back to real work. > > Those who want > > > SL removed should get 1918 moved to historic first > > > > complete red herring. > > They are designed to serve the same purposes. Clearly the market has > found several uses for 1918, so claiming any of those (except > expanding > the address space by reuse) are void in an IPv6 world is a > bit academic. > > > > > a socially better case of this herring would be to cure world > > hunger first. > > > > we may not like 1918, but that does not mean we should > > reproduce it to show > > our dislike. > > There are uses for 1918, and life would have been good without NAT. We > need to keep the real problem child in focus and not blame > 1918 for the > transgressions of NAT. > > Service providers and network managers clearly know the boundaries of > their routing complex, and may find that using SL is a reasonable > mechanism for SNMP and other management traffic, much as they use 1918 > now. The issues raised on the thread have mostly focused on > cases where > the site boundary is not clear. When there is no clear > boundary then SL > shouldn't be used, just as you can't use 1918 in those cases now. > > Tony > > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 17 07:19:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5HEJhk7021413; Mon, 17 Jun 2002 07:19:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5HEJhm2021409; Mon, 17 Jun 2002 07:19:43 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5HEJEk7021367 for ; Mon, 17 Jun 2002 07:19:14 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA08200 for ; Mon, 17 Jun 2002 07:19:17 -0700 (PDT) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA24047 for ; Mon, 17 Jun 2002 07:19:17 -0700 (PDT) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id ADCD48D1D; Mon, 17 Jun 2002 10:19:16 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 17 Jun 2002 10:19:16 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols Date: Mon, 17 Jun 2002 10:19:15 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B022D2C26@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Fwd: IPv6 Scoped Addresses and Routing Protocols Thread-Index: AcITdtiN7uTbNWoCR/COEGUzXd2r9wCjn2/A From: "Bound, Jim" To: "Robert Elz" Cc: "Randy Bush" , "Francis Dupont" , "Steven M. Bellovin" , X-OriginalArrivalTime: 17 Jun 2002 14:19:16.0086 (UTC) FILETIME=[F6332960:01C21609] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5HEJFk7021370 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > | Also this is not the case for link-local. The reason is > that the links > | are hardwired in the implementation and treating them as > zones works for > | links. But sites are "virtual". > > More FUD... > > Sites are only "virtual" until someone decides which links > belong to the > site, and which do not, and configures things that way. Sites can include links but of themselves do not exist they are virtual. > > They're no more virtual than an ATM based link level, where > someone has > to decide which ATM PVCs and SVCs perhaps are part of the > link, and which > are not, and/or any modern switch where someone has to decide > which ports > belong to which VLAN. Those are virtual to and I don't believe in these networks either. So I am being consistent. > > Once configured, any and all of these things are just as real as each > other. If you add the logic to the routing table, src addr select, etc. the virtual can be used yes. but many of us don't believe its worth it. that adds code too so just put that in your calculator as we talk. /jim > > 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 Jun 17 08:15:51 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5HFFpk7021782; Mon, 17 Jun 2002 08:15:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5HFFpc7021781; Mon, 17 Jun 2002 08:15:51 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5HFFlk7021774 for ; Mon, 17 Jun 2002 08:15:47 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA25805 for ; Mon, 17 Jun 2002 08:15:26 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA05787 for ; Mon, 17 Jun 2002 09:15:25 -0600 (MDT) Received: from kenawang ([147.11.233.28]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id IAA09183; Mon, 17 Jun 2002 08:13:47 -0700 (PDT) Message-Id: <4.2.2.20020617110250.023b5e60@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 17 Jun 2002 11:09:28 -0400 To: Robert Elz From: Margaret Wasserman Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols Cc: ipng@sunroof.eng.sun.com In-Reply-To: <28632.1024190950@munnari.OZ.AU> References: <4.2.2.20020614141439.02548370@mail.windriver.com> <4.2.2.20020614141439.02548370@mail.windriver.com> <200206141557.g5EFvnZs020596@thunk.east.sun.com> <200206141557.g5EFvnZs020596@thunk.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 09:29 PM 6/15/02 , Robert Elz wrote: > Date: Fri, 14 Jun 2002 14:23:26 -0400 > From: Margaret Wasserman > Message-ID: <4.2.2.20020614141439.02548370@mail.windriver.com> > > | Even if a multi-sited host has no routing protocols and a primitive > | forwarding table (i.e. an ICMP redirect cache), there will still be > | increased implementation complexity. The multi-sited host will > | need to maintain multiple forwarding tables (one for the global > | scope, and one for each attached site), will need to choose the > | correct table as part of the next-hop lookup for outbound traffic, > >Yes, and it also needs to do that for link local addressing as well. This does not match my understanding. A link-local address is incomplete, as a destination for traffic, without including the zone ID. That zone ID unambiguously identifies which interface should be used to send the traffic, so there is no need to perform any sort of routing look-up for link local traffic -- just send it out the indicated interface. >I'm not sure it isn't possible in some obscure setups to get redirects >for link locals, which would require just the same - but in any case, I don't think that its ever valid to send a redirect for a link-local address. I'm not quite sure, though, what you are supposed to do if you receive one. Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 17 14:06:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5HL6tk7022877; Mon, 17 Jun 2002 14:06:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5HL6thn022874; Mon, 17 Jun 2002 14:06:55 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5HL2rkb022690 for ; Mon, 17 Jun 2002 14:06:45 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA26417 for ; Mon, 17 Jun 2002 09:44:35 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.96.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA15209 for ; Mon, 17 Jun 2002 10:46:36 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g5HGhuM09258; Mon, 17 Jun 2002 23:43:56 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g5HGhRf03811; Mon, 17 Jun 2002 23:43:28 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: "Bound, Jim" cc: "JINMEI Tatuya / ????" , "Margaret Wasserman" , "Brian Haberman" , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B022D2C24@tayexc13.americas.cpqcorp.net> References: <9C422444DE99BC46B3AD3C6EAFC9711B022D2C24@tayexc13.americas.cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 17 Jun 2002 23:43:27 +0700 Message-ID: <3809.1024332207@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 17 Jun 2002 10:19:13 -0400 From: "Bound, Jim" Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B022D2C24@tayexc13.americas.cpqcorp.net> | Link-Locals do not have the same properties to implement as site-locals. They have almost the same properties (the internals of routing protocols excepted, as LL's don't go there - obviously, as they're not routed anywhere), Apart from inside routing, a user of SL's has to specify the scope, just as does a user of LL's, and the forwarding engine has to make sure that the packet is sent only to a link in the appropriate scope, in both cases. Routers (routing protocols omitted for now) need to check that the scope of the outgoing interface is the same as that of the incoming one, for both link locals and site locals - for link locals that can be reduced to checking that the interface is the same (or I thought it could, but apparently we have multi-interface links now, which makes LL's even closer to SL's in this area) but it doesn't have to be (and probably can't if these multi-interface link things exist, whatever they really are). | Site causes logic beyond the link and causes more errors for TCP, SCTP, | and Anycast. What errors? Please Jim - don't just claim something, if there's a problem, actually give the details, then it will be possible for others to either see your point, or show you where you're mistaken. But "causes more errors" is just the same as "this program is broken" without any more detail - it is a totally useless comment. 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 Jun 17 14:33:07 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5HLX7k7023367; Mon, 17 Jun 2002 14:33:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5HLX7GU023366; Mon, 17 Jun 2002 14:33:07 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5HLX2kF023352 for ; Mon, 17 Jun 2002 14:33:04 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA06887 for ; Mon, 17 Jun 2002 12:33:05 -0700 (PDT) Received: from mail6.microsoft.com (mail6.microsoft.com [131.107.3.126]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA10635 for ; Mon, 17 Jun 2002 13:33:05 -0600 (MDT) Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 17 Jun 2002 12:33:04 -0700 Received: from 157.54.8.23 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 17 Jun 2002 12:33:04 -0700 Received: from red-msg-06.redmond.corp.microsoft.com ([157.54.12.71]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 17 Jun 2002 12:33:04 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols Date: Mon, 17 Jun 2002 12:33:04 -0700 Message-ID: <7695E2F6903F7A41961F8CF888D87EA804BC4D7A@red-msg-06.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Fwd: IPv6 Scoped Addresses and Routing Protocols Thread-Index: AcIWEoBzf+tRmUFCSbimI5602ZzURAAIbTyA From: "Richard Draves" To: "Margaret Wasserman" , "Robert Elz" Cc: X-OriginalArrivalTime: 17 Jun 2002 19:33:04.0397 (UTC) FILETIME=[CCBF6BD0:01C21635] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5HLX4k7023360 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >I'm not sure it isn't possible in some obscure setups to get > redirects > >for link locals, which would require just the same - but in any case, > > I don't think that its ever valid to send a redirect for a link-local > address. I'm not quite sure, though, what you are supposed > to do if you > receive one. If a router receives a packet sent to a link-local destination address, and that link-local address is not assigned to the router's interface, then wouldn't the router try to forward the packet to the destination address? Because the destination address is link-local, this would mean forward the packet back out the interface that received the packet. This in turn would cause the router to generate a redirect. 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 Jun 17 14:52:12 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5HLqBk7023691; Mon, 17 Jun 2002 14:52:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5HLqB45023689; Mon, 17 Jun 2002 14:52:11 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5HLq1kL023654 for ; Mon, 17 Jun 2002 14:52:04 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA21731 for ; Mon, 17 Jun 2002 10:29:19 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.96.5]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA07385 for ; Mon, 17 Jun 2002 10:29:18 -0700 (PDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g5HHSgM14478; Tue, 18 Jun 2002 00:28:42 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g5HHSGf04267; Tue, 18 Jun 2002 00:28:16 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Margaret Wasserman cc: ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-Reply-To: <4.2.2.20020617110250.023b5e60@mail.windriver.com> References: <4.2.2.20020617110250.023b5e60@mail.windriver.com> <4.2.2.20020614141439.02548370@mail.windriver.com> <4.2.2.20020614141439.02548370@mail.windriver.com> <200206141557.g5EFvnZs020596@thunk.east.sun.com> <200206141557.g5EFvnZs020596@thunk.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 18 Jun 2002 00:28:16 +0700 Message-ID: <4265.1024334896@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 17 Jun 2002 11:09:28 -0400 From: Margaret Wasserman Message-ID: <4.2.2.20020617110250.023b5e60@mail.windriver.com> | A link-local address is incomplete, as a destination for traffic, without | including the zone ID. As is a site local, yes. | That zone ID unambiguously identifies which | interface should be used to send the traffic, Does it, always? I would have agreed, but I have seen comments from others about links to which there are multiple interfaces connected, so I'm not sure this is actually correct. That is, assuming what I understood from those messages is anything like correct. There's a draft on that stuff, isn't there? Actually, "was" seems to be more correct, it looks to have expired a couple of weeks ago. 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 Jun 17 14:52:11 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5HLqAk7023688; Mon, 17 Jun 2002 14:52:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5HLqAoe023687; Mon, 17 Jun 2002 14:52:10 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5HLq1kJ023654 for ; Mon, 17 Jun 2002 14:52:04 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA19929 for ; Mon, 17 Jun 2002 10:25:24 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.96.5]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA15600 for ; Mon, 17 Jun 2002 11:25:22 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g5HHOiM13926; Tue, 18 Jun 2002 00:24:45 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g5HHOJf04255; Tue, 18 Jun 2002 00:24:19 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Arthur Kepner cc: Margaret Wasserman , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 18 Jun 2002 00:24:19 +0700 Message-ID: <4253.1024334659@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 17 Jun 2002 09:03:08 -0700 From: Arthur Kepner Message-ID: | - The ICMP Target Address is either a link-local address (when | redirected to a router) That parenthesized restriction is the interesting case, when a redirect redirects to a host, rather than a router. 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 Jun 17 14:52:02 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5HLq2k7023658; Mon, 17 Jun 2002 14:52:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5HLq1sZ023655; Mon, 17 Jun 2002 14:52:01 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5HLpvk7023632 for ; Mon, 17 Jun 2002 14:51:57 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA26113 for ; Mon, 17 Jun 2002 14:49:16 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA29894 for ; Mon, 17 Jun 2002 15:49:15 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g5HLlfa06977; Tue, 18 Jun 2002 00:47:41 +0300 Date: Tue, 18 Jun 2002 00:47:41 +0300 (EEST) From: Pekka Savola To: Richard Draves cc: Margaret Wasserman , Robert Elz , Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols In-Reply-To: <7695E2F6903F7A41961F8CF888D87EA804BC4D7A@red-msg-06.redmond.corp.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 17 Jun 2002, Richard Draves wrote: > > >I'm not sure it isn't possible in some obscure setups to get > > redirects > > >for link locals, which would require just the same - but in any case, > > > > I don't think that its ever valid to send a redirect for a link-local > > address. I'm not quite sure, though, what you are supposed > > to do if you > > receive one. > > If a router receives a packet sent to a link-local destination address, > and that link-local address is not assigned to the router's interface, > then wouldn't the router try to forward the packet to the destination > address? Because the destination address is link-local, this would mean > forward the packet back out the interface that received the packet. This > in turn would cause the router to generate a redirect. I'm not sure why router would ever receive such a link-local packet, as Neighbor Discovery always tries to find where to deliver the packet on-link, not send it to the router? A few special cases are possible, like a point-to-point link (consider 3GPP) or if a does something equivalent to IPv4 static ARP mapping, pointing an address towards the router's L2 address. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 17 16:09:17 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5HN9Hk7024425; Mon, 17 Jun 2002 16:09:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5HN9GaL024424; Mon, 17 Jun 2002 16:09:16 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5HN9Fk7024417 for ; Mon, 17 Jun 2002 16:09:15 -0700 (PDT) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g5HN99oR007034 for ; Mon, 17 Jun 2002 16:09:09 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g5HN98mE007033 for ipng@sunroof.eng.sun.com; Mon, 17 Jun 2002 16:09:08 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5H7nrk7020369 for ; Mon, 17 Jun 2002 00:49:53 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA16074 for ; Mon, 17 Jun 2002 00:49:57 -0700 (PDT) Received: from smtp.laposte.net (nposte04.axime.com [160.92.113.39]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA00869 for ; Mon, 17 Jun 2002 01:49:57 -0600 (MDT) Received: from klee (194.2.198.227) by smtp.laposte.net (5.5.044) id 3CF4B31300168D3F; Mon, 17 Jun 2002 09:49:37 +0200 Received: from jlaganie by klee with local (Exim 3.35 #1 (Debian)) id 17JrGb-0000HH-00; Mon, 17 Jun 2002 09:49:37 +0200 Date: Mon, 17 Jun 2002 09:49:36 +0200 To: Pekka Savola Cc: Jari Arkko , sommerfeld@east.sun.com, "Bound, Jim" , James Kempf , ipng@sunroof.eng.sun.com, ietf-send@standards.ericsson.net Subject: Re: Securing Neighbor Discovery BOF Message-ID: <20020617074936.GA1059@klee> References: <3D08F5E0.5010701@kolumbus.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i From: Julien Laganier Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sat, Jun 15, 2002 at 06:11:08PM +0300, Pekka Savola wrote: > I'm only grasping at straws here, but the logical approach at keying would > be requiring manual keying with a router in the subnet, through which the > rest of the keys would then be negotiated (somehow). > > Even that may be unscalable, but manually keying like 2-4 keys is may be > problematic also, but that might be workable. > > There are some issues here (like when performing DAD for link-locals, and > someone telling that address is already in use, verifying whether that is > legit or not as one has not been able to contact the router yet) though. > > I haven't really thought about this enough, but I wonder if anyone else > has tried to follow this path, and seen where it leads. It is logic. But how do you handle the case of public hospitality networks, like those which could be found in airports, conference rooms, etc., where there is no subscription (public wireless networks are an example)? By publishing the secret keys to authorized members... You cannot know them since the network is public. Even in the case of a private networks, there is the problem of a rogue node which could compromise the keys. IMHO, manual keying only solves a few security threats in ND for a few networks policies. It is not appropriate for public access networks, it has a poor scalability, and so on. Folks? -- Julien LAGANIER, PhD Student RESAM Laboratory (UCB / INRIA RESO) Ecole Normale Superieure de Lyon -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 17 16:10:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5HNA7k7024441; Mon, 17 Jun 2002 16:10:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5HNA7qe024440; Mon, 17 Jun 2002 16:10:07 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5HNA5k7024433 for ; Mon, 17 Jun 2002 16:10:05 -0700 (PDT) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g5HN9xoR007042 for ; Mon, 17 Jun 2002 16:09:59 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g5HN9x5N007041 for ipng@sunroof.eng.sun.com; Mon, 17 Jun 2002 16:09:59 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5HG3Rk7022276 for ; Mon, 17 Jun 2002 09:03:27 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA14761 for ; Mon, 17 Jun 2002 09:03:31 -0700 (PDT) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA19806 for ; Mon, 17 Jun 2002 10:05:33 -0600 (MDT) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g5HE32il005950; Mon, 17 Jun 2002 07:03:02 -0700 Received: from neteng.engr.sgi.com (neteng.engr.sgi.com [192.26.80.10]) by cthulhu.engr.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id JAA60422; Mon, 17 Jun 2002 09:03:08 -0700 (PDT) Date: Mon, 17 Jun 2002 09:03:08 -0700 From: Arthur Kepner To: Margaret Wasserman cc: Robert Elz , Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-Reply-To: <4.2.2.20020617110250.023b5e60@mail.windriver.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 17 Jun 2002, Margaret Wasserman wrote: > .... > I don't think that its ever valid to send a redirect for a link-local > address. I'm not quite sure, though, what you are supposed to do if you > receive one. > >From 2461, Section 8.1: 8.1. Validation of Redirect Messages A host MUST silently discard any received Redirect message that does not satisfy all of the following validity checks: .... - The ICMP Target Address is either a link-local address (when redirected to a router) or the same as the ICMP Destination Address (when redirected to the on-link destination). -- Arthur -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 17 16:21:44 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5HNLik7024576; Mon, 17 Jun 2002 16:21:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5HNLi9j024575; Mon, 17 Jun 2002 16:21:44 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5HNLfk7024568 for ; Mon, 17 Jun 2002 16:21:41 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA29299 for ; Mon, 17 Jun 2002 16:21:46 -0700 (PDT) Received: from mail-blue.research.att.com (H-135-207-30-102.research.att.com [135.207.30.102]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA20436 for ; Mon, 17 Jun 2002 16:21:46 -0700 (PDT) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id A43FA4CE9F; Mon, 17 Jun 2002 19:21:45 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id TAA29742; Mon, 17 Jun 2002 19:21:43 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id QAA04394; Mon, 17 Jun 2002 16:21:44 -0700 (PDT) Message-Id: <200206172321.QAA04394@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: kre@munnari.OZ.AU Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols Cc: ipng@sunroof.eng.sun.com References: <3D0A39BC.69743C67@sun.com> <15626.10068.955615.342647@thomasm-u1.cisco.com> <15626.6777.20313.190032@thomasm-u1.cisco.com> <200206141539.LAA11227@castillo.torrentnet.com> <11262.1024071212@munnari.OZ.AU> <13076.1024074055@munnari.OZ.AU> <14818.1024077446@munnari.OZ.AU> <28608.1024190203@munnari.OZ.AU> Date: Mon, 17 Jun 2002 16:21:44 -0700 Versions: dmail (solaris) 2.4c/makemail 2.9d Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >And of course, [merging two sites with possibly-overlapping subnet >numbers] only ever happens when the site owner chooses to >have it happen (two organisations that merge can run their net as >two separate IPv6 "sites" if they choose) Running the net as two separate sites has its own costs, though, by limiting the permitted topology. (See my discussion with Dave Thaler hundreds of messages ago in this thread). Bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 18 04:25:55 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5IBPsk7028408; Tue, 18 Jun 2002 04:25:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5IBPsLO028407; Tue, 18 Jun 2002 04:25:54 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5IBPpk7028400 for ; Tue, 18 Jun 2002 04:25:51 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA25980 for ; Tue, 18 Jun 2002 04:25:56 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.96.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA21346 for ; Tue, 18 Jun 2002 05:27:52 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g5IBOqM27626; Tue, 18 Jun 2002 18:24:58 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g5IBONf07254; Tue, 18 Jun 2002 18:24:27 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Bill Fenner cc: ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-Reply-To: <200206172321.QAA04394@windsor.research.att.com> References: <200206172321.QAA04394@windsor.research.att.com> <3D0A39BC.69743C67@sun.com> <15626.10068.955615.342647@thomasm-u1.cisco.com> <15626.6777.20313.190032@thomasm-u1.cisco.com> <200206141539.LAA11227@castillo.torrentnet.com> <11262.1024071212@munnari.OZ.AU> <13076.1024074055@munnari.OZ.AU> <14818.1024077446@munnari.OZ.AU> <28608.1024190203@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 18 Jun 2002 18:24:23 +0700 Message-ID: <7252.1024399463@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 17 Jun 2002 16:21:44 -0700 From: Bill Fenner Message-ID: <200206172321.QAA04394@windsor.research.att.com> | Running the net as two separate sites has its own costs, though, | by limiting the permitted topology. (See my discussion with Dave | Thaler hundreds of messages ago in this thread). Yes, absolutely. Nothing is going to avoid *all* renumbering in every possible situation, what site locals avoid is renumbering from the outside affecting operations internally (if they're used properly). To me, that's a big win. 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 Jun 18 06:56:42 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5IDugk7029188; Tue, 18 Jun 2002 06:56:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5IDugAT029187; Tue, 18 Jun 2002 06:56:42 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5IDubk7029180 for ; Tue, 18 Jun 2002 06:56:37 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA15727 for ; Tue, 18 Jun 2002 06:56:41 -0700 (PDT) Received: from astro.cs.utk.edu ([160.36.58.43]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA00096 for ; Tue, 18 Jun 2002 06:56:39 -0700 (PDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5IDoMY05084; Tue, 18 Jun 2002 09:50:22 -0400 (EDT) Message-Id: <200206181350.g5IDoMY05084@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Robert Elz cc: Bill Fenner , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-reply-to: (Your message of "Tue, 18 Jun 2002 18:24:23 +0700.") <7252.1024399463@munnari.OZ.AU> Date: Tue, 18 Jun 2002 09:50:22 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Yes, absolutely. Nothing is going to avoid *all* renumbering in > every possible situation, what site locals avoid is renumbering from > the outside affecting operations internally (if they're used properly). > > To me, that's a big win. perhaps, but the "if they're used properly" comes with a cost - applications have to know how to deal with them. the other thing is that 'proper' handling of of SLs and LLs is different enough from proper handling of normal addresses that sane apps will only use them as a last resort, and the limitations of those kinds of addresses for normal opreations will not be discovered until the global addresses fail to work. the bottom line is that renumbering from the outside will still affect operations internally - just in ways that are more subtle and harder to diagnose. (as if the loss of external connectivity isn't enough of an effect) so I think SLs are a fairly limited win, and they come at a fairly high cost. I also think that external renumbering events are going to have to be carefully managed by humans, with plenty of advance notice, for the forseeable future. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 18 07:23:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5IENnk7029325; Tue, 18 Jun 2002 07:23:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5IENnqo029324; Tue, 18 Jun 2002 07:23:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5IENjk7029317 for ; Tue, 18 Jun 2002 07:23:45 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA22739 for ; Tue, 18 Jun 2002 07:23:50 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.96.5]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA25665 for ; Tue, 18 Jun 2002 08:23:48 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g5IEN4M00130; Tue, 18 Jun 2002 21:23:04 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g5IEMbf08478; Tue, 18 Jun 2002 21:22:37 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Keith Moore cc: Bill Fenner , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-Reply-To: <200206181350.g5IDoMY05084@astro.cs.utk.edu> References: <200206181350.g5IDoMY05084@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 18 Jun 2002 21:22:37 +0700 Message-ID: <8476.1024410157@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 18 Jun 2002 09:50:22 -0400 From: Keith Moore Message-ID: <200206181350.g5IDoMY05084@astro.cs.utk.edu> | perhaps, but the "if they're used properly" comes with a cost - | applications have to know how to deal with them. Some applications. But those are also the applications that need to know more about addresses than they currently usually do anyway. If you remember from some earlier message, I'd only use SL addresses in those apps that expressly say they want to use them, for others, the vast majority of apps probably, globals work fine. | the other thing is that 'proper' handling of of SLs and LLs is different | enough from proper handling of normal addresses that sane apps will only | use them as a last resort, But that makes no sense. If you're able to use them at all, the logic has to be there in the code, and in that case, it makes sense to use them whenever they work (SL's anyway, LL's usually only when their use is specifically requested). So ... | and the limitations of those kinds of addresses | for normal opreations will not be discovered until the global addresses | fail to work. I don't think that's true. I'd also never regard a SL address as a fall back from a global that doesn't work - my model at least requires the global address to work (in the sense of reach the recipient and get a reply back) before I'd consider using the SL instead. Rather, SL's are for those apps that know they will (or are likely to) be using the address for a long time, and which consequently want an address that will more probably be stable for longer. | the bottom line is that renumbering from the outside | will still affect operations internally - just in ways that are more | subtle and harder to diagnose. I disagree - but this seems to largely come down to the theory of when and how SL's will get used. Certainly external renumbering has the potential to disrupt internal stuff - anything that is using a global address will be affected. But if I know that I want to guard against that possibility (as an app writer of the kind of apps that suffer most - filesystem, mounts, tunnels, ... probably remote logins) then if I get to use SLs I can avoid the problems for me - one less issue for the net people to have to deal with. | (as if the loss of external connectivity isn't enough of an effect) External connectivity isn't likely to be lost (or shouldn't be), just external connections that have lasted longer than the overlap period of old & new addresses will break when the old finally stop working. Often, that will be no noticeable effect at all, as there simply tend not to be that many long term wide area connections (tunnels are probably the most noticeable kind of application that may be affected). | so I think SLs are a fairly limited win, and they come at a fairly | high cost. I'm still looking for the high cost, I can't really see it. Certainly not zero cost, but I don't really think that the cost is all that great. | I also think that external renumbering events are going to have to be | carefully managed by humans, with plenty of advance notice, for the | forseeable future. Depends who is foreseeing ... I certainly agree that it is going to be a while before things can be less disruptive. But that's no excuse for deliberately creating the environment where more disruption is required. Note that for many sites these days (IPv4) renumbering is essentially an invisible operation - almost nothing is affected at all. That is, one adjusts the NAT box, and fixes the external DNS, and aside from any connections that were open and get broken (which a good NAT box, if such a thing exists, could probably avoid by keeping the old state even after recreating it becomes invalid) no-one inside the net can even tell that the renumbering happened. One of the aims of IPv6 was to be at least as good as IPv4 at everything (and better wherever it is possible). If SL's get sacrificed, just how does IPv6 ever return to even par (or better) ? If the answer if NATv6, then I think we should all just quit and leave all of this to someone with better judgment. 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 Jun 18 07:31:42 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5IEVgk7029372; Tue, 18 Jun 2002 07:31:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5IEVgKJ029371; Tue, 18 Jun 2002 07:31:42 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5IEVck7029364 for ; Tue, 18 Jun 2002 07:31:39 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA28591 for ; Tue, 18 Jun 2002 07:31:43 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA00289 for ; Tue, 18 Jun 2002 08:31:42 -0600 (MDT) Message-ID: <012301c216d4$a19ddaf0$0f6015ac@T23KEMPF> From: "James Kempf" To: , References: <3D08F5E0.5010701@kolumbus.fi> <20020617074936.GA1059@klee> Subject: Re: Securing Neighbor Discovery BOF Date: Tue, 18 Jun 2002 07:30:00 -0700 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 A possibility is for the ISP to distribute a public/private key pair when the host gets its IP address, then use DH to generate the session key. Or one could distribute a shared session key through secure (via TLS over EAP) L2 authentication when the host enters the foreign network. We proposed something similar for ABK using id crypto, and it would work a little more cleanly there because the IP address acts as the public key, but id crypto suffers from being a new and therefore not well understood algorithm. jak ----- Original Message ----- From: "Julien Laganier" To: "Pekka Savola" Cc: "Jari Arkko" ; ; "Bound, Jim" ; "James Kempf" ; ; Sent: Monday, June 17, 2002 12:49 AM Subject: Re: Securing Neighbor Discovery BOF > On Sat, Jun 15, 2002 at 06:11:08PM +0300, Pekka Savola wrote: > > I'm only grasping at straws here, but the logical approach at keying would > > be requiring manual keying with a router in the subnet, through which the > > rest of the keys would then be negotiated (somehow). > > > > Even that may be unscalable, but manually keying like 2-4 keys is may be > > problematic also, but that might be workable. > > > > There are some issues here (like when performing DAD for link-locals, and > > someone telling that address is already in use, verifying whether that is > > legit or not as one has not been able to contact the router yet) though. > > > > I haven't really thought about this enough, but I wonder if anyone else > > has tried to follow this path, and seen where it leads. > > It is logic. But how do you handle the case of public hospitality > networks, like those which could be found in airports, conference > rooms, etc., where there is no subscription (public wireless networks > are an example)? > > By publishing the secret keys to authorized members... You cannot know > them since the network is public. > > Even in the case of a private networks, there is the problem of a rogue > node which could compromise the keys. > > IMHO, manual keying only solves a few security threats in ND for a few > networks policies. It is not appropriate for public access networks, it > has a poor scalability, and so on. > > Folks? > -- > Julien LAGANIER, PhD Student > RESAM Laboratory (UCB / INRIA RESO) > Ecole Normale Superieure de Lyon > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Jun 18 07:53:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5IEr7k7029489; Tue, 18 Jun 2002 07:53:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5IEr78R029488; Tue, 18 Jun 2002 07:53:07 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5IEr3k7029481 for ; Tue, 18 Jun 2002 07:53:03 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA22518 for ; Tue, 18 Jun 2002 07:53:08 -0700 (PDT) Received: from astro.cs.utk.edu ([160.36.58.43]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA12633 for ; Tue, 18 Jun 2002 08:53:07 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5IEkrY12563; Tue, 18 Jun 2002 10:46:53 -0400 (EDT) Message-Id: <200206181446.g5IEkrY12563@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Robert Elz cc: Keith Moore , Bill Fenner , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-reply-to: (Your message of "Tue, 18 Jun 2002 21:22:37 +0700.") <8476.1024410157@munnari.OZ.AU> Date: Tue, 18 Jun 2002 10:46:53 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk okay, I now understand your use case for SLs, though I still think it would probably be better to solve that problem by assigning a unique, non-publically-routable prefix to each site that asks for one. > I disagree - but this seems to largely come down to the theory of when > and how SL's will get used. Certainly external renumbering has the > potential to disrupt internal stuff - anything that is using a global > address will be affected. But if I know that I want to guard against > that possibility (as an app writer of the kind of apps that suffer > most - filesystem, mounts, tunnels, ... probably remote logins) then > if I get to use SLs I can avoid the problems for me - one less issue for > the net people to have to deal with. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 18 08:15:05 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5IFF4k7029629; Tue, 18 Jun 2002 08:15:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5IFF4b2029628; Tue, 18 Jun 2002 08:15:04 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5IFF1k7029621 for ; Tue, 18 Jun 2002 08:15:01 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA29426 for ; Tue, 18 Jun 2002 08:15:06 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.96.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA16972 for ; Tue, 18 Jun 2002 09:17:06 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g5IFDcM06686; Tue, 18 Jun 2002 22:13:38 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g5IFDCf08788; Tue, 18 Jun 2002 22:13:12 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Keith Moore cc: Bill Fenner , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-Reply-To: <200206181446.g5IEkrY12563@astro.cs.utk.edu> References: <200206181446.g5IEkrY12563@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 18 Jun 2002 22:13:12 +0700 Message-ID: <8786.1024413192@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 18 Jun 2002 10:46:53 -0400 From: Keith Moore Message-ID: <200206181446.g5IEkrY12563@astro.cs.utk.edu> | okay, I now understand your use case for SLs, though I still think it | would probably be better to solve that problem by assigning a unique, | non-publically-routable prefix to each site that asks for one. Yes, that would be an alternative - and is much the same as SL's with site ID's embedded. Aside from the much touted (but really silly) objection of "who would assign them" this method has other problems. Either way (SL's with ID's, or non-routable globals) gets rid of the scoping problem. No need to pass scopes around any more - but they're still needed for LL's. They also make routing easier. The global addr model though makes apps lifes more difficult, in that it is then no longer immediately obvious which addresses are stable, and which are not. Given two addresses, which should I use if I want a stable connection (assuming I somehow know that both work) ? Globals also lack the "you can't possibly route that, everyone and his dog owns the same address" argument that immediately shoots down anyone trying to make the thing routable, and stable. None of this is easy - there is no easy answer (or not that has been proposed so far). 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 Jun 18 08:35:13 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5IFZCk7029726; Tue, 18 Jun 2002 08:35:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5IFZCVh029725; Tue, 18 Jun 2002 08:35:12 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5IFZ9k7029718 for ; Tue, 18 Jun 2002 08:35:09 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA18675 for ; Tue, 18 Jun 2002 08:35:14 -0700 (PDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA04165 for ; Tue, 18 Jun 2002 08:35:14 -0700 (PDT) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g5IFR9uF019280; Tue, 18 Jun 2002 08:27:09 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ABW83759; Tue, 18 Jun 2002 08:24:37 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA14090; Tue, 18 Jun 2002 08:27:29 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15631.20833.505187.593662@thomasm-u1.cisco.com> Date: Tue, 18 Jun 2002 08:27:29 -0700 (PDT) To: Robert Elz Cc: Keith Moore , Bill Fenner , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-Reply-To: <8786.1024413192@munnari.OZ.AU> References: <200206181446.g5IEkrY12563@astro.cs.utk.edu> <8786.1024413192@munnari.OZ.AU> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert Elz writes: > The global addr model though makes apps lifes more difficult, in that > it is then no longer immediately obvious which addresses are stable, > and which are not. Given two addresses, which should I use if I want > a stable connection (assuming I somehow know that both work) ? This is just the tip of the iceberg of what hosts don't know about addresses. The problem is that it is definitionally *unknowable* to the host since only thing that has that knowledge of those sort of topology goodies are routers, perhaps transported by routing protocols. This, to my mind, is the very basic reason why SL addresses are a generally Bad Idea. Requiring hosts to have knowledge of network topology is a bug, not a feature. Mike -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 18 08:46:51 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5IFkpk7029824; Tue, 18 Jun 2002 08:46:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5IFkppM029823; Tue, 18 Jun 2002 08:46:51 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5IFklk7029816 for ; Tue, 18 Jun 2002 08:46:47 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA12004 for ; Tue, 18 Jun 2002 08:46:52 -0700 (PDT) Received: from astro.cs.utk.edu ([160.36.58.43]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA11929 for ; Tue, 18 Jun 2002 08:46:52 -0700 (PDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5IFecY19885; Tue, 18 Jun 2002 11:40:38 -0400 (EDT) Message-Id: <200206181540.g5IFecY19885@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Robert Elz cc: Keith Moore , Bill Fenner , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-reply-to: (Your message of "Tue, 18 Jun 2002 22:13:12 +0700.") <8786.1024413192@munnari.OZ.AU> Date: Tue, 18 Jun 2002 11:40:38 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > | okay, I now understand your use case for SLs, though I still think it > | would probably be better to solve that problem by assigning a unique, > | non-publically-routable prefix to each site that asks for one. > > Yes, that would be an alternative - and is much the same as > SL's with site ID's embedded. right. but you don't have to deal with that extra frob. > Aside from the much touted (but really silly) objection of "who would > assign them" this method has other problems. > > Either way (SL's with ID's, or non-routable globals) gets rid of the > scoping problem. No need to pass scopes around any more - but they're > still needed for LL's. perhaps, but LLs really shouldn't be used except for some very odd cases - I see LL as mostly a way to avoid having to reinvent the same functionality differently for each L2 network. > The global addr model though makes apps lifes more difficult, in that > it is then no longer immediately obvious which addresses are stable, > and which are not. Given two addresses, which should I use if I want > a stable connection (assuming I somehow know that both work) ? I don't think stability is the issue. global addrs need to be reasonably stable (which is to say, on the order of MTBFs for reliable machines) whether or not the prefix is provider-based, topology-based, or assigned to the site. the idea that a prefix can be changed at a whim is just a fantasy. at the same time, apps that need stable connections that last for months really do need to work out mechanisms to recover from address changes, but they'd need to do this even if the addresses were permanent, because within that kind of timeframe, machines get moved, replaced, reassigned, etc anyway. the real issue is that a pre-site prefix is still a limited scope prefix. it might or might not work to reach a different site with a different per-site prefix, depending on whether you have a private connection to that site. so there's still trial-and-failure involved in knowing which address to use, and an app component cannot expect to advertise a single single global address to be reachable from all of its peers if any of those peers are at a site that relies on pre-site prefixes for connectivity (via private agreements). so it still complicates the model that apps have to be written to, though not quite as badly as SLs. but as long as we insist on provider- or topology-based addressing for the public network, I don't see a better way to solve the problem that isolated sites want to interconnect with other sites, than non-routable site-specific address prefixes. and since we cannot insist that everyone connect every host to the internet, distributed apps have to make a decision anyway - either they're only going to work on hosts that are connected to the public internet and have global addresses, or they're going to have to cope with multiple addresses and the possibility that the same address won't work everywhere. but at least we can avoid having addresses whose meaning varies from one place to another, and we can avoid having apps try to guess what addressing realm/scope they're in. > None of this is easy - there is no easy answer (or not that has been > proposed so far). indeed. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 18 08:47:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5IFl9k7029834; Tue, 18 Jun 2002 08:47:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5IFl8lc029833; Tue, 18 Jun 2002 08:47:08 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5IFl5k7029826 for ; Tue, 18 Jun 2002 08:47:05 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA16267 for ; Tue, 18 Jun 2002 08:47:10 -0700 (PDT) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA16163 for ; Tue, 18 Jun 2002 09:47:09 -0600 (MDT) Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 18 Jun 2002 08:47:08 -0700 Message-ID: <2B81403386729140A3A899A8B39B046406C848@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 X-MS-Has-Attach: content-class: urn:content-classes:message X-MS-TNEF-Correlator: Thread-Topic: Fwd: IPv6 Scoped Addresses and Routing Protocols Thread-Index: AcIW3ks0ZhrlzLDATr2bbsRAi+NqeQAAMRxQ From: "Michel Py" To: "Michael Thomas" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5IFl5k7029827 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Michael Thomas wrote: > Requiring hosts to have knowledge of network topology > is a bug, not a feature. I agree, but there would be ways to use SL by having them handled by the routers only, with a routing protocol. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 18 14:23:21 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5ILNKk7000806; Tue, 18 Jun 2002 14:23:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5ILNK7Y000805; Tue, 18 Jun 2002 14:23:20 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5ILNHk7000798 for ; Tue, 18 Jun 2002 14:23:17 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA23855 for ; Tue, 18 Jun 2002 14:23:21 -0700 (PDT) Received: from alicia.nttmcl.com (alicia.nttmcl.com [216.69.69.10]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA18433 for ; Tue, 18 Jun 2002 15:23:21 -0600 (MDT) Received: (from jj@localhost) by alicia.nttmcl.com (8.10.1/8.10.1) id g5ILNJi29156; Tue, 18 Jun 2002 14:23:19 -0700 (PDT) Date: Tue, 18 Jun 2002 14:23:19 -0700 From: JJ Behrens To: Michel Py Cc: ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols Message-ID: <20020618142319.B17770@alicia.nttmcl.com> References: <2B81403386729140A3A899A8B39B046405E107@server2000.arneill-py.sacramento.ca.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <2B81403386729140A3A899A8B39B046405E107@server2000.arneill-py.sacramento.ca.us>; from michel@arneill-py.sacramento.ca.us on Thu, Jun 13, 2002 at 07:47:02PM -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > JJ Behrens wrote: > > Michael, > > I am no security wizard. However, it seems to me that you are > > suggesting that site-local addresses add a small amount of > > security because there's no way to connect directly from the > > attacker's machine to the database machine. However, if the Web > > server has been compromised (which is a very reasonable proposition > > based on recent events), it seems just as easy for the attacker to > > mount his attack by first ssh'ing to the Web server, and then > > attacking the database server from there. > > I welcome your corrections if I have missed something. > > You have perfectly understood. The point I was trying to make is not how > easy or difficult it is to hack the web server, but that it is one extra > step that the hacker has to take. If the database server has no access > to the outside, the hacker needs to have enough access and skills to > install some kind of a proxy server that will read the data from the > database server to the web server, then send this data back to the > hacker. This is no easy task. > > In other words: Yes it is possible to copy data from a machine that does > not have access to the outside, but it does require skills that some > hackers do not have. Let's say you know Windows, but the server you > compromise is an obscure flavor of Unix. How much time is it going to > take you to understand how that system is configured, write the software > to proxy the data, compile it in a way that the host likes, install it, > etc. All of that without being caught. > > Granted, that will not stop a good hacker, but that will stop the > disgruntled employee that does not know jack but the passwords. > > I read somewhere that 80% of computer crime is committed by people that > are nowhere near what you would call a hacker but have insider's info. > If using SL keeps half of these 80% out, I'm more than happy with it. > > A significant part of securing a host or network is putting a large > number of roadblocks in the hacker's way. None of the road blocks are > impossible to pass, the goal is to get the hacker tired before the end. > I have to insist that a host that has direct access to the Internet > (such as an RFC 1918 host with NAT) is indeed less secure than a host > that does not (such as a v6 host with a SL address only). Your point is valid. Now it remains to be argued whether the difficulties associated with SL's are worth this small increase in security. Personally, I feel that this small increase in security is not worth the extra work. However, it remains to be seen whether we can solve the renumbering problem (i.e. the use of SL's for longterm stable IP's). Best Regards, -jj -- Users of C++ should consider hanging themselves rather than shooting their legs off--it's best not to use C++ simply as a better C. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 18 15:14:21 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5IMEKk7000923; Tue, 18 Jun 2002 15:14:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5IMEKit000922; Tue, 18 Jun 2002 15:14:20 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5IMEHk7000915 for ; Tue, 18 Jun 2002 15:14:17 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA03831 for ; Tue, 18 Jun 2002 15:14:22 -0700 (PDT) Received: from alicia.nttmcl.com (alicia.nttmcl.com [216.69.69.10]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA11999 for ; Tue, 18 Jun 2002 15:14:22 -0700 (PDT) Received: (from jj@localhost) by alicia.nttmcl.com (8.10.1/8.10.1) id g5IMBcU02673; Tue, 18 Jun 2002 15:11:38 -0700 (PDT) Date: Tue, 18 Jun 2002 15:11:38 -0700 From: JJ Behrens To: Robert Elz Cc: Margaret Wasserman , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols Message-ID: <20020618151138.C17770@alicia.nttmcl.com> References: <4.2.2.20020614141439.02548370@mail.windriver.com> <200206141557.g5EFvnZs020596@thunk.east.sun.com> <200206141557.g5EFvnZs020596@thunk.east.sun.com> <4.2.2.20020614141439.02548370@mail.windriver.com> <28632.1024190950@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <28632.1024190950@munnari.OZ.AU>; from kre@munnari.OZ.AU on Sun, Jun 16, 2002 at 08:29:10AM +0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > | And what do we actually get for this added complexity? > > I think this has been answered enough. People are ignoring the > benefit as no-one is actually being made to renumber their IPv6 > sites currently. Please correct me if I'm wrong, but doesn't DNS help here a lot? It's trivial to update the prefix of a bunch of boxes in DNS. Perhaps the only critique of this approach concerns very long-term connections. Best Regards, -jj -- Users of C++ should consider hanging themselves rather than shooting their legs off--it's best not to use C++ simply as a better C. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 18 17:12:21 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5J0CLk7001200; Tue, 18 Jun 2002 17:12:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5J0CK04001199; Tue, 18 Jun 2002 17:12:20 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5J0CGk7001192 for ; Tue, 18 Jun 2002 17:12:16 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA03686 for ; Tue, 18 Jun 2002 17:12:23 -0700 (PDT) Received: from astro.cs.utk.edu ([160.36.58.43]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA05019 for ; Tue, 18 Jun 2002 17:12:22 -0700 (PDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5J04GK00965; Tue, 18 Jun 2002 20:04:18 -0400 (EDT) Message-Id: <200206190004.g5J04GK00965@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: JJ Behrens cc: Robert Elz , Margaret Wasserman , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-reply-to: (Your message of "Tue, 18 Jun 2002 15:11:38 PDT.") <20020618151138.C17770@alicia.nttmcl.com> Date: Tue, 18 Jun 2002 20:04:16 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Please correct me if I'm wrong, but doesn't DNS help here a lot? DNS is only part of the picture. prefixes and addresses are stored in lots of places besides DNS - e.g. running applications, stacks, host configuration files, routers, firewalls, network management stations, and traffic monitors. There's no good mechanism for updating all of these, and DNS can only solve part of the problem. for instance there's an inherent conflict between a host or server needing to assert its identity or service name (as many server hosts do) and the network trying to assign addresses (or even prefixes) to hosts (as many networks do). a reasonable renumbering solution needs to support some hybrid of these - neither extreme is inherently the right approach. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 18 20:16:16 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5J3GFk7001445; Tue, 18 Jun 2002 20:16:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5J3GFmP001444; Tue, 18 Jun 2002 20:16:15 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5J3GCk7001437 for ; Tue, 18 Jun 2002 20:16:12 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA22107 for ; Tue, 18 Jun 2002 20:16:18 -0700 (PDT) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA12164 for ; Tue, 18 Jun 2002 20:16:18 -0700 (PDT) Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 18 Jun 2002 20:16:17 -0700 Message-ID: <2B81403386729140A3A899A8B39B046405E12B@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 X-MS-Has-Attach: content-class: urn:content-classes:message X-MS-TNEF-Correlator: Thread-Topic: Fwd: IPv6 Scoped Addresses and Routing Protocols Thread-Index: AcIXDndfl81nsMk/R3KSwkxAZ1/HRgAKuorQ From: "Michel Py" To: "JJ Behrens" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5J3GCk7001438 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > JJ Behrens wrote: > [Michel's point about SLs being somehow more secure] > Your point is valid. Now it remains to be argued whether the > difficulties associated with SL's are worth this small increase > in security. Personally, I feel that this small increase in > security is not worth the extra work. However, it remains to be > seen whether we can solve the renumbering problem (i.e. the use > of SL's for longterm stable IP's). A matter of appreciation, indeed. But there is some demand for SLs. So, what about comparing the extra work required to make SLs work to the work required to suppress them, plus the work required to deal with whatever (possibly more crappy) will replace them? Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 18 21:26:57 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5J4Qvk7001558; Tue, 18 Jun 2002 21:26:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5J4QvhZ001557; Tue, 18 Jun 2002 21:26:57 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5J4Qsk7001550 for ; Tue, 18 Jun 2002 21:26:54 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA06653 for ; Tue, 18 Jun 2002 21:26:59 -0700 (PDT) Received: from hotmail.com (f50.law4.hotmail.com [216.33.149.50]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA13820 for ; Tue, 18 Jun 2002 22:29:07 -0600 (MDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 18 Jun 2002 21:26:58 -0700 Received: from 12.234.202.37 by lw4fd.law4.hotmail.msn.com with HTTP; Wed, 19 Jun 2002 04:26:58 GMT X-Originating-IP: [12.234.202.37] From: "Tissa Senevirathne" To: ipng@sunroof.eng.sun.com Subject: ID on BGP extensions to Tag IPv6 routes that has IPv4 tunnels Date: Wed, 19 Jun 2002 04:26:58 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 19 Jun 2002 04:26:58.0507 (UTC) FILETIME=[8CFA71B0:01C21749] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ID below describe use of BGP extended community attributes to tag IPv6 routes that need IPv4 tunneling. Please could you comment. http://search.ietf.org/internet-drafts/draft-tsenevir-ipv6-bgp-tun-00.txt Thanks Tissa _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.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 Jun 18 22:51:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5J5ptk7001813; Tue, 18 Jun 2002 22:51:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5J5pt2x001812; Tue, 18 Jun 2002 22:51:55 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5J5pqk7001805 for ; Tue, 18 Jun 2002 22:51:52 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA25528 for ; Tue, 18 Jun 2002 22:51:57 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.96.5]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA03665 for ; Tue, 18 Jun 2002 23:51:52 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g5J5oZM01412; Wed, 19 Jun 2002 12:50:45 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g5J5mif26136; Wed, 19 Jun 2002 12:48:45 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Michael Thomas cc: Keith Moore , Bill Fenner , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-Reply-To: <15631.20833.505187.593662@thomasm-u1.cisco.com> References: <15631.20833.505187.593662@thomasm-u1.cisco.com> <200206181446.g5IEkrY12563@astro.cs.utk.edu> <8786.1024413192@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 19 Jun 2002 12:48:44 +0700 Message-ID: <26134.1024465724@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 18 Jun 2002 08:27:29 -0700 (PDT) From: Michael Thomas Message-ID: <15631.20833.505187.593662@thomasm-u1.cisco.com> | This, to my mind, is the very basic reason why | SL addresses are a generally Bad Idea. Requiring | hosts to have knowledge of network topology is | a bug, not a feature. I agree with the last sentence, but knowing about SL addresses tells you nothing at all about network topology. The two just aren't related. Assigning SL addresses requires knowledge of the topology (as does assigning global addreses), but to use one doesn't. All the hosts do is use them. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 18 22:57:07 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5J5v6k7001836; Tue, 18 Jun 2002 22:57:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5J5v6Bq001835; Tue, 18 Jun 2002 22:57:06 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5J5v3k7001828 for ; Tue, 18 Jun 2002 22:57:03 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA26680 for ; Tue, 18 Jun 2002 22:57:09 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA00049 for ; Tue, 18 Jun 2002 22:57:08 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g5J5v3h02637; Wed, 19 Jun 2002 08:57:03 +0300 Date: Wed, 19 Jun 2002 08:57:02 +0300 (EEST) From: Pekka Savola To: Tissa Senevirathne cc: ipng@sunroof.eng.sun.com Subject: Re: ID on BGP extensions to Tag IPv6 routes that has IPv4 tunnels 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 Wed, 19 Jun 2002, Tissa Senevirathne wrote: > ID below describe use of BGP extended community attributes to tag IPv6 > routes that need IPv4 tunneling. > > Please could you comment. > > http://search.ietf.org/internet-drafts/draft-tsenevir-ipv6-bgp-tun-00.txt Have you read: http://search.ietf.org/internet-drafts/draft-ietf-ngtrans-bgp-tunnel-04.txt ? -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 18 23:20:31 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5J6KUk7001886; Tue, 18 Jun 2002 23:20:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5J6KUA5001885; Tue, 18 Jun 2002 23:20:30 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5J6KQk7001878 for ; Tue, 18 Jun 2002 23:20:26 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA28219 for ; Tue, 18 Jun 2002 23:20:32 -0700 (PDT) Received: from astro.cs.utk.edu ([160.36.58.43]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA14540 for ; Wed, 19 Jun 2002 00:20:31 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5J6DNK08234; Wed, 19 Jun 2002 02:13:23 -0400 (EDT) Message-Id: <200206190613.g5J6DNK08234@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Robert Elz cc: Michael Thomas , Keith Moore , Bill Fenner , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-reply-to: (Your message of "Wed, 19 Jun 2002 12:48:44 +0700.") <26134.1024465724@munnari.OZ.AU> Date: Wed, 19 Jun 2002 02:13:23 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I agree with the last sentence, but knowing about SL addresses > tells you nothing at all about network topology. The two just > aren't related. Assigning SL addresses requires knowledge of > the topology (as does assigning global addreses), but to use > one doesn't. All the hosts do is use them. actually a distributed app does in some sense need to know about network topology in order to use SL addresses, because a component might send a referral using an SL address to another component that isn't at the same site. without some notion of topology the app has no idea which address to use in the referral. it's very much like the problem that occurs with NATs. the app could simply refuse to use SL addresses, but then it wouldn't be able to use components at sites that don't have global addresses. though I expect it's more likely that the app would pass multiple addresses in the referral and let the components receiving those referrals do trial-and-failure until they find an address which works to reach the desired component, than actually trying to make the app aware of topology. still, it stinks no matter how you do it. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 18 23:48:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5J6mjk7001990; Tue, 18 Jun 2002 23:48:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5J6mjUo001989; Tue, 18 Jun 2002 23:48:45 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5J6mfk7001982 for ; Tue, 18 Jun 2002 23:48:42 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA03159 for ; Tue, 18 Jun 2002 23:48:45 -0700 (PDT) Received: from ALPHA8.CC.MONASH.EDU.AU (alpha8.cc.monash.edu.au [130.194.1.8]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA05098 for ; Tue, 18 Jun 2002 23:48:44 -0700 (PDT) Received: from splat.its.monash.edu.au ([130.194.1.73]) by vaxh.cc.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01KJ4EDIBVBI8ZKAR5@vaxh.cc.monash.edu.au> for ipng@sunroof.eng.sun.com; Wed, 19 Jun 2002 16:47:59 +1000 Received: from splat (unknown [127.0.0.1]) by localhost (Postfix) with ESMTP id 2A62B13000A; Wed, 19 Jun 2002 06:47:53 +0000 (/etc/localtime) Received: from eng.monash.edu.au (brettpc.eng.monash.edu.au [130.194.252.100]) by splat.its.monash.edu.au (Postfix) with ESMTP id B8D3213000D; Wed, 19 Jun 2002 16:47:40 +1000 (EST) Date: Wed, 19 Jun 2002 16:46:06 +1000 From: Brett Pentland Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols To: Keith Moore Cc: Robert Elz , Michael Thomas , Bill Fenner , ipng@sunroof.eng.sun.com Message-id: <3D1028AE.9070303@eng.monash.edu.au> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020408 X-Accept-Language: en-us, en References: <200206190613.g5J6DNK08234@astro.cs.utk.edu> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith Moore wrote: >>I agree with the last sentence, but knowing about SL addresses >>tells you nothing at all about network topology. The two just >>aren't related. Assigning SL addresses requires knowledge of >>the topology (as does assigning global addreses), but to use >>one doesn't. All the hosts do is use them. > > > actually a distributed app does in some sense need to know > about network topology in order to use SL addresses, because > a component might send a referral using an SL address to another > component that isn't at the same site. without some notion > of topology the app has no idea which address to use in the > referral. it's very much like the problem that occurs with NATs. Is it good practice for such an app to use addresses directly, rather than hostnames (that are then resolved through DNS into global addresses anyway)? Perhaps this is an example of a bad use of SL but does it mean that SL is inherently bad? Regards, Brett. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 19 02:31:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5J9Vak7002414; Wed, 19 Jun 2002 02:31:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5J9Vamj002413; Wed, 19 Jun 2002 02:31: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.12.4/8.12.4) with ESMTP id g5J9VWk7002406 for ; Wed, 19 Jun 2002 02:31:33 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA03415 for ; Wed, 19 Jun 2002 02:31:37 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.96.5]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA10793 for ; Wed, 19 Jun 2002 03:31:30 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g5J9UaM05151; Wed, 19 Jun 2002 16:30:37 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g5J9U6f26517; Wed, 19 Jun 2002 16:30:06 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Keith Moore cc: Bill Fenner , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-Reply-To: <200206181540.g5IFecY19885@astro.cs.utk.edu> References: <200206181540.g5IFecY19885@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 19 Jun 2002 16:30:05 +0700 Message-ID: <26515.1024479005@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 18 Jun 2002 11:40:38 -0400 From: Keith Moore Message-ID: <200206181540.g5IFecY19885@astro.cs.utk.edu> [Aside: I have been interrupted many times while creating this message. (Its life span in my editor runs to many hours now...) I see that while I have been waiting, you have replied to an earlier message I sent. I think that the points you made there have been covered in this reply already, before I saw your later message, so I won't reply to that one as well - much of this is all based around the usage model for SL addresses - for sure, it is possible to imagine some in which SL addressing would be absolutely horrible. They should obviously be avoided. I don't think that such a model is required however, I believe that SL addressing can be mare relatively painless to use] | perhaps, but LLs really shouldn't be used except for some very odd | cases - I see LL as mostly a way to avoid having to reinvent the | same functionality differently for each L2 network. But what is of concern here largely is not how often they should be used, but whether the mechanisms to allow them to be used at all have to be provided. Once an option exists, all the support is required, even if in practice the option is never used. So, the simple existence of LL addresses, and the possibility that a node may be connected to two links, each with its own set of LL addresses, and to nothing else at all (no global addressing, and in your model, no SL addressing) means that apps need to have all the baggage in them to deal with sending to either one of those links - even if in practice it gets used almost never. It is because all this is *required* anyway, that I can't see where the big extra costs for using SL addresses come from - it is all just the same extra baggage. | I don't think stability is the issue. Stability is absolutely the issue. | global addrs need to be reasonably | stable (which is to say, on the order of MTBFs for reliable machines) | whether or not the prefix is provider-based, topology-based, or | assigned to the site. the idea that a prefix can be changed at a whim | is just a fantasy. That would sure be nice. But no-one has yet suggested any mechanism by which we confine this to the realms of fantasy, and stop it becoming reality. If you can do that, by all means, I'd love to know how it is to be achieved. The argument so far seems to be "it hasn't happened yet, and I wouldn't like it if it did happen, so I will just declare it impossible". Even worse, to a fair degree there's a large amount of assuming this, and then "simplifying" things based upon this assumption being a fact, to the degree that when (if) the assumption turns out to be wrong, we'll all be much worse off. Another assumption is that when renumbering does happen, the old and new overlap will be so long, that nothing that really matters will care if it stops working (there will be so little, and it will be so infrequent that it just won't really matter). The problem with this is that the overlap period is a period if instability, and in general, people want such periods to be as short as possible, not as long. Make it too long and you may end up with a new renumbering being required before the first one is fixed. Now I certainly don't know that renumbering will happen often, or at any particular frequency, I'd certainly mush prefer stable addressing that never changes. But I am not prepared to assume that is how things will end up, so I want to plan for the worst, and give everything the greatest possibility to work properly - so I assume that one day (maybe 10-15 years away, who knows) some significant renumbering will start to be needed. I want the protocols we are installing now (along with enhancements over this period) to be able to cope with that. If later events show that some other solution is found, and site local addresses have no role left to play, then they can simply fade away, we can declare them historic, and we will have wasted some effort, on what is really insurance. I'd love it if that happened, but I actually think this insurance is more like car insurance, than plane crash insurance - it isn't the kind you take out but expect never to have to use, it is the kind we take out, because it is very likely it will actually be needed, sometime or other (just my opinion of course). | at the same time, apps that need stable connections | that last for months really do need to work out mechanisms to recover | from address changes, but they'd need to do this even if the addresses | were permanent, because within that kind of timeframe, machines get moved, | replaced, reassigned, etc anyway. Yes. Back when IPng was being started, I really wanted us to do TCPng at the same time (which may have turned out to be SCTP or something like it) - so that we could expect that coping with address changes would be much easier. But almost no-one else wanted to do that... So I don't really have great hopes that we're going to get things like NFS, changed so that they can cope with address changes transparently. Again, great if it happens, I'm just not willing to gamble everything on success in that area. | the real issue is that a pre-site prefix is still a limited scope prefix. Yes. | it might or might not work to reach a different site with a different | per-site prefix, depending on whether you have a private connection to | that site. Yes. | so there's still trial-and-failure involved in knowing which | address to use, Yes. | and an app component cannot expect to advertise a single | single global address to be reachable from all of its peers if any | of those peers are at a site that relies on pre-site prefixes for | connectivity (via private agreements). Well, again, I'd simply require everyone to have global addresses that work. That is, I would make site local addressing actually depend upon global addressing working. To some extent this (not by design) mitigates Jim Bound's concern about SL addressing defeating end to end, as I would have SL addressing simply not work if end to end didn't work first. So, creating a private fiefdom with only SL addressing (any not routed address space really) and expecting it to function to communicate with others just won't work at all - except in the case of sites running a private DNS, which really should be only disconnected sites - when the DNS can simply be set up to return all addresses that actually work - if you put an address there, it better work for everyone who can possibly get that answer, directly or indirectly). | so it still complicates the | model that apps have to be written to, though not quite as badly as SLs. I don't see the difference. Note that the only apps that really need to be much complicated by SL's (aside from the scope part, which is really largely hidden - the lower layers include it in the addr structure, and the app just uses the whole thing) when they're trying to be fancy with addresses. That is, for example, to send an address from one node to another. My model for that would be for the app to send only global addresses, (more accurately, only addresses that were received from the DNS) never site locals (which only requires that they be easy to recognise). Note: I require everything to have a global address, so there's never a problem doing that (no guarantee that the global will work from the place it is being sent - but that's the same whether SL's exist or not). Then where the address is received, the app can decide if it would be better to use a SL addr if it can, and discover the SL addr for itself (most apps won't bother, as they're not going to be affected). | but as long as we insist on provider- or topology-based addressing for | the public network, I don't see a better way to solve the problem that | isolated sites want to interconnect with other sites, than non-routable | site-specific address prefixes. No, nor do I. I have no problems with these things. If they're used only by completely non-connected sites, they'll work just fine. And continue regardless of whether SL addresses also exist. But if they get seen by a globally connected site, then they start to cause other problems (including how we find the things in the first place, given the "disconnected" site isn't going to be in the the DNS). | and since we cannot insist that everyone connect every host to the | internet, We can't insist that everyone make every host reachable from the internet - we can insist that everything be given a global address. We don't do it quite in that way of course, instead we just design things so that if everything doesn't have a global address, it doesn't work, even locally. We make lots of that kind of decision (as does everyone else who builds things). | but at least we can avoid having addresses | whose meaning varies from one place to another, and we can avoid | having apps try to guess what addressing realm/scope they're in. I would never let an app see an address whose meaning varied (beyond what it gets told in the address itself). That is, for a site local with a scope attached, just consider the scope to be the most significant bits of the address. With this interpretation, all addresses the app should ever see are ones with (instantaneous anyway) fixed meanings. Embedding the scope in the SL addr, and calling it a site identifier, doesn't change that, it just means that more addresses are available. The same should be somehow made true if global prefixes were to be assigned - apps would need some way to know which would work, and which would not - this looks to be the biggest drawback to that approach to me. 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 Jun 19 06:32:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5JDWOk7002817; Wed, 19 Jun 2002 06:32:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5JDWOfH002816; Wed, 19 Jun 2002 06:32:24 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5JDWKk7002809 for ; Wed, 19 Jun 2002 06:32:20 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA14505 for ; Wed, 19 Jun 2002 06:32:25 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA21412 for ; Wed, 19 Jun 2002 07:32:24 -0600 (MDT) Received: from kenawang ([147.11.233.18]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id GAA12619; Wed, 19 Jun 2002 06:30:43 -0700 (PDT) Message-Id: <4.2.2.20020619092327.022a1d60@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 19 Jun 2002 09:32:10 -0400 To: Robert Elz From: Margaret Wasserman Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols Cc: ipng@sunroof.eng.sun.com In-Reply-To: <26515.1024479005@munnari.OZ.AU> References: <200206181540.g5IFecY19885@astro.cs.utk.edu> <200206181540.g5IFecY19885@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Robert, At 05:30 AM 6/19/02 , Robert Elz wrote: >If later events show that some other solution is found, and site local >addresses have no role left to play, then they can simply fade away, >we can declare them historic, and we will have wasted some effort, on >what is really insurance. If site-local addressing is "really insurance", and may "fade away" later, would this be an argument for: - Moving site-local out of the base IPv6 specs into separate documents (with the exception of reserving their address space in the addressing architecture)? - Determining the status (PS, DS, experimental, historic) of those documents separately? - Making site-local implementation optional? Maybe hosts that don't implement SL should treat them as global, routers should, by default, never forward them? -- This opens the possibility of enabling site-local later with changes only in routers. What do you think? Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 19 07:33:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5JEXfk7002981; Wed, 19 Jun 2002 07:33:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5JEXf8E002980; Wed, 19 Jun 2002 07:33:41 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5JEXak7002973 for ; Wed, 19 Jun 2002 07:33:37 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA11600 for ; Wed, 19 Jun 2002 07:33:40 -0700 (PDT) Received: from astro.cs.utk.edu ([160.36.58.43]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA05955 for ; Wed, 19 Jun 2002 08:33:35 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5JEOUK09638; Wed, 19 Jun 2002 10:24:30 -0400 (EDT) Message-Id: <200206191424.g5JEOUK09638@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Brett Pentland cc: Keith Moore , Robert Elz , Michael Thomas , Bill Fenner , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-reply-to: (Your message of "Wed, 19 Jun 2002 16:46:06 +1000.") <3D1028AE.9070303@eng.monash.edu.au> Date: Wed, 19 Jun 2002 10:24:30 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Is it good practice for such an app to use addresses directly, rather > than hostnames (that are then resolved through DNS into global addresses > anyway)? yes. DNS is often slow, unreliable, or even unavailable. many hosts don't know their own DNS names, or if they do know a name, it's not fully- qualified. it's not reasonable to expect all apps to use DNS every time they start a new communication with a host. > Perhaps this is an example of a bad use of SL but does it mean > that SL is inherently bad? none of this is inherently, absolutely bad, but some things are worse than others. I think SL is far more trouble than it's worth. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 19 08:08:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5JF8mk7003125; Wed, 19 Jun 2002 08:08:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5JF8m5N003124; Wed, 19 Jun 2002 08:08:48 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5JF8hk7003108 for ; Wed, 19 Jun 2002 08:08:43 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA17253 for ; Wed, 19 Jun 2002 08:08:47 -0700 (PDT) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA20945 for ; Wed, 19 Jun 2002 09:08:47 -0600 (MDT) Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 19 Jun 2002 08:08:45 -0700 Message-ID: <2B81403386729140A3A899A8B39B046405E130@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 X-MS-Has-Attach: content-class: urn:content-classes:message X-MS-TNEF-Correlator: Thread-Topic: Fwd: IPv6 Scoped Addresses and Routing Protocols Thread-Index: AcIXlljyJNiAGWD9SMyQ8aOTxfyeHwAC1K5g From: "Michel Py" To: "Margaret Wasserman" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5JF8ik7003109 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Margaret Wasserman wrote: > - Making site-local implementation optional? Maybe hosts that > don't implement SL should treat them as global, routers should, > by default, never forward them? -- This opens the possibility > of enabling site-local later with changes only in routers. I have to say that using SLs on a v6 portable phone would not be my top priority if I was developing such a product. It seems that all the perceived need for SLs is for fixed hosts on relatively large setups. What about a clause making the implementation optional for mobile devices? Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 19 08:13:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5JFDbk7003302; Wed, 19 Jun 2002 08:13:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5JFDb8X003301; Wed, 19 Jun 2002 08:13:37 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5JFDXk7003294 for ; Wed, 19 Jun 2002 08:13:33 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA27923 for ; Wed, 19 Jun 2002 08:13:38 -0700 (PDT) Received: from astro.cs.utk.edu ([160.36.58.43]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA11165 for ; Wed, 19 Jun 2002 08:13:37 -0700 (PDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5JF7AK15279; Wed, 19 Jun 2002 11:07:10 -0400 (EDT) Message-Id: <200206191507.g5JF7AK15279@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Robert Elz cc: Keith Moore , Bill Fenner , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-reply-to: (Your message of "Wed, 19 Jun 2002 16:30:05 +0700.") <26515.1024479005@munnari.OZ.AU> Date: Wed, 19 Jun 2002 11:07:10 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > But what is of concern here largely is not how often they should be > used, but whether the mechanisms to allow them to be used at all have > to be provided. Once an option exists, all the support is required, > even if in practice the option is never used. > > So, the simple existence of LL addresses, and the possibility that a > node may be connected to two links, each with its own set of LL addresses, > and to nothing else at all (no global addressing, and in your model, no > SL addressing) means that apps need to have all the baggage in them to > deal with sending to either one of those links - even if in practice > it gets used almost never. I guess I disagree, because I don't think existence of an API for sending/receiving raw IP packets compels apps to support that either. but it depends to some degree on how LL is pitched to the public. the zeroconf WG is pitching v4 LL as a mechanism to allow appliances to auto-configure themselves, and therefore encouraging use of LL by applications, with all of problems that exist for v6 LL and more. I don't think use of LL by apps is a good idea for either v4 or v6. > It is because all this is *required* anyway, that I can't see where the > big extra costs for using SL addresses come from - it is all just the > same extra baggage. the danger is that SL addrs are clearly meant for use by apps, while it can be argued that LLs aren't meant for GP use. > | I don't think stability is the issue. > > Stability is absolutely the issue. I guess it depends on how often the network's global prefixes are renumbered and whether this is done as a planned event or on the whim of the ISP with little or not notice. To me the later is simply unacceptable, but I don't pretend I/we can stop ISPs from doing that. ISPs that pull that kind of stunt deserve to go out of business quickly. > | global addrs need to be reasonably > | stable (which is to say, on the order of MTBFs for reliable machines) > | whether or not the prefix is provider-based, topology-based, or > | assigned to the site. the idea that a prefix can be changed at a whim > | is just a fantasy. > > That would sure be nice. But no-one has yet suggested any mechanism > by which we confine this to the realms of fantasy, and stop it becoming > reality. If you can do that, by all means, I'd love to know how it is > to be achieved. to some degree this is govered by public perception about what is reasonable, and such perception can be influenced by standards. so we do have some influence here. we should try to use it. > Even worse, to a fair degree there's a large amount of assuming this, and > then "simplifying" things based upon this assumption being a fact, to > the degree that when (if) the assumption turns out to be wrong, we'll > all be much worse off. either you have to assume some kind of predictable behavior by the network, or you have to build your own network to your own specs all the way to every machine you wish to connect to. that predictable behavior is more- or-less determined by the specifications. there's no way to absolutely prevent brain-damage like unannounced renumbering, but it can be discouraged. and if such renumbering breaks valuable functions, and is unnecessary, that creates a market opportunity for a competitor to that ISP. > Another assumption is that when renumbering does happen, the old and new > overlap will be so long, that nothing that really matters will care if > it stops working (there will be so little, and it will be so infrequent > that it just won't really matter). The problem with this is that the > overlap period is a period if instability, and in general, people want > such periods to be as short as possible, not as long. Make it too long > and you may end up with a new renumbering being required before the first > one is fixed. Well, the assumption (correct or not) is that a site can tolerate multiple prefixes anyway, so that the degree of "instability" due to overlap will be acceptable. Whether this is true is yet TBD. > Now I certainly don't know that renumbering will happen often, or at > any particular frequency, I'd certainly mush prefer stable addressing that > never changes. But I am not prepared to assume that is how things will > end up, so I want to plan for the worst, and give everything the greatest > possibility to work properly - so I assume that one day (maybe 10-15 > years away, who knows) some significant renumbering will start to be > needed. I want the protocols we are installing now (along with > enhancements over this period) to be able to cope with that. well, there is more than one idea about how to give everything the greatest possibility to work properly. one way is to design a simple and easily understood way of having things work properly, with clear separation of function between various layers (e.g. the network/ISP is responsible for making sure that address prefixes don't change without X amount of notice and Y amount of overlap, and apps that need to keep connections open longer than Y are responsible for having their own mechanisms for doing so). another way is to introduce extra complexity and overlap between functionality (belt-and-suspenders approach) which might assume that the app will compensate for any degree of instabliity in the network. To me the latter way is more expensive, introduces more potential for failure, and is harder to fix problems when they occur because the ISP can blame the app implementor and vice versa. Once you have complexity, it's difficult to get rid of it. So I prefer the simple approach. > If later events show that some other solution is found, and site local > addresses have no role left to play, then they can simply fade away, > we can declare them historic, and we will have wasted some effort, on > what is really insurance. I'd love it if that happened, but I actually > think this insurance is more like car insurance, than plane crash > insurance - it isn't the kind you take out but expect never to have to > use, it is the kind we take out, because it is very likely it will > actually be needed, sometime or other (just my opinion of course). > > | at the same time, apps that need stable connections > | that last for months really do need to work out mechanisms to recover > | from address changes, but they'd need to do this even if the addresses > | were permanent, because within that kind of timeframe, machines get moved, > | replaced, reassigned, etc anyway. > > Yes. Back when IPng was being started, I really wanted us to do TCPng > at the same time (which may have turned out to be SCTP or something like > it) - so that we could expect that coping with address changes would be > much easier. But almost no-one else wanted to do that... > > So I don't really have great hopes that we're going to get things like > NFS, changed so that they can cope with address changes transparently. easiest way to fix this is to have NFS (and those other apps) use mobile IP. > Again, great if it happens, I'm just not willing to gamble everything > on success in that area. > > | the real issue is that a pre-site prefix is still a limited scope prefix. > > Yes. > > | it might or might not work to reach a different site with a different > | per-site prefix, depending on whether you have a private connection to > | that site. > > Yes. > > | so there's still trial-and-failure involved in knowing which > | address to use, > > Yes. > > | and an app component cannot expect to advertise a single > | single global address to be reachable from all of its peers if any > | of those peers are at a site that relies on pre-site prefixes for > | connectivity (via private agreements). > > Well, again, I'd simply require everyone to have global addresses that > work. I don't think it flies as long as we're requiring sites to connect to the public net to get global addresses, and some sites don't want to connect to the public net at all. But they do want to connect to other sites, and they want to run the same apps that people on the public net run. > | so it still complicates the > | model that apps have to be written to, though not quite as badly as SLs. > > I don't see the difference. with global non-routable addresses, the site-id is carried along with the address, it's exposed as part of the address (assuming a reserved prefix for such addresses), it's returned in the same kind of DNS RR that carries a normal address. the address is globally scoped so there is no chance of mistaking an address from a remote site as being one from a local site or a different remote site. > Note that the only apps that really need to be much complicated by SL's > (aside from the scope part, which is really largely hidden - the lower > layers include it in the addr structure, and the app just uses the whole > thing) when they're trying to be fancy with addresses. > > That is, for example, to send an address from one node to another. > > My model for that would be for the app to send only global addresses, > (more accurately, only addresses that were received from the DNS) > never site locals (which only requires that they be easy to recognise). again, I don't think that flies. too many enterprise nets are not connected to the public internet have no way to get globals. in the current IPv6 view, they have no way to get global IPv6 addresses . even if they borrow a prefix from somewhere, those addresses won't really be global in the sense that they're reachable from elsewhere. > | but as long as we insist on provider- or topology-based addressing for > | the public network, I don't see a better way to solve the problem that > | isolated sites want to interconnect with other sites, than non-routable > | site-specific address prefixes. > > No, nor do I. I have no problems with these things. If they're > used only by completely non-connected sites, they'll work just fine. > And continue regardless of whether SL addresses also exist. But it seems to me that if we do have these, we don't need SL anymore. > But if they get seen by a globally connected site, then they start to cause > other problems (including how we find the things in the first place, > given the "disconnected" site isn't going to be in the the DNS). DNS is not the only mechanism by which apps find addresses, nor should it be. I expect to see even more such mechanisms in the future. > | and since we cannot insist that everyone connect every host to the > | internet, > > We can't insist that everyone make every host reachable from the > internet - we can insist that everything be given a global address. perhaps (and I probably agree), but right now we're insisting on just the opposite. > | but at least we can avoid having addresses > | whose meaning varies from one place to another, and we can avoid > | having apps try to guess what addressing realm/scope they're in. > > I would never let an app see an address whose meaning varied (beyond > what it gets told in the address itself). I *wish* I could dictate the environments that my apps run in to that degree, but I don't have any way to prevent an app that I write from seeing such addresses. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 19 08:22:19 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5JFMJk7003344; Wed, 19 Jun 2002 08:22:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5JFMJiV003343; Wed, 19 Jun 2002 08:22:19 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5JFMFk7003336 for ; Wed, 19 Jun 2002 08:22:16 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA23784 for ; Wed, 19 Jun 2002 08:22:20 -0700 (PDT) Received: from hotmail.com (f119.law4.hotmail.com [216.33.149.119]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA29911 for ; Wed, 19 Jun 2002 08:22:20 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 19 Jun 2002 08:22:19 -0700 Received: from 12.234.168.141 by lw4fd.law4.hotmail.msn.com with HTTP; Wed, 19 Jun 2002 15:22:19 GMT X-Originating-IP: [12.234.168.141] From: "Tissa Senevirathne" To: pekkas@netcore.fi Cc: ipng@sunroof.eng.sun.com, ppvpn@ppvpn.francetelecom.com Subject: Re: ID on BGP extensions to Tag IPv6 routes that has IPv4 tunnels Date: Wed, 19 Jun 2002 15:22:19 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 19 Jun 2002 15:22:19.0970 (UTC) FILETIME=[1A658A20:01C217A5] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Truly a good question.. Thanks Here is the summary of differences. **ID: draft-tsenevir-ipv6-bgp-tun-00.txt** 1. Treat IPv4 tunneling as an attribute of the native IPv6 route 2. Extended community attributes are presented as a generic way of identifying specific properties of IPv6 routes or for that matter any route. In other words it is an extension to BGP4+ 3. Implementation vise it is easier to apply policies on attributes. Actually the recommended method is to use attributes not more messages. 4. Methods in the ID Allows Ipv6 devices(routers) to select either a native Ipv6 connection or a tunnel connection (eg: ipv4) to reach remote Ipv6 cloude, based BGP policies. 5. In the ID we treat tunneling as reachability issue of the relay routers. Thus decoupling, tunnel discovery from route policies - to simplify implementation. **ID: draft-ietf-ngtrans-bgp-tunnel-04.txt** (the way I understand..) 1. it propose to use special NLRI to encode IPv4 address (section 4.1) 2. in section 7.3 the ID explains that it does not need to use VPN specific parts of 2547. in such case the methods can be simplified further, as presented in the new ID. Conclusion: The methods presented in ID draft-tsenevir-ipv6-bgp-tun-00.txt is simpler, scalable and easy to implement. NOTE: Tunnel between relay routers is a reachability issue between them and it is better that we do not complicate our IPv6 routes with that >From: Pekka Savola >To: Tissa Senevirathne >CC: ipng@sunroof.eng.sun.com >Subject: Re: ID on BGP extensions to Tag IPv6 routes that has IPv4 tunnels >Date: Wed, 19 Jun 2002 08:57:02 +0300 (EEST) > >On Wed, 19 Jun 2002, Tissa Senevirathne wrote: > > ID below describe use of BGP extended community attributes to tag IPv6 > > routes that need IPv4 tunneling. > > > > Please could you comment. > > > > >http://search.ietf.org/internet-drafts/draft-tsenevir-ipv6-bgp-tun-00.txt > >Have you read: > >http://search.ietf.org/internet-drafts/draft-ietf-ngtrans-bgp-tunnel-04.txt > >? > >-- >Pekka Savola "Tell me of difficulties surmounted, >Netcore Oy not those you stumble over and fall" >Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home Page: http://playground.sun.com/ipng >FTP archive: ftp://playground.sun.com/pub/ipng >Direct all administrative requests to majordomo@sunroof.eng.sun.com >-------------------------------------------------------------------- _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 19 08:44:25 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5JFiPk7003502; Wed, 19 Jun 2002 08:44:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5JFiOqZ003501; Wed, 19 Jun 2002 08:44:24 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5JFiLk7003494 for ; Wed, 19 Jun 2002 08:44:21 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA28807 for ; Wed, 19 Jun 2002 08:44:26 -0700 (PDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA01145 for ; Wed, 19 Jun 2002 08:44:25 -0700 (PDT) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g5JFa4uF021185; Wed, 19 Jun 2002 08:36:04 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ABX07914; Wed, 19 Jun 2002 08:33:33 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA14852; Wed, 19 Jun 2002 08:36:25 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15632.42232.910327.457985@thomasm-u1.cisco.com> Date: Wed, 19 Jun 2002 08:36:24 -0700 (PDT) To: Brett Pentland Cc: Keith Moore , Robert Elz , Michael Thomas , Bill Fenner , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-Reply-To: <3D1028AE.9070303@eng.monash.edu.au> References: <200206190613.g5J6DNK08234@astro.cs.utk.edu> <3D1028AE.9070303@eng.monash.edu.au> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brett Pentland writes: > Keith Moore wrote: > >>I agree with the last sentence, but knowing about SL addresses > >>tells you nothing at all about network topology. The two just > >>aren't related. Assigning SL addresses requires knowledge of > >>the topology (as does assigning global addreses), but to use > >>one doesn't. All the hosts do is use them. > > > > > > actually a distributed app does in some sense need to know > > about network topology in order to use SL addresses, because > > a component might send a referral using an SL address to another > > component that isn't at the same site. without some notion > > of topology the app has no idea which address to use in the > > referral. it's very much like the problem that occurs with NATs. > > Is it good practice for such an app to use addresses directly, rather > than hostnames (that are then resolved through DNS into global addresses > anyway)? Perhaps this is an example of a bad use of SL but does it mean > that SL is inherently bad? I'll point out that SDP -- the main component for media rendezvous signaling -- doesn't use DNS names. They are sent as raw numeric addresses. So this is not entirely academic. Mike -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 19 09:54:38 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5JGsck7003898; Wed, 19 Jun 2002 09:54:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5JGscj2003897; Wed, 19 Jun 2002 09:54:38 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5JGsXk7003887 for ; Wed, 19 Jun 2002 09:54:33 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA06953 for ; Wed, 19 Jun 2002 09:54:39 -0700 (PDT) Received: from esunmail ([129.147.58.121]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA05771 for ; Wed, 19 Jun 2002 10:54:38 -0600 (MDT) Received: from xpa-fe2 (esunmail-ge1 [129.147.58.122]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 0.3 (built May 13 2002)) with ESMTP id <0GXY00LUCPN1XJ@edgemail1.Central.Sun.COM> for ipng@sunroof.eng.sun.com; Wed, 19 Jun 2002 10:54:38 -0600 (MDT) Received: from localhost ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 0.2 (built Apr 26 2002)) with ESMTPSA id <0GXY00FM2PMZY1@mail.sun.net> for ipng@sunroof.eng.sun.com; Wed, 19 Jun 2002 10:54:36 -0600 (MDT) Date: Wed, 19 Jun 2002 09:54:35 -0700 From: Alain Durand Subject: Re: IPv6 Scoped Addresses and Routing Protocols In-reply-to: <4.2.2.20020619092327.022a1d60@mail.windriver.com> To: Margaret Wasserman Cc: Robert Elz , ipng@sunroof.eng.sun.com Message-id: <3C5B9DC4-83A5-11D6-8C65-00039376A6AA@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.482) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wednesday, June 19, 2002, at 06:32 AM, Margaret Wasserman wrote: > If site-local addressing is "really insurance", and may "fade away" > later, > would this be an argument for: > > - Moving site-local out of the base IPv6 specs into separate > documents > (with the exception of reserving their address space > in the > addressing architecture)? > - Determining the status (PS, DS, experimental, historic) of > those > documents separately? > - Making site-local implementation optional? Maybe hosts that > don't > implement SL should treat them as global, routers > should, by > default, never forward them? -- This opens the > possibility > of enabling site-local later with changes only in > routers. > > What do you think? What is the impact of your proposal to the address selection rules? - 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 Jun 19 11:02:58 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5JI2vk7004069; Wed, 19 Jun 2002 11:02:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5JI2vGD004068; Wed, 19 Jun 2002 11:02:57 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5JI2rk7004061 for ; Wed, 19 Jun 2002 11:02:53 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA22737 for ; Wed, 19 Jun 2002 11:02:57 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA14802 for ; Wed, 19 Jun 2002 11:02:57 -0700 (PDT) Received: from kenawang ([147.11.233.2]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id LAA08216; Wed, 19 Jun 2002 11:01:09 -0700 (PDT) Message-Id: <4.2.2.20020619132647.022a93b0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 19 Jun 2002 14:00:30 -0400 To: Alain Durand From: Margaret Wasserman Subject: Re: IPv6 Scoped Addresses and Routing Protocols Cc: Robert Elz , ipng@sunroof.eng.sun.com In-Reply-To: <3C5B9DC4-83A5-11D6-8C65-00039376A6AA@sun.com> References: <4.2.2.20020619092327.022a1d60@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Alain, >> - Making site-local implementation optional? Maybe hosts that don't >> implement SL should treat them as global, routers should, by >> default, never forward them? -- This opens the possibility >> of enabling site-local later with changes only in routers. >> >>What do you think? > >What is the impact of your proposal to the address selection rules? There are two cases: (1) The routers don't support site-local. No site-local prefixes will be advertised, and no site-local traffic will be routed. (2) The routers do support site-local. Site-local prefixes may be advertised, and site-local traffic will be routed within the site. In both cases, the hosts will behave exactly the same, with different results. In the first case, the host will not receive any router advertisements containing site-local prefixes, so it won't build site-local source addresses. Since site-local isn't supported in the site, the host should only receive global destination addresses, and will use global source addresses to send to them. In the event of a configuration error, the host might receive a site-local destination address. In that case, it would treat the site-local destination as global and use a global source address. The destination address would not appear on-link to the host, so the packet would be sent to the default router where it would be discarded (probably with a scope exceeded ICMP error, unless we invent a new one). In the second case, the host may receive router advertisements from the router containing site-local prefixes and configure addresses of the form "". However, the host will think that these are global addresses (just like it would treat any currently undefined portion of the IPv6 address space). When a host with both site-local and global addresses configured (all treated as global) receives a global destination address, the longest-match portion of the address selection rules will result in choosing a true global address (not a site-local address). When a site-local destination is chosen, a site-local address will be preferred, for the same reason. If both site-local and global destinations are available, either might be chosen as a destination -- the host would not have any reason to prefer one over the other. I think this works fine... The current source address selection document could be simplified to remove any special handling for site-local, but a separate document could be written explaining how a more sophisticated set of selection rules could be implemented on hosts that are aware of site-local addressing. Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 19 11:31:28 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5JIVRk7004277; Wed, 19 Jun 2002 11:31:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5JIVRPq004276; Wed, 19 Jun 2002 11:31:27 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5JIVNk7004269 for ; Wed, 19 Jun 2002 11:31:23 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA16561 for ; Wed, 19 Jun 2002 11:31:27 -0700 (PDT) Received: from esunmail ([129.147.58.122]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA27613 for ; Wed, 19 Jun 2002 12:33:38 -0600 (MDT) Received: from xpa-fe2 (esunmail-ge0 [129.147.58.121]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 0.3 (built May 13 2002)) with ESMTP id <0GXY00MDOU4E0S@edgemail1.Central.Sun.COM> for ipng@sunroof.eng.sun.com; Wed, 19 Jun 2002 12:31:27 -0600 (MDT) Received: from localhost ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 0.2 (built Apr 26 2002)) with ESMTPSA id <0GXY00FMBU4DY1@mail.sun.net> for ipng@sunroof.eng.sun.com; Wed, 19 Jun 2002 12:31:26 -0600 (MDT) Date: Wed, 19 Jun 2002 11:31:25 -0700 From: Alain Durand Subject: Re: IPv6 Scoped Addresses and Routing Protocols In-reply-to: <4.2.2.20020619132647.022a93b0@mail.windriver.com> To: Margaret Wasserman Cc: Robert Elz , ipng@sunroof.eng.sun.com Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.482) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wednesday, June 19, 2002, at 11:00 AM, Margaret Wasserman wrote: [...] > If both site-local and global destinations are > available, either might be chosen as a destination -- the host would not > have any reason to prefer one over the other. So you are actually suggesting a paradigm change from the model where hosts implement a mechanism (address selection) to enforce Site Local use whenever possible to a model where application knowledgeable about site local scope may decide to take advantage of it when available. Am I right? - 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 Jun 19 12:20:30 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5JJKUk7004595; Wed, 19 Jun 2002 12:20:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5JJKUnV004594; Wed, 19 Jun 2002 12:20:30 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5JJKPk7004587 for ; Wed, 19 Jun 2002 12:20:26 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA02736 for ; Wed, 19 Jun 2002 12:20:31 -0700 (PDT) Received: from astro.cs.utk.edu ([160.36.58.43]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA01060; Wed, 19 Jun 2002 12:20:30 -0700 (PDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5JJJX200619; Wed, 19 Jun 2002 15:19:33 -0400 (EDT) Message-Id: <200206191919.g5JJJX200619@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Margaret Wasserman cc: Alain Durand , Robert Elz , ipng@sunroof.eng.sun.com Subject: Re: IPv6 Scoped Addresses and Routing Protocols In-reply-to: (Your message of "Wed, 19 Jun 2002 14:00:30 EDT.") <4.2.2.20020619132647.022a93b0@mail.windriver.com> Date: Wed, 19 Jun 2002 15:19:33 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > If both site-local and global destinations are > available, either might be chosen as a destination -- the host would not > have any reason to prefer one over the other. not so, because the address chosen may get used in other contexts besides that of the immediate source and destination. the idea that a host can reasonably choose from among addresses based on looking at only the sources and destinations of a single host pair does not hold. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 19 13:25:17 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5JKPHk7004748; Wed, 19 Jun 2002 13:25:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5JKPHcg004747; Wed, 19 Jun 2002 13:25:17 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5JKPDk7004740 for ; Wed, 19 Jun 2002 13:25:13 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA05345 for ; Wed, 19 Jun 2002 13:25:14 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA28966 for ; Wed, 19 Jun 2002 14:27:24 -0600 (MDT) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g5JKPCl07661 for ; Wed, 19 Jun 2002 15:25:12 -0500 (CDT) Received: from eamrcnt761.exu.ericsson.se (eamrcnt761.exu.ericsson.se [138.85.133.39]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g5JKPCM04192 for ; Wed, 19 Jun 2002 15:25:12 -0500 (CDT) Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Wed, 19 Jun 2002 15:24:30 -0500 Message-ID: <66F66129A77AD411B76200508B65AC69B4D620@EAMBUNT705> From: "Bernie Volz (EUD)" To: ipng@sunroof.eng.sun.com Subject: Multicast address recommended hop counts? Date: Wed, 19 Jun 2002 15:25:11 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C217CF.692A32BC" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C217CF.692A32BC Content-Type: text/plain; charset="ISO-8859-1" Is there any document (RFC or draft) that gives any guidance on setting the hop counts for multicast addresses? The hop limit is 1 by default (based on the RFC 2553) which is fine for link-local multicasts, but what about site local or other scoped multicast addresses? For example, RFC 2373 lists the following scope values for multicast groups: 0 reserved 1 node-local scope 2 link-local scope 3 (unassigned) 4 (unassigned) 5 site-local scope 6 (unassigned) 7 (unassigned) 8 organization-local scope 9 (unassigned) A (unassigned) B (unassigned) C (unassigned) D (unassigned) E global scope F reserved Is there a corresponding recommended hop count for each of the assigned scopes: 1 node-local scope Hops = 1 2 link-local scope Hops = 1 5 site-local scope Hops = ? (8, 16, 32?) 8 organization-local scope Hops = ? (8, 16, 32?) E global scope Hops = default IP TTL (64)? - Bernie Volz ------_=_NextPart_001_01C217CF.692A32BC Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Multicast address recommended hop counts?

Is there any document (RFC or draft) that gives any = guidance on setting
the hop counts for multicast addresses?

The hop limit is 1 by default (based on the RFC 2553) = which is fine for
link-local multicasts, but what about site local or = other scoped
multicast addresses?

For example, RFC 2373 lists the following scope = values for multicast
groups:
         = 0  reserved
         = 1  node-local scope
         = 2  link-local scope
         = 3  (unassigned)
         = 4  (unassigned)
         = 5  site-local scope
         = 6  (unassigned)
         = 7  (unassigned)
         = 8  organization-local scope
         = 9  (unassigned)
         = A  (unassigned)
         = B  (unassigned)
         = C  (unassigned)
         = D  (unassigned)
         = E  global scope
         = F  reserved

Is there a corresponding recommended hop count for = each of the
assigned scopes:
         = 1  node-local = scope         Hops =3D 1
         = 2  link-local = scope         Hops =3D 1
         = 5  site-local = scope         Hops =3D ? (8, = 16, 32?)
         = 8  organization-local scope Hops =3D ? (8, 16, 32?)
         = E  global = scope           &= nbsp; Hops =3D default IP TTL (64)?

- Bernie Volz

------_=_NextPart_001_01C217CF.692A32BC-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 19 14:41:14 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5JLfEk7005066; Wed, 19 Jun 2002 14:41:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5JLfEIv005065; Wed, 19 Jun 2002 14:41:14 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5JLfAk7005058 for ; Wed, 19 Jun 2002 14:41:11 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA12277 for ; Wed, 19 Jun 2002 14:41:15 -0700 (PDT) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA25729 for ; Wed, 19 Jun 2002 15:41:14 -0600 (MDT) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id BD06C6833; Wed, 19 Jun 2002 17:41:13 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 19 Jun 2002 17:41:13 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols Date: Wed, 19 Jun 2002 17:41:13 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B8B15@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Fwd: IPv6 Scoped Addresses and Routing Protocols Thread-Index: AcIWHnuKNY1G09ysRIS0clCnb838ZwBuqovw From: "Bound, Jim" To: "Robert Elz" Cc: "JINMEI Tatuya / ????" , "Margaret Wasserman" , "Brian Haberman" , X-OriginalArrivalTime: 19 Jun 2002 21:41:13.0756 (UTC) FILETIME=[08C9FDC0:01C217DA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5JLfBk7005059 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert, Site identification requires a site-zone-id to differenentiate fec0::1 from fec0::1 on a node with two sites. Under the site-identifier for the two sites are local links that also require zone ids for the link-locals. So the structure for an interface requires site-zone-id and then within each site link-local-zone ids. What I am saying is the site-id abstraction now requires another level of indirection when determining which interface the packet should be sent for interface data structures, routing data structures, and tansport data structures. It also requires more intelligence for SCTP as example that uses addresses as failover in this case. For site-local just the addresses is not enough but also the site-id now. Rather than debate site-local existence maybe it would be good to just get consensus on their complexity and what they mean regarding added work for implementations? But as someone pointed out to me privately I don't want people printing on my site printer from the Internet. So is it the job of the address type or the filters in IPv6 routing or firewalls to prevent that? Hope this helps with my initial issue. /jim > -----Original Message----- > From: Robert Elz [mailto:kre@munnari.OZ.AU] > Sent: Monday, June 17, 2002 12:43 PM > To: Bound, Jim > Cc: JINMEI Tatuya / ????; Margaret Wasserman; Brian Haberman; > ipng@sunroof.eng.sun.com > Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols > > > Date: Mon, 17 Jun 2002 10:19:13 -0400 > From: "Bound, Jim" > Message-ID: > <9C422444DE99BC46B3AD3C6EAFC9711B022D2C24@tayexc13.americas.cp > qcorp.net> > > | Link-Locals do not have the same properties to implement > as site-locals. > > They have almost the same properties (the internals of > routing protocols > excepted, as LL's don't go there - obviously, as they're not > routed anywhere), > > Apart from inside routing, a user of SL's has to specify the > scope, just as > does a user of LL's, and the forwarding engine has to make > sure that the > packet is sent only to a link in the appropriate scope, in both cases. > > Routers (routing protocols omitted for now) need to check > that the scope > of the outgoing interface is the same as that of the incoming one, for > both link locals and site locals - for link locals that can be reduced > to checking that the interface is the same (or I thought it could, but > apparently we have multi-interface links now, which makes > LL's even closer > to SL's in this area) but it doesn't have to be (and probably can't if > these multi-interface link things exist, whatever they really are). > > | Site causes logic beyond the link and causes more errors > for TCP, SCTP, > | and Anycast. > > What errors? Please Jim - don't just claim something, if there's a > problem, actually give the details, then it will be possible > for others > to either see your point, or show you where you're mistaken. > > But "causes more errors" is just the same as "this program is broken" > without any more detail - it is a totally useless comment. > > 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 Jun 19 15:48:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5JMmjk7005165; Wed, 19 Jun 2002 15:48:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5JMmjCQ005164; Wed, 19 Jun 2002 15:48:45 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5JMmgk7005157 for ; Wed, 19 Jun 2002 15:48:42 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA10120 for ; Wed, 19 Jun 2002 15:48:47 -0700 (PDT) Received: from alicia.nttmcl.com (alicia.nttmcl.com [216.69.69.10]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA00697 for ; Wed, 19 Jun 2002 16:48:46 -0600 (MDT) Received: (from jj@localhost) by alicia.nttmcl.com (8.10.1/8.10.1) id g5JMmhY05598; Wed, 19 Jun 2002 15:48:43 -0700 (PDT) Date: Wed, 19 Jun 2002 15:48:42 -0700 From: JJ Behrens To: Michel Py , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols Message-ID: <20020619154842.A585@alicia.nttmcl.com> References: <2B81403386729140A3A899A8B39B046405E12B@server2000.arneill-py.sacramento.ca.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <2B81403386729140A3A899A8B39B046405E12B@server2000.arneill-py.sacramento.ca.us>; from michel@arneill-py.sacramento.ca.us on Tue, Jun 18, 2002 at 08:16:17PM -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > JJ Behrens wrote: > > [Michel's point about SLs being somehow more secure] > > Your point is valid. Now it remains to be argued whether the > > difficulties associated with SL's are worth this small increase > > in security. Personally, I feel that this small increase in > > security is not worth the extra work. However, it remains to be > > seen whether we can solve the renumbering problem (i.e. the use > > of SL's for longterm stable IP's). > > A matter of appreciation, indeed. But there is some demand for SLs. > > So, what about comparing the extra work required to make SLs work to the > work required to suppress them, plus the work required to deal with > whatever (possibly more crappy) will replace them? It seems to me that the amount of work to make SL's not globally routable is fairly small. Afterall, there's already code to keep link locals from leaving the link. As far as replacing the benefits of SL's with something else: minor security improvement: this improvement is not worth bending over backwards for. very long-term connections: using SL's for very long-term connections doesn't provide long-term connections across the net. If SL's are so hard to deal with, perhaps we should just solve the long-term connection problem directly (perhaps with a new fourth layer protocol). Of course, I am young, and I have not caught up with all of the email, so feel free to ignore me :) Best Regards, -jj -- Users of C++ should consider hanging themselves rather than shooting their legs off--it's best not to use C++ simply as a better C. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 19 16:00:07 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5JN07k7005193; Wed, 19 Jun 2002 16:00:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5JN07ns005192; Wed, 19 Jun 2002 16:00:07 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5JN03k7005185 for ; Wed, 19 Jun 2002 16:00:03 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA14749 for ; Wed, 19 Jun 2002 16:00:08 -0700 (PDT) Received: from roll.mentat.com (mentat.com [192.88.122.129]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA19930 for ; Wed, 19 Jun 2002 17:00:07 -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 PAA05269; Wed, 19 Jun 2002 15:52:38 -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 PAA27782; Wed, 19 Jun 2002 15:52:38 -0700 (PDT) Received: (from tim@localhost) by feller.mentat.com (8.9.3+Sun/8.9.3) id PAA07984; Wed, 19 Jun 2002 15:56:56 -0700 (PDT) Date: Wed, 19 Jun 2002 15:56:56 -0700 (PDT) From: Tim Hartrick Message-Id: <200206192256.PAA07984@feller.mentat.com> To: kre@munnari.oz.au, Jim.Bound@hp.com Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols Cc: ipng@sunroof.eng.sun.com, jinmei@isl.rdc.toshiba.co.jp, mrw@windriver.com, bkhabs@nc.rr.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, > > Site identification requires a site-zone-id to differenentiate fec0::1 from fec0::1 on a node with two sites. Under the site-identifier for the two sites are local links that also require zone ids for the link-locals. > > So the structure for an interface requires site-zone-id and then within each site link-local-zone ids. > > What I am saying is the site-id abstraction now requires another level of indirection when determining which interface the packet should be sent for interface data structures, routing data structures, and tansport data structures. It also requires more intelligence for SCTP as example that uses addresses as failover in this case. For site-local just the addresses is not enough but also the site-id now. > > Rather than debate site-local existence maybe it would be good to just get consensus on their complexity and what they mean regarding added work for implementations? > I think that this is the right direction to go and I agree with Jim that the vast majority of the implementation complexity associated with limited scope addresses is associated with nodes that are connected to two or more zones. Given this, I don't see any reason that individual implementors can't decide for themselves, based on customer demand, whether or not their implementation needs to be able to support being connected to two or more zones. This, in my opinion, goes for link-local, site-local or any future limited scope unicast address that can be imagined. The existence of site-local addresses in the address architecture doesn't imply a requirement that every implementation be able to act as a site-border router or implement "two-faced" DNS or implement various unspecified routing protocol extentions to implement site-border router functionality. All of these features are admittedly complex to specify and implement, but not impossible given appropriate motivation. The good news is that not every implementation needs to have all these features from day one. Most implementations will never need any of them. There are a minimum set of requirements that any node will have to implement in order to communicate using site-local addresses. As far as I can tell that minimum set is pretty well specified in the Draves destination/source address selection draft. Any specification and implementation beyond that minimum set should be driven by customer demand. What I would like to see come out of this long discussion is simply some text in the in progress "Node Requirements" document that specifies how much of the scoped address architecture MUST be implemented and that that text would say that the rules specified in Draves' draft are the only MUST implement portion of the architecture. There should be no requirement that a node be able to be part of more than one zone. The above should solve. in the near term, the fears of implementation complexity. The "architectural" arguments against site-local/private addresses can't be countered except to say, as many others have, that customers will use "private" address space. It is going to happen. Something like RFC 1918 will come into existence. We can specify the bit pattern now or specify it later, but it will be specified. It is indeed scary that this might lead to IPv6 NAT but IPv4 NAT happened without any RFCs or architectural blessing. Removing site-local addresses from the address architecture will do exactly nothing to stop IPv6 NAT if the reasons that IPv4 NAT exists persist; address scarcity and cost, and questionable security capabilities. The first reason is solved by IPv6 as long as the providers do the right thing. The second part is mostly FUD which can be countered with some BCP or informational RFCs, and secure products. 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 Wed Jun 19 16:25:06 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5JNP5k7005324; Wed, 19 Jun 2002 16:25:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5JNP5Aq005323; Wed, 19 Jun 2002 16:25:05 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5JNP2k7005316 for ; Wed, 19 Jun 2002 16:25:02 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA23087 for ; Wed, 19 Jun 2002 16:25:08 -0700 (PDT) Received: from drugs.dv.isc.org (drugs.dv.isc.org [130.155.191.236]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA20105 for ; Wed, 19 Jun 2002 17:22:58 -0600 (MDT) Received: from drugs.dv.isc.org (localhost.dv.isc.org [127.0.0.1]) by drugs.dv.isc.org (8.12.3/8.12.3) with ESMTP id g5JNMpm0016344; Thu, 20 Jun 2002 09:22:51 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200206192322.g5JNMpm0016344@drugs.dv.isc.org> To: "Bernie Volz (EUD)" Cc: ipng@sunroof.eng.sun.com From: Mark.Andrews@isc.org Subject: Re: Multicast address recommended hop counts? In-reply-to: Your message of "Wed, 19 Jun 2002 15:25:11 EST." <66F66129A77AD411B76200508B65AC69B4D620@EAMBUNT705> Date: Thu, 20 Jun 2002 09:22:51 +1000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Is there any document (RFC or draft) that gives any guidance on setting > the hop counts for multicast addresses? > > The hop limit is 1 by default (based on the RFC 2553) which is fine for > link-local multicasts, but what about site local or other scoped > multicast addresses? > > For example, RFC 2373 lists the following scope values for multicast > groups: > 0 reserved > 1 node-local scope > 2 link-local scope > 3 (unassigned) > 4 (unassigned) > 5 site-local scope > 6 (unassigned) > 7 (unassigned) > 8 organization-local scope > 9 (unassigned) > A (unassigned) > B (unassigned) > C (unassigned) > D (unassigned) > E global scope > F reserved > > Is there a corresponding recommended hop count for each of the > assigned scopes: > 1 node-local scope Hops = 1 > 2 link-local scope Hops = 1 > 5 site-local scope Hops = ? (8, 16, 32?) > 8 organization-local scope Hops = ? (8, 16, 32?) > E global scope Hops = default IP TTL (64)? I wouldn't bother with additional knobs. Just use the same default TTL for site/organization/global. Mark -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@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 Wed Jun 19 16:42:18 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5JNgIk7005431; Wed, 19 Jun 2002 16:42:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5JNgIP1005430; Wed, 19 Jun 2002 16:42:18 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5JNgDk7005420 for ; Wed, 19 Jun 2002 16:42:14 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA00286 for ; Wed, 19 Jun 2002 16:42:19 -0700 (PDT) Received: from esunmail ([129.147.58.121]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA09200 for ; Wed, 19 Jun 2002 17:42:19 -0600 (MDT) Received: from xpa-fe2 (esunmail-ge0 [129.147.58.121]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 0.3 (built May 13 2002)) with ESMTP id <0GXZ00ERV8IHIF@edgemail1.Central.Sun.COM> for ipng@sunroof.eng.sun.com; Wed, 19 Jun 2002 17:42:18 -0600 (MDT) Received: from sun.com ([129.146.85.69]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 0.2 (built Apr 26 2002)) with ESMTPSA id <0GXZ00FQI8IGY1@mail.sun.net> for ipng@sunroof.eng.sun.com; Wed, 19 Jun 2002 17:42:17 -0600 (MDT) Date: Wed, 19 Jun 2002 16:41:35 -0700 From: Alain Durand Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols To: Tim Hartrick Cc: ipng@sunroof.eng.sun.com Message-id: <3D1116AF.CBAB4F87@sun.com> MIME-version: 1.0 X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) Content-type: text/plain; charset=iso-8859-15 Content-transfer-encoding: 7BIT X-Accept-Language: en References: <200206192256.PAA07984@feller.mentat.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tim Hartrick wrote: > What I would like to see come out of this long discussion is simply some text > in the in progress "Node Requirements" document that specifies how much of the > scoped address architecture MUST be implemented and that that text would say > that the rules specified in Draves' draft are the only MUST implement portion > of the architecture. There should be no requirement that a node be able to be > part of more than one zone. So this is a different suggestion than the one Margaret made this morning. We now have 5 alternatives on the table: 1 - Site local scope is enforced in the kernel by Addres selection rule when available and applications are build to work in a multi-sited environment. 2 - Site local scope is enforced in the kernel by Addres selection rule when available but applications can be limited to only support one site. 3- Site local scope can be requested by specific applications when available. 4- Site local are reserved for sites that are not connected to the Internet. 5- Site local are taken out of the address architecture. - 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 Jun 19 18:41:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5K1f7k7005969; Wed, 19 Jun 2002 18:41:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5K1f7aJ005968; Wed, 19 Jun 2002 18:41:07 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5K1f4k7005961 for ; Wed, 19 Jun 2002 18:41:04 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA05922 for ; Wed, 19 Jun 2002 18:41:09 -0700 (PDT) Received: from mail.icu.ac.kr (mail.icu.ac.kr [210.107.128.19]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA02702 for ; Wed, 19 Jun 2002 18:41:08 -0700 (PDT) Received: from gmlee (v33-146.icu.ac.kr [210.107.133.146]) by mail.icu.ac.kr (8.11.6/8.11.6) with SMTP id g5K1hfr29751 for ; Thu, 20 Jun 2002 10:43:41 +0900 (KST) Message-ID: <016901c217fb$737039c0$92856bd2@gmlee> From: "Gyu Myoung Lee" To: Subject: Comments on Automatic Prefix Delegation Protocol(APDP) draft Date: Thu, 20 Jun 2002 10:40:25 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by sunroof.eng.sun.com id g5K1f4k7005962 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, folks I have followed up APDP draft and our members are implementing this protocol. In this draft, I have the following questions. 1) For the Delegator Query procedure, there was scope fied (S bit) for representing site-local scope or global scope in previous version. But this field was excluded in the new prefix option. I think the prefix option must include this field. 2) this draft defines only one prefix option. So there are some problems that each field has a different meaning according to message type (prefix request message and prefix delegation message). The explaination of message field is not enough. How about seperate in two cases? otherwise, I think the new prefix option (ex, prefix request option) is needed. Do you have any ideas? 3) In delegator query procedure, the prefix request message doesn't contain the prefix option. But I think a delegator query code MAY contain a prefix option and the Requestor can select the Delegator which is configured to provide the specified prefix length. I expect to include these ideas in the updated version. Thank you for reading Regards Gyu Myoung Lee -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 19 19:07:53 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5K27qk7006113; Wed, 19 Jun 2002 19:07:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5K27qTZ006112; Wed, 19 Jun 2002 19:07:52 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5K27mk7006105 for ; Wed, 19 Jun 2002 19:07:48 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA17708 for ; Wed, 19 Jun 2002 19:07:53 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA25651 for ; Wed, 19 Jun 2002 19:07:53 -0700 (PDT) Received: from kenawang ([147.11.233.2]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id TAA15807; Wed, 19 Jun 2002 19:06:10 -0700 (PDT) Message-Id: <4.2.2.20020619220021.02234410@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 19 Jun 2002 22:03:29 -0400 To: Tim Hartrick From: Margaret Wasserman Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols Cc: kre@munnari.oz.au, Jim.Bound@hp.com, ipng@sunroof.eng.sun.com, jinmei@isl.rdc.toshiba.co.jp, bkhabs@nc.rr.com In-Reply-To: <200206192256.PAA07984@feller.mentat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Tim, Excellent points. I particularly agree with the following paragraph: >What I would like to see come out of this long discussion is simply some text >in the in progress "Node Requirements" document that specifies how much of the >scoped address architecture MUST be implemented and that that text would say >that the rules specified in Draves' draft are the only MUST implement portion >of the architecture. There should be no requirement that a node be able to be >part of more than one zone. I think that this would be an excellent way to limit the impact of scoped addressing on implementations that are not interested in existing at site borders. Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 19 20:01:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5K31jk7006242; Wed, 19 Jun 2002 20:01:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5K31jjw006241; Wed, 19 Jun 2002 20:01:45 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5K31fk7006234 for ; Wed, 19 Jun 2002 20:01:41 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA27839 for ; Wed, 19 Jun 2002 20:01:47 -0700 (PDT) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA18960 for ; Wed, 19 Jun 2002 21:03:58 -0600 (MDT) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id A53CF8FBF; Wed, 19 Jun 2002 23:01:45 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 19 Jun 2002 23:01:45 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols Date: Wed, 19 Jun 2002 23:01:44 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B8B1B@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Fwd: IPv6 Scoped Addresses and Routing Protocols Thread-Index: AcIX5REzanZ63Ok/Q+i3Fz4Azo8v5AAIZNRw From: "Bound, Jim" To: "Tim Hartrick" , Cc: , , , X-OriginalArrivalTime: 20 Jun 2002 03:01:45.0544 (UTC) FILETIME=[CFD3F480:01C21806] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5K31gk7006235 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I agree with Tim for the record. If we do this below that at least is a way forward. If we are to have them I would like to know what the MUSTs are too and also I agree the min is in rich draves src addr select. /jim > -----Original Message----- > From: Tim Hartrick [mailto:tim@mentat.com] > Sent: Wednesday, June 19, 2002 6:57 PM > To: kre@munnari.oz.au; Bound, Jim > Cc: ipng@sunroof.eng.sun.com; jinmei@isl.rdc.toshiba.co.jp; > mrw@windriver.com; bkhabs@nc.rr.com > Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols > > > > > Jim, > > > > > Site identification requires a site-zone-id to > differenentiate fec0::1 from fec0::1 on a node with two > sites. Under the site-identifier for the two sites are > local links that also require zone ids for the link-locals. > > > > So the structure for an interface requires site-zone-id and > then within each site link-local-zone ids. > > > > What I am saying is the site-id abstraction now requires > another level of indirection when determining which interface > the packet should be sent for interface data structures, > routing data structures, and tansport data structures. It > also requires more intelligence for SCTP as example that uses > addresses as failover in this case. For site-local just the > addresses is not enough but also the site-id now. > > > > Rather than debate site-local existence maybe it would be > good to just get consensus on their complexity and what they > mean regarding added work for implementations? > > > > I think that this is the right direction to go and I agree > with Jim that the > vast majority of the implementation complexity associated with limited > scope addresses is associated with nodes that are connected > to two or more > zones. Given this, I don't see any reason that individual > implementors can't > decide for themselves, based on customer demand, whether or not their > implementation needs to be able to support being connected to > two or more zones. > This, in my opinion, goes for link-local, site-local or any > future limited scope > unicast address that can be imagined. > > The existence of site-local addresses in the address > architecture doesn't > imply a requirement that every implementation be able to act > as a site-border > router or implement "two-faced" DNS or implement various > unspecified routing > protocol extentions to implement site-border router > functionality. All of > these features are admittedly complex to specify and > implement, but not > impossible given appropriate motivation. The good news is > that not every > implementation needs to have all these features from day one. Most > implementations will never need any of them. > > There are a minimum set of requirements that any node will > have to implement > in order to communicate using site-local addresses. As far > as I can tell that > minimum set is pretty well specified in the Draves > destination/source address > selection draft. Any specification and implementation beyond > that minimum > set should be driven by customer demand. > > What I would like to see come out of this long discussion is > simply some text > in the in progress "Node Requirements" document that > specifies how much of the > scoped address architecture MUST be implemented and that that > text would say > that the rules specified in Draves' draft are the only MUST > implement portion > of the architecture. There should be no requirement that a > node be able to be > part of more than one zone. > > The above should solve. in the near term, the fears of implementation > complexity. The "architectural" arguments against > site-local/private addresses > can't be countered except to say, as many others have, that > customers will use > "private" address space. It is going to happen. Something > like RFC 1918 will > come into existence. We can specify the bit pattern now or > specify it later, > but it will be specified. It is indeed scary that this might > lead to IPv6 NAT > but IPv4 NAT happened without any RFCs or architectural > blessing. Removing > site-local addresses from the address architecture will do > exactly nothing to > stop IPv6 NAT if the reasons that IPv4 NAT exists persist; > address scarcity > and cost, and questionable security capabilities. The first > reason is solved > by IPv6 as long as the providers do the right thing. The > second part is mostly > FUD which can be countered with some BCP or informational > RFCs, and secure > products. > > > > 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 Thu Jun 20 03:09:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5KA9nk7007032; Thu, 20 Jun 2002 03:09:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5KA9n7U007031; Thu, 20 Jun 2002 03:09:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5KA9jk7007024 for ; Thu, 20 Jun 2002 03:09:45 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA06887 for ; Thu, 20 Jun 2002 03:09:48 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA20407 for ; Thu, 20 Jun 2002 03:09:47 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 8C83B4B24; Thu, 20 Jun 2002 19:09:40 +0900 (JST) To: Erik Nordmark Cc: ettikan.kandasamy.karuppiah@intel.com, ipng@sunroof.eng.sun.com In-reply-to: Erik.Nordmark's message of Wed, 05 Jun 2002 18:45:49 +0200. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Comments on draft-ietf-ipngwg-ipv6-anycast-analysis From: itojun@iijlab.net Date: Thu, 20 Jun 2002 19:09:40 +0900 Message-Id: <20020620100940.8C83B4B24@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk i'm trying to catch up with my pile of email... >I completely fail to see what section 1.1 is trying to say >other than "there are different forms of anycast". i'll try to rework on it. >It assigns the tag "BGP" anycast to both the Hardie and Ohta-san document, >even though only the latter is an interdomain anycast scheme. >And contrasting this against RFC 1546 seems odd, since RFC 1546 doesn't >say anything whether it limits itself to intradomain anycast or not. as far as I remember from the past presentations, Hardie draft did propose interdomain anycast scheme. the diagram in appendix A look like intradomain, however, section 1.4 and 1.5 does not have any restriction on intra/interdomain. the diagram I saw at dnsop meeting was interdomain (single prefix advertised with a single AS #, from multiple different location). >I think (but I haven't verified) that (many) tftp implementations verify >the source address. Perhaps I'm confused and it is only the server that does >this and not the client. But using TFTP as an example of how secure protocols >should be done is not a very strong argument to say the least. many of tftp implementation do check address pairs, however, the specification clearly indicates that the address should not be checked. >> distribution of servers is worldwide. BGP anycast is being used for >> specific upper-layer protocols only, like DNS and HTTP. There is no >Where is it being used for HTTP? The documents you cite talk about DNS >and UDP exclusively. webserver for past olympic games. i don't have any citable document on it. 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 Thu Jun 20 04:00:01 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5KB00k7007341; Thu, 20 Jun 2002 04:00:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5KB00Qu007340; Thu, 20 Jun 2002 04:00:00 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5KAxsk7007330 for ; Thu, 20 Jun 2002 03:59:54 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA18887 for ; Thu, 20 Jun 2002 03:59:58 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA08910 for ; Thu, 20 Jun 2002 03:59:58 -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 GAA24069; Thu, 20 Jun 2002 06:59:16 -0400 (EDT) Message-Id: <200206201059.GAA24069@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-ipv6-node-requirements-00.txt Date: Thu, 20 Jun 2002 06:59:16 -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 IP Version 6 Working Group Working Group of the IETF. Title : IPv6 Node Requirements Author(s) : J. Loughney Filename : draft-ietf-ipv6-node-requirements-00.txt Pages : 23 Date : 19-Jun-02 This document defines requirements for IPv6 nodes. It is expected that IPv6 will be deployed in a wide range of devices and situations. Specifying the requirements for IPv6 nodes allows IPv6 to function well and interoperate in a large number of situations and deployments. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-node-requirements-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipv6-node-requirements-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-ipv6-node-requirements-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: <20020619122707.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-node-requirements-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-node-requirements-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020619122707.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 20 03:59:59 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5KAxxk7007338; Thu, 20 Jun 2002 03:59:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5KAxxWd007337; Thu, 20 Jun 2002 03:59:59 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5KAxqk7007323 for ; Thu, 20 Jun 2002 03:59:53 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA01303 for ; Thu, 20 Jun 2002 03:59:56 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA06318 for ; Thu, 20 Jun 2002 04:59: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 GAA24049; Thu, 20 Jun 2002 06:59:11 -0400 (EDT) Message-Id: <200206201059.GAA24049@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-ipv6-default-addr-select-08.txt Date: Thu, 20 Jun 2002 06:59:11 -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 IP Version 6 Working Group Working Group of the IETF. Title : Default Address Selection for IPv6 Author(s) : R. Draves Filename : draft-ietf-ipv6-default-addr-select-08.txt Pages : 25 Date : 19-Jun-02 This document describes two algorithms, for source address selection and for destination address selection. The algorithms specify default behavior for all IPv6 implementations. They do not override choices made by applications or upper-layer protocols, nor do they preclude the development of more advanced mechanisms for address selection. The two algorithms share a common framework, including an optional mechanism for allowing administrators to provide policy that can override the default behavior. In dual stack implementations, the framework allows the destination address selection algorithm to consider both IPv4 and IPv6 addresses - depending on the available source addresses, the algorithm might prefer IPv6 addresses over IPv4 addresses, or vice-versa. All IPv6 nodes, including both hosts and routers, must implement default address selection as defined in this specification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-default-addr-select-08.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipv6-default-addr-select-08.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-ipv6-default-addr-select-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020619122656.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-default-addr-select-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-default-addr-select-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020619122656.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 20 04:25:31 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5KBPUk7007451; Thu, 20 Jun 2002 04:25:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5KBPUTH007450; Thu, 20 Jun 2002 04:25:30 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5KBPRk7007443 for ; Thu, 20 Jun 2002 04:25:27 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA06036 for ; Thu, 20 Jun 2002 04:25:31 -0700 (PDT) From: john.loughney@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA18570 for ; Thu, 20 Jun 2002 04:25:30 -0700 (PDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g5KBPvi06482 for ; Thu, 20 Jun 2002 14:25:57 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 20 Jun 2002 14:25:29 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 20 Jun 2002 14:25:29 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: I-D ACTION:draft-ietf-ipv6-node-requirements-00.txt Date: Thu, 20 Jun 2002 14:25:27 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC654B5@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-ietf-ipv6-node-requirements-00.txt Thread-Index: AcIYS0VGV7Pdd7bwTeaoImxntWfA1AAAZp5Q To: X-OriginalArrivalTime: 20 Jun 2002 11:25:29.0030 (UTC) FILETIME=[2E6DEE60:01C2184D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5KBPSk7007444 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all, This draft has now be announced. It is the product of a design team formed in Minneapolis. I will say that the current draft needs work, there are a number of open issues, some of which can only be addressed through the WG process. I'm firstly interested in comments on the format & scope of the document. Is the approach we took reasonable? thanks to all involved in the design team. best regards, john > -----Original Message----- > From: ext Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: 20 June, 2002 13:59 > Cc: ipng@sunroof.eng.sun.com > Subject: I-D ACTION:draft-ietf-ipv6-node-requirements-00.txt > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > This draft is a work item of the IP Version 6 Working Group > Working Group of the IETF. > > Title : IPv6 Node Requirements > Author(s) : J. Loughney > Filename : draft-ietf-ipv6-node-requirements-00.txt > Pages : 23 > Date : 19-Jun-02 > > This document defines requirements for IPv6 nodes. It is expected > that IPv6 will be deployed in a wide range of devices and situations. > Specifying the requirements for IPv6 nodes allows IPv6 to function > well and interoperate in a large number of situations and > deployments. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipv6-node-requi > rements-00.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body > of the message. > > Internet-Drafts are also available by anonymous FTP. Login > with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-ipv6-node-requirements-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-ipv6-node-requirements-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. > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 20 06:24:26 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5KDOPk7007974; Thu, 20 Jun 2002 06:24:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5KDOPCl007973; Thu, 20 Jun 2002 06:24:25 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5KDOLk7007966 for ; Thu, 20 Jun 2002 06:24:22 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g5KDOKb09584; Thu, 20 Jun 2002 15:24:20 +0200 (MEST) Date: Thu, 20 Jun 2002 15:23:07 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: IESG comments on draft-ietf-ipngwg-default-addr-select-06.txt To: Tony Hain Cc: Keith Moore , Alberto Escudero-Pascual , "Bound, Jim" , Erik Nordmark , Thomas Narten , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Any app that doesn't need a forward or reverse record in DNS will work > with a private address, why do they need a special API. What you are Nope. Temporary addresses will not be useful for more than 7 days (using the default timers). Thus if I e.g. want a telnet session to stay up for many weeks the telnet application needs a non-temporary address indepedent of any DNS related stuff. 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 Jun 20 10:42:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5KHgmk7009597; Thu, 20 Jun 2002 10:42:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5KHgmY9009596; Thu, 20 Jun 2002 10:42:48 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5KHgjk7009589 for ; Thu, 20 Jun 2002 10:42:45 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA08660 for ; Thu, 20 Jun 2002 10:42:49 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA28181 for ; Thu, 20 Jun 2002 11:42:48 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA24386 for ; Thu, 20 Jun 2002 10:42:48 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g5KHglg22664 for ; Thu, 20 Jun 2002 10:42:47 -0700 X-mProtect: <200206201742> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (4.22.78.78, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpd3MeqvZ; Thu, 20 Jun 2002 10:42:44 PDT Message-Id: <4.3.2.7.2.20020620103849.025cd5c0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 20 Jun 2002 10:42:27 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: Reminder: Internet-Draft Cutoff Dates for Yokohama, Japan Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Reminder of the internet draft cutoff dates. Please note that the cutoff time on each date is 0900 US-EDT. The cutoff time for the previous meetings was 1700 US-EDT. Bob >To: IETF-Announce: ; >From: Internet-Drafts Administrator >Subject: Internet-Draft Cutoff Dates for Yokohama, Japan >Date: Fri, 14 Jun 2002 11:22:13 -0400 >Sender: nsyracus@cnri.reston.va.us > > >NOTE: There are two (2) Internet-Draft Cutoff dates > >June 24th: Cutoff for Initial Submissions (new documents) > >All initial submissions(-00) must be submitted by Monday, June 24th, at >09:00 US-EDT (eastern daylight time). Initial submissions received >after this time will NOT be made available in the Internet-Drafts >directory, and will have to be resubmitted. > > > >As before, all initial submissions (-00.txt) with a filename beginning >with a draft-ietf MUST be approved by the appropriate WG Chair prior to >processing and announcing. WG Chair approval must be received by >Monday, June 24th. > > Please do NOT wait until the last minute to submit. > >Be advised: NO placeholders. Updates to initial submissions received > the week of June 24th will NOT be accepted. > >July 1st: FINAL Internet-Draft Cutoff > >All revised Internet-Draft submissions must be submitted by Monday, >July 1st, 2002 at 09:00 US-EDT (eastern daylight time). >Internet-Drafts received after this time >will NOT be announced NOR made available in the Internet-Drafts >Directories. > >We will begin accepting Internet-Draft submissions the week of the >meeting, though announcements will NOT be sent until the IETF meeting >is over. > >Thank you for your understanding and cooperation. Please do not hesitate >to contact us if you have any questions or concenrs. > >FYI: These and other significant dates can be found at > http://www.ietf.org/meetings/cutoff_dates_54.html -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 20 12:11:54 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5KJBrk7010538; Thu, 20 Jun 2002 12:11:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5KJBrGn010537; Thu, 20 Jun 2002 12:11:53 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5KJBok7010530 for ; Thu, 20 Jun 2002 12:11:50 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA18613 for ; Thu, 20 Jun 2002 12:11:55 -0700 (PDT) Received: from [208.236.204.65] (gateus.nmss.com [208.236.204.65]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id NAA23030 for ; Thu, 20 Jun 2002 13:11:54 -0600 (MDT) To: ipng@sunroof.eng.sun.com Received: from [10.1.3.12] by [208.236.204.65] via smtpd (for [192.18.98.31]) with SMTP; 20 Jun 2002 14:07:47 UT Subject: Re: I-D ACTION:draft-ietf-ipv6-node-requirements-00.txt X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Adam Machalek" Date: Thu, 20 Jun 2002 14:11:30 -0500 X-MIMETrack: Serialize by Router on NAMASMTP02/NMS Communications(Release 5.0.10 |March 22, 2002) at 06/20/2002 03:08:05 PM, Serialize complete at 06/20/2002 03:08:05 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 00696B5E86256BDE_=" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multipart message in MIME format. --=_alternative 00696B5E86256BDE_= Content-Type: text/plain; charset="us-ascii" My first comment is structural in nature. Six months ago when we started our IPv6 implementation I spent several weeks wading through all the IPv6 and NGTrans RFCs and drafts in order to catagorize them into what this draft terms "unconditional manditory", "conditional mandatory", and "unconditionally optional". From there we were able to focus our effort. While it is clearly defined in the text of the draft, I would have appreciated an Appendix with nothing more then a list of the relevent RFCs/Drafts grouped into those 3 catagories. Adam Machalek --=_alternative 00696B5E86256BDE_= Content-Type: text/html; charset="us-ascii"
My first comment is structural in nature.  Six months ago when we started our IPv6 implementation I spent several weeks wading through all the IPv6 and NGTrans RFCs and drafts in order to catagorize them into what this draft terms "unconditional manditory", "conditional mandatory", and "unconditionally optional".  From there we were able to focus our effort.  

While it is clearly defined in the text of the draft, I would have appreciated an Appendix with nothing more then a list of the relevent RFCs/Drafts grouped into those 3 catagories.  

Adam Machalek --=_alternative 00696B5E86256BDE_=-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 20 15:14:18 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5KMEIk7011043; Thu, 20 Jun 2002 15:14:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5KMEHGf011042; Thu, 20 Jun 2002 15:14:17 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5KMEGk7011034 for ; Thu, 20 Jun 2002 15:14:16 -0700 (PDT) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g5KME7oR011988 for ; Thu, 20 Jun 2002 15:14:07 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g5KME6Eg011987 for ipng@sunroof.eng.sun.com; Thu, 20 Jun 2002 15:14:06 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5KEb5k7008315 for ; Thu, 20 Jun 2002 07:37:05 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA26308 for ; Thu, 20 Jun 2002 07:37:07 -0700 (PDT) Received: from mail.alcatel.be (alc250.alcatel.be [195.207.101.250]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA19353 for ; Thu, 20 Jun 2002 07:37:05 -0700 (PDT) Received: from bemail04.net.alcatel.be (relay3 [127.0.0.1]) by mail.alcatel.be (8.11.0/8.11.4) with ESMTP id g5KEXbO27988; Thu, 20 Jun 2002 16:33:37 +0200 Received: from alcatel.be ([138.203.67.106]) by bemail04.net.alcatel.be (Lotus Domino Release 5.0.8) with ESMTP id 2002062016364705:5514 ; Thu, 20 Jun 2002 16:36:47 +0200 Message-ID: <3D11E87D.66F00A56@alcatel.be> Date: Thu, 20 Jun 2002 16:36:46 +0200 From: jeremy.de_clercq@alcatel.be X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Tissa Senevirathne Cc: pekkas@netcore.fi, ipng@sunroof.eng.sun.com, ppvpn@ppvpn.francetelecom.com, Francois Le Faucheur , Dirk OOMS , Gerard GASTAUD , stuart.prevost@bt.com Subject: Re: ID on BGP extensions to Tag IPv6 routes that has IPv4 tunnels References: X-MIMETrack: Itemize by SMTP Server on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 06/20/2002 16:36:47, Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 06/20/2002 16:36:49, Serialize complete at 06/20/2002 16:36:49 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, thanks Pekka for identifying this. as far as I understand, the problem both drafts are trying solve is to 'signal' the IPv4 address to use as the egress of the tunnel, when advertising IPv6 routes over an IPv4 backbone via BGP/TCP/IPv4. In order to avoid the "additional explicit configuration" mentioned in RFC2545 (section 4). RFC2545 says: " Thus, when using TCP over IPv4 as a transport for IPv6 reachability information, additional explicit configuration of the peer's network address is required. " * draft-tsenevir-ipv6-bgp-tun encodes this IPv4 address as a new sub-type from a BGP extended cummunities attribute. * draft-ietf-ngtrans-bgp-tunnel encodes this IPv4 address in the BGP NEXT_HOP field, in an IPv4-mapped IPv6 address. Tissa, [sidenote : should we discuss this on the ppvpn mailing list ? I don't think it's of specific interest to this community.] You're proposing to use an IPv4 address encoded in an extended BGP attribute as the tunnel endpoint ? this would mean that you don't use the BGP NEXT_HOP attribute any more ? Which address will the BGP NEXT_HOP contain ? What will it be used for ? How will BGP routers treat it when propagating messages ? Could you please explain for which router the following is a problem : " Key problem in hand is to distinguish between IPV6 routes that have native connectivity and IPv6 routes that do not have native connectivity. " or what's wrong with this reasoning: "if the NEXT_HOP is reachable via an IPv6 network (BGP/TCP/IPv6), use IPv6 forwarding; if the NEXT_HOP is reachable via an IPv4 network (BGP/TCP/IPv4), use tunneling." some more comments inline: > **ID: draft-tsenevir-ipv6-bgp-tun-00.txt** > > 1. Treat IPv4 tunneling as an attribute of the native IPv6 route is the fact that the IPv6 route is distributed over an IPv4 network not enough to know that normal forwarding is not going to work and that you'll need some tunneling ? > 2. Extended community attributes are presented as a generic way of > identifying specific properties of IPv6 routes or for that matter any route. > In other words it is an extension to BGP4+ The BGP NEXT_HOP attribute is the attribute to use to find the next hop address to use to forward traffic towards the announced destinations. > 3. Implementation vise it is easier to apply policies on attributes. > Actually the recommended method is to use attributes not more messages. I fail to see how this relates to policies. Which draft is introducing which additional messages ? Both drafts are using existing BGP messages. > 4. Methods in the ID Allows Ipv6 devices(routers) to select either a native > Ipv6 connection or a tunnel connection (eg: ipv4) to reach remote Ipv6 > cloude, based BGP policies. Who can make the selection ? the traffic-egress (BGP sender) or the traffic-ingress (BGP receiver)? Does this mean the network is IPv4 AND IPv6 capable ? If the answer is yes, why should you tunnel IPv6 traffic ? > > 5. In the ID we treat tunneling as reachability issue of the relay routers. > Thus decoupling, tunnel discovery from route policies - to simplify > implementation. I'm confused. The extended communities attribute contains the tunnel egress IPv4 address, AND will be used for some policy. So it couples tunnel discovery and route policies, no ? in draft-ietf-ngtrans-bgp-tunnel-04.txt, the BGP NEXT_HOP attribute is used to identify the next hop, any other attributes can be added for any other policy. > > **ID: draft-ietf-ngtrans-bgp-tunnel-04.txt** > > (the way I understand..) > > 1. it propose to use special NLRI to encode IPv4 address (section 4.1) There's no special NLRI. The draft uses IPv6 NLRI (with known AFI/SAFI), actually MP_REACH_NLRI as it's defined in MP-BGP, and an IPv4-mapped IPv6 address as NEXT HOP. > 2. in section 7.3 the ID explains that it does not need to use VPN specific > parts of 2547. in such case the methods can be simplified further, as > presented in the new ID. section 7.3 says that there are no VPN specific parts in draft-ietf-ngtrans-bgp-tunnel. Please explain the 'further simplification' of your proposal. why is using a new attribute simpler than using the next hop attribute ? > > Conclusion: > > The methods presented in ID draft-tsenevir-ipv6-bgp-tun-00.txt is simpler, > scalable and easy to implement. NOTE: Tunnel between relay routers is a > reachability issue between them and it is better that we do not complicate > our IPv6 routes with that "simpler, scalable and easy to implement". Please convince us. thanks, Jeremy. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 20 16:22:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5KNMNk7011518; Thu, 20 Jun 2002 16:22:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5KNMNU3011517; Thu, 20 Jun 2002 16:22:23 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5KNMKk7011510 for ; Thu, 20 Jun 2002 16:22:20 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA10400 for ; Thu, 20 Jun 2002 16:22:25 -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 ESMTP id RAA19702 for ; Thu, 20 Jun 2002 17:22:25 -0600 (MDT) Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 20 Jun 2002 16:22:24 -0700 Received: from 157.54.8.155 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 20 Jun 2002 16:22:24 -0700 Received: from red-msg-06.redmond.corp.microsoft.com ([157.54.12.71]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 20 Jun 2002 16:22:24 -0700 x-mimeole: Produced By Microsoft Exchange V6.0.6177.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: I-D ACTION:draft-ietf-ipv6-default-addr-select-08.txt Date: Thu, 20 Jun 2002 16:22:26 -0700 Message-ID: <7695E2F6903F7A41961F8CF888D87EA8063CED6A@red-msg-06.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-ietf-ipv6-default-addr-select-08.txt Thread-Index: AcIYV3TBBxnsc9V6RGKYeCeBeHcP5gATT+VQ From: "Richard Draves" To: X-OriginalArrivalTime: 20 Jun 2002 23:22:24.0676 (UTC) FILETIME=[55C09E40:01C218B1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5KNMKk7011511 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This revision primarily has editorial changes & clarifications in response to IESG comments. There are also two substantive changes that require WG review: 1. I added definitions and requirements for IPv4-mapped and IPv4-translatable addresses, in support of SIIT. The key paragraph is On IPv6-only nodes that support SIIT [13, especially section 5], if the destination address is an IPv4-mapped address then the candidate set MUST contain only IPv4-translatable addresses. If the destination address is not an IPv4-mapped address, then the candidate set MUST NOT contain IPv4-translatable addresses. I believe this change has already has WG consensus, based on discussion on the list late last year and at Salt Lake City. I just forgot to incorporate it earlier. 2. I changed the requirement for an API to control temporary vs public address usage, from "may" to "MUST". The new text reads An implementation MUST support a per-connection configuration mechanism (for example, a socket option) to reverse the sense of this preference and prefer temporary addresses over public addresses. The default is still to use public addresses not temporary addresses, although implementations MAY reverse this default if they want to emphasize privacy over application compatibility. 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 Jun 20 17:00:12 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5L00Ck7011700; Thu, 20 Jun 2002 17:00:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5L00BdD011699; Thu, 20 Jun 2002 17:00:11 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5L008k7011692 for ; Thu, 20 Jun 2002 17:00:09 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA19385 for ; Thu, 20 Jun 2002 17:00:14 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA07123 for ; Thu, 20 Jun 2002 17:00:14 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id RAA15027 for ; Thu, 20 Jun 2002 17:00:14 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g5L00Cn15665; Thu, 20 Jun 2002 17:00:12 -0700 X-mProtect: <200206210000> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (4.22.78.78, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdpTbAex; Thu, 20 Jun 2002 17:00:10 PDT Message-Id: <4.3.2.7.2.20020620165217.0314e4f8@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 20 Jun 2002 16:59:45 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: IPv6 w.g. Last Call on "Default Router Preferences, More-Specific Routes and Load Sharing" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a IPv6 working group last call for comments on advancing the following document as a Proposed Standard: Title: Default Router Preferences, More-Specific Routes and Load Sharing Author(s): R. Draves, B. Hinden Filename: draft-ietf-ipv6-router-selection-02.txt Pages: 13 Date: 10-Jun-02 Please send substantive comments to the ipng mailing list, and minor editorial comments to the authors. This last call period will on July 4, 2002. Bob Hinden / Steve Deering / Margaret Wasserman -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 20 17:08:11 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5L08Bk7011738; Thu, 20 Jun 2002 17:08:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5L08AxW011737; Thu, 20 Jun 2002 17:08:10 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5L086k7011730 for ; Thu, 20 Jun 2002 17:08:07 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA25526 for ; Thu, 20 Jun 2002 17:08:12 -0700 (PDT) Received: from astro.cs.utk.edu ([160.36.58.43]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA06363 for ; Thu, 20 Jun 2002 18:08:10 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5L07X202749; Thu, 20 Jun 2002 20:07:33 -0400 (EDT) Message-Id: <200206210007.g5L07X202749@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Richard Draves" cc: ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-ietf-ipv6-default-addr-select-08.txt In-reply-to: (Your message of "Thu, 20 Jun 2002 16:22:26 PDT.") <7695E2F6903F7A41961F8CF888D87EA8063CED6A@red-msg-06.redmond.corp.microsoft.com> Date: Thu, 20 Jun 2002 20:07:33 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > 2. I changed the requirement for an API to control temporary vs public > address usage, from "may" to "MUST". The new text reads > > An implementation MUST support a per-connection configuration > mechanism (for example, a socket option) to reverse the sense of > this preference and prefer temporary addresses over public > addresses. > > The default is still to use public addresses not temporary addresses, > although implementations MAY reverse this default if they want to > emphasize privacy over application compatibility. I don't think it's reasonable to allow host implementations to reverse this default - this will break apps. the default should always be to use public addresses. apps that can use temp addresses SHOULD ask for them. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 20 17:11:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5L0B8k7011758; Thu, 20 Jun 2002 17:11:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5L0B8b9011757; Thu, 20 Jun 2002 17:11:08 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5L0B4k7011750 for ; Thu, 20 Jun 2002 17:11:05 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA00301 for ; Thu, 20 Jun 2002 17:11:10 -0700 (PDT) Received: from mail6.microsoft.com (mail6.microsoft.com [131.107.3.126]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA07462 for ; Thu, 20 Jun 2002 18:11:09 -0600 (MDT) Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 20 Jun 2002 17:11:09 -0700 Received: from 157.54.8.155 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 20 Jun 2002 17:11:09 -0700 Received: from red-msg-06.redmond.corp.microsoft.com ([157.54.12.71]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 20 Jun 2002 17:11:09 -0700 x-mimeole: Produced By Microsoft Exchange V6.0.6177.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: I-D ACTION:draft-ietf-ipv6-default-addr-select-08.txt Date: Thu, 20 Jun 2002 17:11:10 -0700 Message-ID: <7695E2F6903F7A41961F8CF888D87EA8063CED6C@red-msg-06.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-ietf-ipv6-default-addr-select-08.txt Thread-Index: AcIYt6ooAXGhmlAuRU+izZ2VEhqkfAAAByhA From: "Richard Draves" To: "Keith Moore" Cc: X-OriginalArrivalTime: 21 Jun 2002 00:11:09.0332 (UTC) FILETIME=[24FBB540:01C218B8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5L0B5k7011751 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > The default is still to use public addresses not temporary > addresses, > > although implementations MAY reverse this default if they want to > > emphasize privacy over application compatibility. > > I don't think it's reasonable to allow host implementations > to reverse this default - this will break apps. > > the default should always be to use public addresses. > apps that can use temp addresses SHOULD ask for them. You don't know what applications are running on the host implementation and whether they will break or not. For some implementations, it MAY be reasonable to prefer temporary 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 Thu Jun 20 17:12:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5L0C9k7011775; Thu, 20 Jun 2002 17:12:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5L0C9KM011774; Thu, 20 Jun 2002 17:12:09 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5L0C5k7011767 for ; Thu, 20 Jun 2002 17:12:05 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA00652 for ; Thu, 20 Jun 2002 17:12:11 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA18729 for ; Thu, 20 Jun 2002 18:12:10 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id RAA15966; Thu, 20 Jun 2002 17:11:38 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g5L0BbI32582; Thu, 20 Jun 2002 17:11:37 -0700 X-mProtect: <200206210011> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (4.22.78.78, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdXpiPml; Thu, 20 Jun 2002 17:11:35 PDT Message-Id: <4.3.2.7.2.20020620170640.0314e4f8@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 20 Jun 2002 17:11:14 -0700 To: Erik.Nordmark@eng.sun.com, Thomas Narten From: Bob Hinden Subject: Request to Advance "IPv6 for Some Second and Third Generation Cellular Hosts" Cc: ipng@sunroof.eng.sun.com, iesg-secretary@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, Thomas, The chairs of the IPv6 working group, on behalf of the working group, request that the following document be published as an Informational RFC: Title: IPv6 for Some Second and Third Generation Cellular Hosts Author(s): J. Arkko, et al. Filename: draft-ietf-ipv6-cellular-host-03.txt Pages: 20 Date: 07-Jun-02 A working group last call for this document was completed on May 27, 2002. This draft resolves issues raised during the working group last call and subsequent discussion on the mailing list. Bob Hinden / Steve Deering / Margaret Wasserman IPv6 Working Group Co-Chairs -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 20 18:49:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5L1nlk7012183; Thu, 20 Jun 2002 18:49:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5L1nled012182; Thu, 20 Jun 2002 18:49:47 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5L1nhk7012175 for ; Thu, 20 Jun 2002 18:49:43 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA26096 for ; Thu, 20 Jun 2002 18:49:48 -0700 (PDT) Received: from esunmail ([129.147.58.121]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA23693 for ; Thu, 20 Jun 2002 19:49:48 -0600 (MDT) Received: from xpa-fe2 (esunmail-ge0 [129.147.58.121]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 0.3 (built May 13 2002)) with ESMTP id <0GY10070092ZVG@edgemail1.Central.Sun.COM> for ipng@sunroof.eng.sun.com; Thu, 20 Jun 2002 19:49:47 -0600 (MDT) Received: from localhost ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 0.2 (built Apr 26 2002)) with ESMTPSA id <0GY100M3G92YGT@mail.sun.net> for ipng@sunroof.eng.sun.com; Thu, 20 Jun 2002 19:49:47 -0600 (MDT) Date: Thu, 20 Jun 2002 18:49:45 -0700 From: Alain Durand Subject: Re: I-D ACTION:draft-ietf-ipv6-default-addr-select-08.txt In-reply-to: <7695E2F6903F7A41961F8CF888D87EA8063CED6A@red-msg-06.redmond.corp.microsoft.com> To: Richard Draves Cc: ipng@sunroof.eng.sun.com Message-id: <29C7CBB4-84B9-11D6-8263-00039376A6AA@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.482) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thursday, June 20, 2002, at 04:22 PM, Richard Draves wrote: > 2. I changed the requirement for an API to control temporary vs public > address usage, from "may" to "MUST". The new text reads > > An implementation MUST support a per-connection configuration > mechanism (for example, a socket option) to reverse the sense of > this preference and prefer temporary addresses over public > addresses. > > The default is still to use public addresses not temporary addresses, > although implementations MAY reverse this default if they want to > emphasize privacy over application compatibility. I'm wondering why having an escape clause that only apply to that particular rule. - 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 Jun 20 19:28:32 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5L2SGk7012289; Thu, 20 Jun 2002 19:28:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5L2SGRn012287; Thu, 20 Jun 2002 19:28:16 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5L2SBk7012273 for ; Thu, 20 Jun 2002 19:28:11 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA02952 for ; Thu, 20 Jun 2002 19:28:16 -0700 (PDT) Received: from web20413.mail.yahoo.com (web20401.mail.yahoo.com [66.163.169.89]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with SMTP id TAA05343 for ; Thu, 20 Jun 2002 19:28:16 -0700 (PDT) Message-ID: <20020621022816.26925.qmail@web20413.mail.yahoo.com> Received: from [12.234.194.61] by web20401.mail.yahoo.com via HTTP; Thu, 20 Jun 2002 19:28:16 PDT Date: Thu, 20 Jun 2002 19:28:16 -0700 (PDT) From: Tissa Senevirathne Subject: Re: ID on BGP extensions to Tag IPv6 routes that has IPv4 tunnels To: jeremy.de_clercq@alcatel.be Cc: pekkas@netcore.fi, ipng@sunroof.eng.sun.com, ppvpn@ppvpn.francetelecom.com, flefauch@cisco.com, dirk.ooms@alcatel.be, Gerard.Gastaud@alcatel.fr, stuart.prevost@bt.com, ngtrans@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-30790635-1024626496=:25129" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --0-30790635-1024626496=:25129 Content-Type: multipart/alternative; boundary="0-79032246-1024626496=:25129" --0-79032246-1024626496=:25129 Content-Type: text/plain; charset=us-ascii Jerome et.alConsider the attached diagram in textAbstract digaram here AS2 AS1. AS3 Site A | | Site B | | Relay A ----- | |---------- Relay B1.If we the remote relay routers are across multiple AS . In such a case BGP NEXT_HOP attribute would not represent the IP address of the relay routers.2. In general, and most commonly, remote relay sites may not be known in advance and there can be multiple of such sites. In this case explicit peering and thus use of BGP NEXT_HOP attribute is not possibile.3. When relay routers IP address is hidden in the NLRI, it is not convinent to apply BGP policies.So abstracting relay router address as an attribute allows to address all that..Why simple ?Proposed method use BGP4+ and extended attributes.. There is no special tunnel specific parsers needed. It is ! ! all driven by BGP policy engineWhy scalable ?It does not need any explcit peering or anything for tunneling purpose. Hence it scale as much the BGP 4+ scaleWhy copied to PPVPN ?RFC 2547 has roots in PPVPN. ID: draft-ietf-ngtrans-bgp-tunnel-04.txt has direct reference to 2547 and I am confident those folks can comment on the on going discussion productively.>From: jeremy.de_clercq@alcatel.be>To: Tissa Senevirathne >CC: pekkas@netcore.fi, ipng@sunroof.eng.sun.com, ppvpn@ppvpn.francetelecom.com, Francois Le Faucheur , Dirk OOMS , Gerard GASTAUD , stuart.prevost@bt.com>Subject: Re: ID on BGP extensions to Tag IPv6 routes that has IPv4 tunnels>Date: Thu, 20 Jun 2002 16:36:46 +0200>>Hi,>>thanks Pekka for identifying this.>>as far as I understand, the problem both drafts are trying solve is to>'signal' the IPv4 address to use as the egress of the tunnel, when>advertising IPv6 routes over an IPv4 backbone via BGP/TCP/IPv4. In order>to avoid the "additional explicit configuration" ! ! mentioned in RFC2545>(section 4).>>RFC2545 says:>"> Thus, when> using TCP over IPv4 as a transport for IPv6 reachability information,> additional explicit configuration of the peer's network address is> required.>">>* draft-tsenevir-ipv6-bgp-tun encodes this IPv4 address as a new>sub-type from a BGP extended cummunities attribute.>>* draft-ietf-ngtrans-bgp-tunnel encodes this IPv4 address in the BGP>NEXT_HOP field, in an IPv4-mapped IPv6 address.>>Tissa,>>[sidenote : should we discuss this on the ppvpn mailing list ? I don't>think it's of specific interest to this community.]>>You're proposing to use an IPv4 address encoded in an extended BGP>attribute as the tunnel endpoint ? this would mean that you don't use>the BGP NEXT_HOP attribute any more ? Which address will the BGP>NEXT_HOP contain ? What will it be used for ? How will BGP routers treat>it when propagating messages ?>>Could you please explain for which router the following is a problem :>"> Key problem! ! in hand is to distinguish between IPV6 routes that have> native connectivity and IPv6 routes that do not have native> connectivity.>">or what's wrong with this reasoning: "if the NEXT_HOP is reachable via>an IPv6 network (BGP/TCP/IPv6), use IPv6 forwarding; if the NEXT_HOP is>reachable via an IPv4 network (BGP/TCP/IPv4), use tunneling.">>some more comments inline:>> > **ID: draft-tsenevir-ipv6-bgp-tun-00.txt**> >> > 1. Treat IPv4 tunneling as an attribute of the native IPv6 route>>is the fact that the IPv6 route is distributed over an IPv4 network not>enough to know that normal forwarding is not going to work and that>you'll need some tunneling ?>> > 2. Extended community attributes are presented as a generic way of> > identifying specific properties of IPv6 routes or for that matter any route.> > In other words it is an extension to BGP4+>>The BGP NEXT_HOP attribute is the attribute to use to find the next hop>address to use to forward traffic towards the announced des! ! tinations.>> > 3. Implementation vise it is easier to apply policies on attributes.> > Actually the recommended method is to use attributes not more messages.>>I fail to see how this relates to policies.>Which draft is introducing which additional messages ? Both drafts are>using existing BGP messages.>> > 4. Methods in the ID Allows Ipv6 devices(routers) to select either a native> > Ipv6 connection or a tunnel connection (eg: ipv4) to reach remote Ipv6> > cloude, based BGP policies.>>Who can make the selection ? the traffic-egress (BGP sender) or the>traffic-ingress (BGP receiver)?>>Does this mean the network is IPv4 AND IPv6 capable ? If the answer is>yes, why should you tunnel IPv6 traffic ?>> >> > 5. In the ID we treat tunneling as reachability issue of the relay routers.> > Thus decoupling, tunnel discovery from route policies - to simplify> > implementation.>>I'm confused. The extended communities attribute contains the tunnel>egress IPv4 address, AND will be used for so! ! me policy. So it couples>tunnel discovery and route policies, no ?>>in draft-ietf-ngtrans-bgp-tunnel-04.txt, the BGP NEXT_HOP attribute is>used to identify the next hop, any other attributes can be added for any>other policy.>> >> > **ID: draft-ietf-ngtrans-bgp-tunnel-04.txt**> >> > (the way I understand..)> >> > 1. it propose to use special NLRI to encode IPv4 address (section 4.1)>>There's no special NLRI. The draft uses IPv6 NLRI (with known AFI/SAFI),>actually MP_REACH_NLRI as it's defined in MP-BGP, and an IPv4-mapped>IPv6 address as NEXT HOP.>> > 2. in section 7.3 the ID explains that it does not need to use VPN specific> > parts of 2547. in such case the methods can be simplified further, as> > presented in the new ID.>>section 7.3 says that there are no VPN specific parts in>draft-ietf-ngtrans-bgp-tunnel. Please explain the 'further>simplification' of your proposal.>>why is using a new attribute simpler than using the next hop attribute ?>> >> > Conclusion:> >> > The m! ! ethods presented in ID draft-tsenevir-ipv6-bgp-tun-00.txt is simpler,> > scalable and easy to implement. NOTE: Tunnel between relay routers is a> > reachability issue between them and it is better that we do not complicate> > our IPv6 routes with that>>"simpler, scalable and easy to implement". Please convince us.>>thanks,>>Jeremy. --------------------------------- Do You Yahoo!? Sign-up for Video Highlights of 2002 FIFA World Cup --0-79032246-1024626496=:25129 Content-Type: text/html; charset=us-ascii Jerome et.al Consider the attached diagram in text Abstract digaram here AS2 AS1. AS3 Site A | | Site B | | Relay A ----- | |---------- Relay B 1. If we the remote relay routers are across multiple AS . In such a case BGP NEXT_HOP attribute would not represent the IP address of the relay routers. 2. In general, and most commonly, remote relay sites may not be known in advance and there can be multiple of such sites. In this case explicit peering and thus use of BGP NEXT_HOP attribute is not possibile. 3. When relay routers IP address is hidden in the NLRI, it is not convinent to apply BGP policies. So abstracting relay router address as an attribute allows to address all that.. Why simple ? Proposed method use BGP4+ and extended attributes.. There is no special tunnel specific parsers needed. It is all driven by BGP policy engine Why scalable ? It does not need any explcit peering or anything for tunneling purpose. Hence it scale as much the BGP 4+ scale Why copied to PPVPN ? RFC 2547 has roots in PPVPN. ID: draft-ietf-ngtrans-bgp-tunnel-04.txt has direct reference to 2547 and I am confident those folks can comment on the on going discussion productively. >From: jeremy.de_clercq@alcatel.be >To: Tissa Senevirathne >CC: pekkas@netcore.fi, ipng@sunroof.eng.sun.com, ppvpn@ppvpn.francetelecom.com, Francois Le Faucheur , Dirk OOMS , Gerard GASTAUD , stuart.prevost@bt.com >Subject: Re: ID on BGP extensions to Tag IPv6 routes that has IPv4 tunnels >Date: Thu, 20 Jun 2002 16:36:46 +0200 > >Hi, > >thanks Pekka for identifying this. > >as far as I understand, the problem both drafts are trying solve is to >'signal' the IPv4 address to use as the egress of the tunnel, when >advertising IPv6 routes over an IPv4 backbone via BGP/TCP/IPv4. In order >to avoid the "additional explicit configuration" mentioned in RFC2545 >(section 4). > >RFC2545 says: >" > Thus, when > using TCP over IPv4 as a transport for IPv6 reachability information, > additional explicit configuration of the peer's network address is > required. >" > >* draft-tsenevir-ipv6-bgp-tun encodes this IPv4 address as a new >sub-type from a BGP extended cummunities attribute. > >* draft-ietf-ngtrans-bgp-tunnel encodes this IPv4 address in the BGP >NEXT_HOP field, in an IPv4-mapped IPv6 address. > >Tissa, > >[sidenote : should we discuss this on the ppvpn mailing list ? I don't >think it's of specific interest to this community.] > >You're proposing to use an IPv4 address encoded in an extended BGP >attribute as the tunnel endpoint ? this would mean that you don't use >the BGP NEXT_HOP attribute any more ? Which address will the BGP >NEXT_HOP contain ? What will it be used for ? How will BGP routers treat >it when propagating messages ? > >Could you please explain for which router the following is a problem : >" > Key problem in hand is to distinguish between IPV6 routes that have > native connectivity and IPv6 routes that do not have native > connectivity. >" >or what's wrong with this reasoning: "if the NEXT_HOP is reachable via >an IPv6 network (BGP/TCP/IPv6), use IPv6 forwarding; if the NEXT_HOP is >reachable via an IPv4 network (BGP/TCP/IPv4), use tunneling." > >some more comments inline: > > > **ID: draft-tsenevir-ipv6-bgp-tun-00.txt** > > > > 1. Treat IPv4 tunneling as an attribute of the native IPv6 route > >is the fact that the IPv6 route is distributed over an IPv4 network not >enough to know that normal forwarding is not going to work and that >you'll need some tunneling ? > > > 2. Extended community attributes are presented as a generic way of > > identifying specific properties of IPv6 routes or for that matter any route. > > In other words it is an extension to BGP4+ > >The BGP NEXT_HOP attribute is the attribute to use to find the next hop >address to use to forward traffic towards the announced destinations. > > > 3. Implementation vise it is easier to apply policies on attributes. > > Actually the recommended method is to use attributes not more messages. > >I fail to see how this relates to policies. >Which draft is introducing which additional messages ? Both drafts are >using existing BGP messages. > > > 4. Methods in the ID Allows Ipv6 devices(routers) to select either a native > > Ipv6 connection or a tunnel connection (eg: ipv4) to reach remote Ipv6 > > cloude, based BGP policies. > >Who can make the selection ? the traffic-egress (BGP sender) or the >traffic-ingress (BGP receiver)? > >Does this mean the network is IPv4 AND IPv6 capable ? If the answer is >yes, why should you tunnel IPv6 traffic ? > > > > > 5. In the ID we treat tunneling as reachability issue of the relay routers. > > Thus decoupling, tunnel discovery from route policies - to simplify > > implementation. > >I'm confused. The extended communities attribute contains the tunnel >egress IPv4 address, AND will be used for some policy. So it couples >tunnel discovery and route policies, no ? > >in draft-ietf-ngtrans-bgp-tunnel-04.txt, the BGP NEXT_HOP attribute is >used to identify the next hop, any other attributes can be added for any >other policy. > > > > > **ID: draft-ietf-ngtrans-bgp-tunnel-04.txt** > > > > (the way I understand..) > > > > 1. it propose to use special NLRI to encode IPv4 address (section 4.1) > >There's no special NLRI. The draft uses IPv6 NLRI (with known AFI/SAFI), >actually MP_REACH_NLRI as it's defined in MP-BGP, and an IPv4-mapped >IPv6 address as NEXT HOP. > > > 2. in section 7.3 the ID explains that it does not need to use VPN specific > > parts of 2547. in such case the methods can be simplified further, as > > presented in the new ID. > >section 7.3 says that there are no VPN specific parts in >draft-ietf-ngtrans-bgp-tunnel. Please explain the 'further >simplification' of your proposal. > >why is using a new attribute simpler than using the next hop attribute ? > > > > > Conclusion: > > > > The methods presented in ID draft-tsenevir-ipv6-bgp-tun-00.txt is simpler, > > scalable and easy to implement. NOTE: Tunnel between relay routers is a > > reachability issue between them and it is better that we do not complicate > > our IPv6 routes with that > >"simpler, scalable and easy to implement". Please convince us. > >thanks, > >Jeremy.


Do You Yahoo!?
Sign-up for Video Highlights of 2002 FIFA World Cup --0-79032246-1024626496=:25129-- --0-30790635-1024626496=:25129 Content-Type: application/msword; name="ipv6bgp diagram.doc" Content-Transfer-Encoding: base64 Content-Description: ipv6bgp diagram.doc Content-Disposition: attachment; filename="ipv6bgp diagram.doc" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAAB AAAAAQAAAAAAAAAAEAAAAgAAAAEAAAD+////AAAAAAAAAAD///////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ///////////////////////9/////v////7///8EAAAABQAAAAYAAAAHAAAA CAAAAAkAAAAKAAAA/v////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// /////////////////////////////////////////////1IAbwBvAHQAIABF AG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAWAAUA//////////8BAAAAAAkCAAAAAADAAAAAAAAARgAAAAAA AAAAAAAAACDCsPwkPikCAwAAAMAPAAAAAAAAVwBvAHIAZABEAG8AYwB1AG0A ZQBuAHQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ABoAAgECAAAA//////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAg8AAAAAAAABAEMAbwBtAHAATwBiAGoAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgACAP// /////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AD0AAABuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA//////////// ////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAQAAAAIAAAADAAAABAAAAAUAAAAGAAAABwAAAAgAAAAJAAAACgAA AAsAAAAMAAAADQAAAA4AAAAPAAAAEAAAABEAAAASAAAAEwAAABQAAAAVAAAA FgAAABcAAAAYAAAAGQAAABoAAAAbAAAAHAAAAB0AAAAeAAAAHwAAACAAAAAh AAAAIgAAACMAAAAkAAAAJQAAACYAAAAnAAAAKAAAACkAAAAqAAAAKwAAACwA AAAtAAAALgAAAC8AAAAwAAAAMQAAADIAAAAzAAAANAAAADUAAAA2AAAANwAA ADgAAAA5AAAAOgAAADsAAAA8AAAA/v///z4AAAD+//////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ///////////////////////////////cpWUAI8AJBAAAAAAAAAAAAAAAAAAA AAAkAwAAAQgAAAIPAAAAAAAAAAAAAAAAAAAAAAAA3QQAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAALA4AAGwAAAAsDgAAbAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFA4AABQAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4AAAoAAAAKDgAACgAAAAAA AAAAAAAAqgIAAHoAAAAoDgAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA7A4AAAIAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACY DgAAVAAAAO4OAAAUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAABQAGAAEAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAegAVEAAAAABUaW1lcyBO ZXcgUm9tYW4ADBAAAAIAU3ltYm9sAAsgAAAAAEFyaWFsABMgAAAAAE1TIFNh bnMgU2VyaWYADBAAAAIAU3ltYm9sABEwAAC6AENvdXJpZXIgTmV3ABUQAAAA AFRpbWVzIE5ldyBSb21hbgANQ29uc2lkZXIgdGhlIGZvbGxvd2luZyBkaWdy YW0NDSAgICAgICAgICAgICAgICAgICAgID09PT09PT09PT09PT09PT09PT09 PT09PQ0gICAgICAgICAgICAgICAgICAgICMgICAgICAgLS0tLS0tLS0tICAg ICAgICAjDSAgICAgICAgICAgICAgICAgICAgIyAgICAgIHwgIEFTMyAgICB8 ICAgICAgICMNICAgICAgICAgICAgICAgICAgICAjICAgICAgfCAgICAgICAg IHwgICAgICAgIw0gICAgICAgICAgICAgICAgICAgICMgICAgICAgLS0tLS0t LS0tICAgICAgICAjDSAgICAgICAgICAgICAgICAgICAgIyAtLS0tLS0tLS0g ICAgLS0tLS0tLS0tICMNICAgICAgICAgICAgICAgICAgICAjfCAgQVMxICAg IHwgIHwgIEFTMiAgICB8IyBFeGFtcGxlIElQVjQgSW50ZXJuZXQNICAgICAg ICAgICAgICAgICAgICAjIC0tLS0tLS0tLSAgICAtLS0tLS0tLS0gIw0gICAg ICAgICAgICAgICAgICAgICA9PT09PT09PT09PT09PT09PT09PT09PT0NICAg ICBUbyBJUFY2ICAgICAgICAgICAgIHx8ICAgICAgICAgICAgICAgICB8fCAg ICAgICAgICAgICAgICAgIFRvIElQVjYNICAgICAgIFxcICAgICAgICAgICAg ICAgIHx8ICAgICAgICAgICAgICAgICB8fCAgICAgICAgICAgICAgICAgLy8N ICAgICAgICBcXCAgICAgICAgICAgICAgIHx8ICAgICAgICAgICAgICAgICB8 fCAgICAgICAgICAgICAgICAvLw0gICAgICAgICBcXCAgICAgICAgICAgICAg fHwgICAgICAgICAgICAgICAgIHx8ICAgICAgICAgICAgICAgLy8NICAgICAg JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSAgICAgICAgICAlJSUlJSUlJSUl JSUlJSUlJSUlJSUlJSUlDSAgICAgICUgIC0tLS0tLS0gICAgICAgLS0tLS0t ICAlICAgICAgICAgJSAgLS0tLS0tLSAgICAgICAgLS0tLS0tICUNICAgICAg JSB8IGlwdjYgIHwgICAgIHwgUmVsYXl8ICUgICAgICAgICAlIHxSZWxheSAg fCAgICAgIHxJUHY2ICB8JQ0gICAgICAlICAtLS0tLS0tICAgICAgIC0tLS0t LSAgJSAgICAgICAgICUgIC0tLS0tLS0gICAgICAgIC0tLS0tLSAlDSAgICAg ICUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUgICAgICAgICAgJSUlJSUlJSUl JSUlJSUlJSUlJSUlJSUlJQ0NICAgICAgICAgSVBWNiBzaXRlIEEgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIElQdjYgc2l0ZSBCDQ0gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLg0gICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgLiBTaXRlIEMsIEQgLi4uIE4N DQ0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAJAMAACUDAABCAwAAQwMAAEQDAABxAwAAcgMA AKADAAChAwAAzwMAANADAAD+AwAA/wMAAC0EAAAuBAAAXAQAAF0EAAChBAAA ogQAANAEAADRBAAA/gQAAP8EAABGBQAARwUAAIgFAACJBQAAyQUAAMoFAAAJ BgAACgYAAEwGAABNBgAAkAYAAJEGAADUBgAA1QYAABgHAAAZBwAAWwcAAFwH AABdBwAAmQcAAJoHAACbBwAAxAcAAMUHAAD+BwAA/wcAAAAIAAABCAAA/fv5 9/Xz8e/t6+nn5ePh393b2dfV09HPzcvJx8XDwb+9u7m3tbOxr62rqaelo6Gf nZsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAANdBQADXQUAA10FAANdBQADXQUAA10FAANdBQADXQUA A10FAANdBQADXQUAA10FAANdBQADXQUAA10FAANdBQADXQUAA10FAANdBQAD XQUAA10FAANdBQADXQUAA10FAANdBQADXQUAA10FAANdBQADXQUAA10FAANd BQADXQUAA10FAANdBQADXQUAA10FAANdBQADXQUAA10FAANdBQADXQUAA10F AANdBQADXQUAA10FAANdBQADXQUAA10FAANdBQADXQUAADIkAwAAJQMAAEMD AABEAwAAcgMAAKEDAADQAwAA/wMAAC4EAABdBAAAogQAANEEAAD/BAAARwUA AIkFAADKBQAACgYAAE0GAACRBgAA1QYAABkHAABcBwAAXQcAAJoHAACbBwAA xQcAAP8HAAAACAAAAQgAAP0AAAAAAAD7AAAAAAAA+QAAAAAAAPcAAAAAAAD1 AAAAAAAA8wAAAAAAAPEAAAAAAADvAAAAAAAA7QAAAAAAAOsAAAAAAADpAAAA AAAA5wAAAAAAAOUAAAAAAADjAAAAAAAA4QAAAAAAAN8AAAAAAADdAAAAAAAA 2wAAAAAAANkAAAAAAADXAAAAAAAA1QAAAAAAANMAAAAAAADRAAAAAAAAzwAA AAAAAM0AAAAAAADLAAAAAAAAyQAAAAAAAMcAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAABAAAAAQAAAAEAAAAB AAAAAQAAAAEAAAABAAAAAQAAAAEAAAABAAAAAQAAAAEAAAABAAAAAQAAAAEA AAABAAAAAQAAAAEAAAABAAAAAQAAAAEAAAABAAAAAQAAAAEAAAABAAAAAQAA AAEAAAAAHCQDAAABCAAABQAkAwAAAQgAAAYAAAAAAN0EAAAAAP////8AAP// //8ECwAADgAPAAgAAQBLAA8AAAAAABoAAEDx/wIAGgAGTm9ybWFsAAIAAAAD AGEJBAAAAAAAAAAAAAAAAAAAAAAAAAAiAEFA8v+hACIAFkRlZmF1bHQgUGFy YWdyYXBoIEZvbnQAAAAAAAAAAAAAAAAAAAAEAAAAAAAAANACAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAA/0AUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAQD+/wMKAAD/////AAkCAAAAAADAAAAAAAAARhwAAABN aWNyb3NvZnQgV29yZCA2LjAgRG9jdW1lbnQACgAAAE1TV29yZERvYwAQAAAA V29yZC5Eb2N1bWVudC42APQ5snEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA --0-30790635-1024626496=:25129-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 20 19:53:58 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5L2rvk7012401; Thu, 20 Jun 2002 19:53:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5L2rvq1012400; Thu, 20 Jun 2002 19:53:57 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5L2rZk7012384 for ; Thu, 20 Jun 2002 19:53:35 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA07502 for ; Thu, 20 Jun 2002 19:53:40 -0700 (PDT) Received: from web20413.mail.yahoo.com (web20401.mail.yahoo.com [66.163.169.89]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id UAA01376 for ; Thu, 20 Jun 2002 20:53:39 -0600 (MDT) Message-ID: <20020621025339.29362.qmail@web20413.mail.yahoo.com> Received: from [12.234.194.61] by web20401.mail.yahoo.com via HTTP; Thu, 20 Jun 2002 19:53:39 PDT Date: Thu, 20 Jun 2002 19:53:39 -0700 (PDT) From: Tissa Senevirathne Subject: clear email..Re: ID on BGP extensions to Tag IPv6 routes that has IPv4 tunnels To: jeremy.de_clercq@alcatel.be Cc: pekkas@netcore.fi, ipng@sunroof.eng.sun.com, ppvpn@ppvpn.francetelecom.com, flefauch@cisco.com, dirk.ooms@alcatel.be, Gerard.Gastaud@alcatel.fr, stuart.prevost@bt.com, ngtrans@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-1762714637-1024628019=:29169" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --0-1762714637-1024628019=:29169 Content-Type: multipart/alternative; boundary="0-2015800112-1024628019=:29169" --0-2015800112-1024628019=:29169 Content-Type: text/plain; charset=us-ascii Sorry.. Previous email got corrupted... Jerome et.al Consider the attached diagram. Abstract diagram below.. AS2 AS 1 AS3 | | Site A | | Site B Relay A - --- Relay B 1. If we the remote relay routers are across multiple AS . In such a case BGP NEXT_HOP attribute would not represent the IP address of the relay routers. 2. In general, and most commonly, remote relay sites may not be known in advance and there can be multiple of such sites. In this case explicit peering and thus use of BGP NEXT_HOP attribute is not possibile. 3. When relay routers IP address is hidden in the NLRI, it is not convinent to apply BGP policies. So abstracting relay router address as an attribute allows to address all that.. Why simple ? Proposed method use BGP4+ and extended attributes.. There is no special tunnel specific parsers needed. It is all driven by BGP policy engine Why scalable ? It does not need any explcit peering or anything for tunneling purpose. Hence it scale as much the BGP 4+ scale Why copied to PPVPN ? RFC 2547 has roots in PPVPN. ID: draft-ietf-ngtrans-bgp-tunnel-04.txt has direct reference to 2547 and I am confident those folks can comment on the on going discussion productively >From: jeremy.de_clercq@alcatel.be >To: Tissa Senevirathne >CC: pekkas@netcore.fi, ipng@sunroof.eng.sun.com, ppvpn@ppvpn.francetelecom.com, Francois Le Faucheur , Dirk OOMS , Gerard GASTAUD , stuart.prevost@bt.com >Subject: Re: ID on BGP extensions to Tag IPv6 routes that has IPv4 tunnels >Date: Thu, 20 Jun 2002 16:36:46 +0200 > >Hi, > >thanks Pekka for identifying this. > >as far as I understand, the problem both drafts are trying solve is to >'signal' the IPv4 address to use as the egress of the tunnel, when >advertising IPv6 routes over an IPv4 backbone via BGP/TCP/IPv4. In order >to avoid the "additional explicit configuration" mentioned in RFC2545 >(section 4). > >RFC2545 says: >" > Thus, when > using TCP over IPv4 as a transport for IPv6 reachability information, > additional explicit configuration of the peer's network address is > required. >" > >* draft-tsenevir-ipv6-bgp-tun encodes this IPv4 address as a new >sub-type from a BGP extended cummunities attribute. > >* draft-ietf-ngtrans-bgp-tunnel encodes this IPv4 address in the BGP >NEXT_HOP field, in an IPv4-mapped IPv6 address. > >Tissa, > >[sidenote : should we discuss this on the ppvpn mailing list ? I don't >think it's of specific interest to this community.] > >You're proposing to use an IPv4 address encoded in an extended BGP >attribute as the tunnel endpoint ? this would mean that you don't use >the BGP NEXT_HOP attribute any more ? Which address will the BGP >NEXT_HOP contain ? What will it be used for ? How will BGP routers treat >it when propagating messages ? > >Could you please explain for which router the following is a problem : >" > Key problem in hand is to distinguish between IPV6 routes that have > native connectivity and IPv6 routes that do not have native > connectivity. >" >or what's wrong with this reasoning: "if the NEXT_HOP is reachable via >an IPv6 network (BGP/TCP/IPv6), use IPv6 forwarding; if the NEXT_HOP is >reachable via an IPv4 network (BGP/TCP/IPv4), use tunneling." > >some more comments inline: > > > **ID: draft-tsenevir-ipv6-bgp-tun-00.txt** > > > > 1. Treat IPv4 tunneling as an attribute of the native IPv6 route > >is the fact that the IPv6 route is distributed over an IPv4 network not >enough to know that normal forwarding is not going to work and that >you'll need some tunneling ? > > > 2. Extended community attributes are presented as a generic way of > > identifying specific properties of IPv6 routes or for that matter any route. > > In other words it is an extension to BGP4+ > >The BGP NEXT_HOP attribute is the attribute to use to find the next hop >address to use to forward traffic towards the announced destinations. > > > 3. Implementation vise it is easier to apply policies on attributes. > > Actually the recommended method is to use attributes not more messages. > >I fail to see how this relates to policies. >Which draft is introducing which additional messages ? Both drafts are >using existing BGP messages. > > > 4. Methods in the ID Allows Ipv6 devices(routers) to select either a native > > Ipv6 connection or a tunnel connection (eg: ipv4) to reach remote Ipv6 > > cloude, based BGP policies. > >Who can make the selection ? the traffic-egress (BGP sender) or the >traffic-ingress (BGP receiver)? > >Does this mean the network is IPv4 AND IPv6 capable ? If the answer is >yes, why should you tunnel IPv6 traffic ? > > > > > 5. In the ID we treat tunneling as reachability issue of the relay routers. > > Thus decoupling, tunnel discovery from route policies - to simplify > > implementation. > >I'm confused. The extended communities attribute contains the tunnel >egress IPv4 address, AND will be used for some policy. So it couples >tunnel discovery and route policies, no ? > >in draft-ietf-ngtrans-bgp-tunnel-04.txt, the BGP NEXT_HOP attribute is >used to identify the next hop, any other attributes can be added for any >other policy. > > > > > **ID: draft-ietf-ngtrans-bgp-tunnel-04.txt** > > > > (the way I understand..) > > > > 1. it propose to use special NLRI to encode IPv4 address (section 4.1) > >There's no special NLRI. The draft uses IPv6 NLRI (with known AFI/SAFI), >actually MP_REACH_NLRI as it's defined in MP-BGP, and an IPv4-mapped >IPv6 address as NEXT HOP. > > > 2. in section 7.3 the ID explains that it does not need to use VPN specific > > parts of 2547. in such case the methods can be simplified further, as > > presented in the new ID. > >section 7.3 says that there are no VPN specific parts in >draft-ietf-ngtrans-bgp-tunnel. Please explain the 'further >simplification' of your proposal. > >why is using a new attribute simpler than using the next hop attribute ? > > > > > Conclusion: > > > > The methods presented in ID draft-tsenevir-ipv6-bgp-tun-00.txt is simpler, > > scalable and easy to implement. NOTE: Tunnel between relay routers is a > > reachability issue between them and it is better that we do not complicate > > our IPv6 routes with that > >"simpler, scalable and easy to implement". Please convince us. > >thanks, > >Jeremy. --------------------------------- Do You Yahoo!? Sign-up for Video Highlights of 2002 FIFA World Cup --0-2015800112-1024628019=:29169 Content-Type: text/html; charset=us-ascii  Sorry.. Previous email got corrupted...

Jerome et.al

Consider the attached diagram.

Abstract diagram below..

                                AS2

                       AS 1                   AS3

                      |                          |

  Site A            |                          |            Site B

         Relay A -                            ---    Relay B

 

 

1.

If we the remote relay routers are across multiple AS . In such a case BGP NEXT_HOP attribute would not represent the IP address of the relay routers.

2. In general, and most commonly, remote relay sites may not be known in advance and there can be multiple of such sites. In this case explicit peering and thus use of BGP NEXT_HOP attribute is not possibile.

3. When relay routers IP address is hidden in the NLRI, it is not convinent to apply BGP policies.

So abstracting relay router address as an attribute allows to address all that..

Why simple ?

Proposed method use BGP4+ and extended attributes.. There is no special tunnel specific parsers needed. It is all driven by BGP policy engine

Why scalable ?

It does not need any explcit peering or anything for tunneling purpose. Hence it scale as much the BGP 4+ scale

Why copied to PPVPN ?

RFC 2547 has roots in PPVPN. ID: draft-ietf-ngtrans-bgp-tunnel-04.txt has direct reference to 2547 and I am confident those folks can comment on the on going discussion productively

>From: jeremy.de_clercq@alcatel.be
>To: Tissa Senevirathne <tsenevir@hotmail.com>
>CC: pekkas@netcore.fi, ipng@sunroof.eng.sun.com, ppvpn@ppvpn.francetelecom.com,   Francois Le Faucheur <flefauch@cisco.com>, Dirk OOMS <dirk.ooms@alcatel.be>,   Gerard GASTAUD <Gerard.Gastaud@alcatel.fr>, stuart.prevost@bt.com
>Subject: Re: ID on BGP extensions to Tag IPv6 routes that has IPv4 tunnels
>Date: Thu, 20 Jun 2002 16:36:46 +0200
>
>Hi,
>
>thanks Pekka for identifying this.
>
>as far as! ! I understand, the problem both drafts are trying solve is to
>'signal' the IPv4 address to use as the egress of the tunnel, when
>advertising IPv6 routes over an IPv4 backbone via BGP/TCP/IPv4. In order
>to avoid the "additional explicit configuration" mentioned in RFC2545
>(section 4).
>
>RFC2545 says:
>"
>    Thus, when
>    using TCP over IPv4 as a transport for IPv6 reachability information,
>    additional explicit configuration of the peer's network address is
>    required.
>"
>
>* draft-tsenevir-ipv6-bgp-tun encodes this IPv4 address as a new
>sub-type from a BGP extended cummunities attribute.
>
>* draft-ietf-ngtrans-bgp-tunnel encodes this IPv4 address in the BGP
>NEXT_HOP field, in an IPv4-mapped IPv6 address.
>
>Tissa,
>
>[sidenote : should we discuss this on the ppvpn mailin! ! g list ? I don't
>think it's of specific interest to this community.]
>
>You're proposing to use an IPv4 address encoded in an extended BGP
>attribute as the tunnel endpoint ? this would mean that you don't use
>the BGP NEXT_HOP attribute any more ? Which address will the BGP
>NEXT_HOP contain ? What will it be used for ? How will BGP routers treat
>it when propagating messages ?
>
>Could you please explain for which router the following is a problem :
>"
>    Key problem in hand is to distinguish between IPV6 routes that have
>    native connectivity and IPv6 routes that do not have native
>    connectivity.
>"
>or what's wrong with this reasoning: "if the NEXT_HOP is reachable via
>an IPv6 network (BGP/TCP/IPv6), use IPv6 forwarding; if the NEXT_HOP is
>reachable via an IPv4 network (BGP/TCP/IPv4), use tunneling."
>
>s! ! ome more comments inline:
>
> > **ID: draft-tsenevir-ipv6-bgp-tun-00.txt**
> >
> > 1. Treat IPv4 tunneling as an attribute of the native IPv6 route
>
>is the fact that the IPv6 route is distributed over an IPv4 network not
>enough to know that normal forwarding is not going to work and that
>you'll need some tunneling ?
>
> > 2. Extended community attributes are presented as a generic way of
> > identifying specific properties of IPv6 routes or for that matter any route.
> > In other words it is an extension to BGP4+
>
>The BGP NEXT_HOP attribute is the attribute to use to find the next hop
>address to use to forward traffic towards the announced destinations.
>
> > 3. Implementation vise it is easier to apply policies on attributes.
> > Actually the recommended method is to use attributes not more messages.
>
>I fail to see how this r! ! elates to policies.
>Which draft is introducing which additional messages ? Both drafts are
>using existing BGP messages.
>
> > 4. Methods in the ID Allows Ipv6 devices(routers) to select either a native
> > Ipv6 connection or a tunnel connection (eg: ipv4) to reach remote Ipv6
> > cloude, based BGP policies.
>
>Who can make the selection ? the traffic-egress (BGP sender) or the
>traffic-ingress (BGP receiver)?
>
>Does this mean the network is IPv4 AND IPv6 capable ? If the answer is
>yes, why should you tunnel IPv6 traffic ?
>
> >
> > 5. In the ID we treat tunneling as reachability issue of the relay routers.
> > Thus decoupling, tunnel discovery from route policies - to simplify
> > implementation.
>
>I'm confused. The extended communities attribute contains the tunnel
>egress IPv4 address, AND will be used for some policy. So it couple! ! s
>tunnel discovery and route policies, no ?
>
>in draft-ietf-ngtrans-bgp-tunnel-04.txt, the BGP NEXT_HOP attribute is
>used to identify the next hop, any other attributes can be added for any
>other policy.
>
> >
> > **ID: draft-ietf-ngtrans-bgp-tunnel-04.txt**
> >
> > (the way I understand..)
> >
> > 1. it propose to use special NLRI to encode IPv4 address (section 4.1)
>
>There's no special NLRI. The draft uses IPv6 NLRI (with known AFI/SAFI),
>actually MP_REACH_NLRI as it's defined in MP-BGP, and an IPv4-mapped
>IPv6 address as NEXT HOP.
>
> > 2. in section 7.3 the ID explains that it does not need to use VPN specific
> > parts of 2547. in such case the methods can be simplified further, as
> > presented in the new ID.
>
>section 7.3 says that there are no VPN specific parts in
>draft-ietf-ngtrans-bgp-tunnel. P! ! lease explain the 'further
>simplification' of your proposal.
>
>why is using a new attribute simpler than using the next hop attribute ?
>
> >
> > Conclusion:
> >
> > The methods presented in ID draft-tsenevir-ipv6-bgp-tun-00.txt is simpler,
> > scalable and easy to implement. NOTE: Tunnel between relay routers is a
> > reachability issue between them and it is better that we do not complicate
> > our IPv6 routes with that
>
>"simpler, scalable and easy to implement". Please convince us.
>
>thanks,
>
>Jeremy.


 

 


Do You Yahoo!?
Sign-up for Video Highlights of 2002 FIFA World Cup --0-2015800112-1024628019=:29169-- --0-1762714637-1024628019=:29169 Content-Type: application/msword; name="ipv6bgp diagram.doc" Content-Transfer-Encoding: base64 Content-Description: ipv6bgp diagram.doc Content-Disposition: attachment; filename="ipv6bgp diagram.doc" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAAB AAAAAQAAAAAAAAAAEAAAAgAAAAEAAAD+////AAAAAAAAAAD///////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ///////////////////////9/////v////7///8EAAAABQAAAAYAAAAHAAAA CAAAAAkAAAAKAAAA/v////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// /////////////////////////////////////////////1IAbwBvAHQAIABF AG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAWAAUA//////////8BAAAAAAkCAAAAAADAAAAAAAAARgAAAAAA AAAAAAAAACDCsPwkPikCAwAAAMAPAAAAAAAAVwBvAHIAZABEAG8AYwB1AG0A ZQBuAHQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ABoAAgECAAAA//////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAg8AAAAAAAABAEMAbwBtAHAATwBiAGoAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgACAP// /////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AD0AAABuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA//////////// ////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAQAAAAIAAAADAAAABAAAAAUAAAAGAAAABwAAAAgAAAAJAAAACgAA AAsAAAAMAAAADQAAAA4AAAAPAAAAEAAAABEAAAASAAAAEwAAABQAAAAVAAAA FgAAABcAAAAYAAAAGQAAABoAAAAbAAAAHAAAAB0AAAAeAAAAHwAAACAAAAAh AAAAIgAAACMAAAAkAAAAJQAAACYAAAAnAAAAKAAAACkAAAAqAAAAKwAAACwA AAAtAAAALgAAAC8AAAAwAAAAMQAAADIAAAAzAAAANAAAADUAAAA2AAAANwAA ADgAAAA5AAAAOgAAADsAAAA8AAAA/v///z4AAAD+//////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ///////////////////////////////cpWUAI8AJBAAAAAAAAAAAAAAAAAAA AAAkAwAAAQgAAAIPAAAAAAAAAAAAAAAAAAAAAAAA3QQAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAALA4AAGwAAAAsDgAAbAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFA4AABQAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4AAAoAAAAKDgAACgAAAAAA AAAAAAAAqgIAAHoAAAAoDgAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA7A4AAAIAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACY DgAAVAAAAO4OAAAUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAABQAGAAEAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAegAVEAAAAABUaW1lcyBO ZXcgUm9tYW4ADBAAAAIAU3ltYm9sAAsgAAAAAEFyaWFsABMgAAAAAE1TIFNh bnMgU2VyaWYADBAAAAIAU3ltYm9sABEwAAC6AENvdXJpZXIgTmV3ABUQAAAA AFRpbWVzIE5ldyBSb21hbgANQ29uc2lkZXIgdGhlIGZvbGxvd2luZyBkaWdy YW0NDSAgICAgICAgICAgICAgICAgICAgID09PT09PT09PT09PT09PT09PT09 PT09PQ0gICAgICAgICAgICAgICAgICAgICMgICAgICAgLS0tLS0tLS0tICAg ICAgICAjDSAgICAgICAgICAgICAgICAgICAgIyAgICAgIHwgIEFTMyAgICB8 ICAgICAgICMNICAgICAgICAgICAgICAgICAgICAjICAgICAgfCAgICAgICAg IHwgICAgICAgIw0gICAgICAgICAgICAgICAgICAgICMgICAgICAgLS0tLS0t LS0tICAgICAgICAjDSAgICAgICAgICAgICAgICAgICAgIyAtLS0tLS0tLS0g ICAgLS0tLS0tLS0tICMNICAgICAgICAgICAgICAgICAgICAjfCAgQVMxICAg IHwgIHwgIEFTMiAgICB8IyBFeGFtcGxlIElQVjQgSW50ZXJuZXQNICAgICAg ICAgICAgICAgICAgICAjIC0tLS0tLS0tLSAgICAtLS0tLS0tLS0gIw0gICAg ICAgICAgICAgICAgICAgICA9PT09PT09PT09PT09PT09PT09PT09PT0NICAg ICBUbyBJUFY2ICAgICAgICAgICAgIHx8ICAgICAgICAgICAgICAgICB8fCAg ICAgICAgICAgICAgICAgIFRvIElQVjYNICAgICAgIFxcICAgICAgICAgICAg ICAgIHx8ICAgICAgICAgICAgICAgICB8fCAgICAgICAgICAgICAgICAgLy8N ICAgICAgICBcXCAgICAgICAgICAgICAgIHx8ICAgICAgICAgICAgICAgICB8 fCAgICAgICAgICAgICAgICAvLw0gICAgICAgICBcXCAgICAgICAgICAgICAg fHwgICAgICAgICAgICAgICAgIHx8ICAgICAgICAgICAgICAgLy8NICAgICAg JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSAgICAgICAgICAlJSUlJSUlJSUl JSUlJSUlJSUlJSUlJSUlDSAgICAgICUgIC0tLS0tLS0gICAgICAgLS0tLS0t ICAlICAgICAgICAgJSAgLS0tLS0tLSAgICAgICAgLS0tLS0tICUNICAgICAg JSB8IGlwdjYgIHwgICAgIHwgUmVsYXl8ICUgICAgICAgICAlIHxSZWxheSAg fCAgICAgIHxJUHY2ICB8JQ0gICAgICAlICAtLS0tLS0tICAgICAgIC0tLS0t LSAgJSAgICAgICAgICUgIC0tLS0tLS0gICAgICAgIC0tLS0tLSAlDSAgICAg ICUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUgICAgICAgICAgJSUlJSUlJSUl JSUlJSUlJSUlJSUlJSUlJQ0NICAgICAgICAgSVBWNiBzaXRlIEEgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIElQdjYgc2l0ZSBCDQ0gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLg0gICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgLiBTaXRlIEMsIEQgLi4uIE4N DQ0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAJAMAACUDAABCAwAAQwMAAEQDAABxAwAAcgMA AKADAAChAwAAzwMAANADAAD+AwAA/wMAAC0EAAAuBAAAXAQAAF0EAAChBAAA ogQAANAEAADRBAAA/gQAAP8EAABGBQAARwUAAIgFAACJBQAAyQUAAMoFAAAJ BgAACgYAAEwGAABNBgAAkAYAAJEGAADUBgAA1QYAABgHAAAZBwAAWwcAAFwH AABdBwAAmQcAAJoHAACbBwAAxAcAAMUHAAD+BwAA/wcAAAAIAAABCAAA/fv5 9/Xz8e/t6+nn5ePh393b2dfV09HPzcvJx8XDwb+9u7m3tbOxr62rqaelo6Gf nZsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAANdBQADXQUAA10FAANdBQADXQUAA10FAANdBQADXQUA A10FAANdBQADXQUAA10FAANdBQADXQUAA10FAANdBQADXQUAA10FAANdBQAD XQUAA10FAANdBQADXQUAA10FAANdBQADXQUAA10FAANdBQADXQUAA10FAANd BQADXQUAA10FAANdBQADXQUAA10FAANdBQADXQUAA10FAANdBQADXQUAA10F AANdBQADXQUAA10FAANdBQADXQUAA10FAANdBQADXQUAADIkAwAAJQMAAEMD AABEAwAAcgMAAKEDAADQAwAA/wMAAC4EAABdBAAAogQAANEEAAD/BAAARwUA AIkFAADKBQAACgYAAE0GAACRBgAA1QYAABkHAABcBwAAXQcAAJoHAACbBwAA xQcAAP8HAAAACAAAAQgAAP0AAAAAAAD7AAAAAAAA+QAAAAAAAPcAAAAAAAD1 AAAAAAAA8wAAAAAAAPEAAAAAAADvAAAAAAAA7QAAAAAAAOsAAAAAAADpAAAA AAAA5wAAAAAAAOUAAAAAAADjAAAAAAAA4QAAAAAAAN8AAAAAAADdAAAAAAAA 2wAAAAAAANkAAAAAAADXAAAAAAAA1QAAAAAAANMAAAAAAADRAAAAAAAAzwAA AAAAAM0AAAAAAADLAAAAAAAAyQAAAAAAAMcAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAABAAAAAQAAAAEAAAAB AAAAAQAAAAEAAAABAAAAAQAAAAEAAAABAAAAAQAAAAEAAAABAAAAAQAAAAEA AAABAAAAAQAAAAEAAAABAAAAAQAAAAEAAAABAAAAAQAAAAEAAAABAAAAAQAA AAEAAAAAHCQDAAABCAAABQAkAwAAAQgAAAYAAAAAAN0EAAAAAP////8AAP// //8ECwAADgAPAAgAAQBLAA8AAAAAABoAAEDx/wIAGgAGTm9ybWFsAAIAAAAD AGEJBAAAAAAAAAAAAAAAAAAAAAAAAAAiAEFA8v+hACIAFkRlZmF1bHQgUGFy YWdyYXBoIEZvbnQAAAAAAAAAAAAAAAAAAAAEAAAAAAAAANACAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAA/0AUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAQD+/wMKAAD/////AAkCAAAAAADAAAAAAAAARhwAAABN aWNyb3NvZnQgV29yZCA2LjAgRG9jdW1lbnQACgAAAE1TV29yZERvYwAQAAAA V29yZC5Eb2N1bWVudC42APQ5snEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA --0-1762714637-1024628019=:29169-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 20 20:23:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5L3Njk7012495; Thu, 20 Jun 2002 20:23:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5L3NjCm012494; Thu, 20 Jun 2002 20:23:45 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5L3Nfk7012487 for ; Thu, 20 Jun 2002 20:23:42 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA12233 for ; Thu, 20 Jun 2002 20:23:47 -0700 (PDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA02616 for ; Thu, 20 Jun 2002 21:23:46 -0600 (MDT) Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 20 Jun 2002 20:23:44 -0700 Received: from 157.54.8.155 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 20 Jun 2002 20:23:45 -0700 Received: from red-msg-06.redmond.corp.microsoft.com ([157.54.12.71]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 20 Jun 2002 20:23:45 -0700 x-mimeole: Produced By Microsoft Exchange V6.0.6177.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: I-D ACTION:draft-ietf-ipv6-default-addr-select-08.txt Date: Thu, 20 Jun 2002 20:23:44 -0700 Message-ID: <7695E2F6903F7A41961F8CF888D87EA8063CED6E@red-msg-06.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-ietf-ipv6-default-addr-select-08.txt Thread-Index: AcIYxe1pqkf8zG0fSvWFHGzXPRvSfAACuNgw From: "Richard Draves" To: "Alain Durand" Cc: X-OriginalArrivalTime: 21 Jun 2002 03:23:45.0418 (UTC) FILETIME=[0CF27EA0:01C218D3] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5L3Ngk7012488 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > The default is still to use public addresses not temporary > addresses, > > although implementations MAY reverse this default if they want to > > emphasize privacy over application compatibility. > > > I'm wondering why having an escape clause that only apply > to that particular rule. First, note that most of the source address slection rules are SHOULD requirements. (The "prefer matching scope" rule being an exception - it's MUST.) An implementation can violate a SHOULD requirement - from RFC 2119: 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. So even without the explicit escape clause, an implementor could decide given their implementation's particular circumstances to prefer temporary addresses over public addresses. Second, note that this escape clause has been there for more than a year (since version 04) and already passed WG & IETF last calls. The reason for having the explicit escape clause is that this rule has been the subject of much discussion in the WG & IESG; some feel that privacy is the overriding concern and some feel that application compatibility is more important. We have a rough consensus to favor application compatibility by default. But as a member of the privacy camp, I think it's helpful to remind implementors that if in their particular circumstances privacy is more important than app compatibility, then they can prefer temporary addresses by default. 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 Jun 20 20:37:32 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5L3bWk7012555; Thu, 20 Jun 2002 20:37:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5L3bWxj012554; Thu, 20 Jun 2002 20:37:32 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5L3bSk7012546 for ; Thu, 20 Jun 2002 20:37:28 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA14826 for ; Thu, 20 Jun 2002 20:37:34 -0700 (PDT) Received: from astro.cs.utk.edu ([160.36.58.43]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA05869 for ; Thu, 20 Jun 2002 21:37:33 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5L3aq203115; Thu, 20 Jun 2002 23:36:53 -0400 (EDT) Message-Id: <200206210336.g5L3aq203115@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Richard Draves" cc: "Keith Moore" , ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-ietf-ipv6-default-addr-select-08.txt In-reply-to: (Your message of "Thu, 20 Jun 2002 17:11:10 PDT.") <7695E2F6903F7A41961F8CF888D87EA8063CED6C@red-msg-06.redmond.corp.microsoft.com> Date: Thu, 20 Jun 2002 23:36:52 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > The default is still to use public addresses not temporary > > addresses, > > > although implementations MAY reverse this default if they want to > > > emphasize privacy over application compatibility. > > > > I don't think it's reasonable to allow host implementations > > to reverse this default - this will break apps. > > > > the default should always be to use public addresses. > > apps that can use temp addresses SHOULD ask for them. > > You don't know what applications are running on the host implementation > and whether they will break or not. and in the vast majority of cases, neither will the host implementor. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 20 21:08:57 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5L48uk7012635; Thu, 20 Jun 2002 21:08:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5L48uHL012634; Thu, 20 Jun 2002 21:08:56 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5L48qk7012627 for ; Thu, 20 Jun 2002 21:08:52 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA19798 for ; Thu, 20 Jun 2002 21:08:57 -0700 (PDT) Received: from astro.cs.utk.edu ([160.36.58.43]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA04562 for ; Thu, 20 Jun 2002 21:08:56 -0700 (PDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5L48J203674; Fri, 21 Jun 2002 00:08:19 -0400 (EDT) Message-Id: <200206210408.g5L48J203674@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Richard Draves" cc: "Alain Durand" , ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-ietf-ipv6-default-addr-select-08.txt In-reply-to: (Your message of "Thu, 20 Jun 2002 20:23:44 PDT.") <7695E2F6903F7A41961F8CF888D87EA8063CED6E@red-msg-06.redmond.corp.microsoft.com> Date: Fri, 21 Jun 2002 00:08:19 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The reason for having the explicit escape clause is that this rule has > been the subject of much discussion in the WG & IESG; some feel that > privacy is the overriding concern and some feel that application > compatibility is more important. We have a rough consensus to favor > application compatibility by default. But as a member of the privacy > camp, I think it's helpful to remind implementors that if in their > particular circumstances privacy is more important than app > compatibility, then they can prefer temporary addresses by default. the point is that the host implementation is almost the worst possible place to override that default. the app knows what kind of addresses it needs, so it is in a good position to make such decisions. the user understands his own need for privacy, but he probably doesn't understand the implications of such a decision for his apps, so he's not in the best position. the host implementor knows even less than the user - unless you are talking about appliance hosts cannot be programmed by the user. in the latter situation the app implementor and the host implementor can be considered the same, and it's as easy for the app to select the proper kind of address than for the host implementor to do so. so I can really find no clear case for having the host implementor change the default. as you say, the SHOULD clause already allows an escape in the case where the host implementor clearly understands the implications of the decision - though that tends to require the host implementor to understand what apps will be run on the host, since the implications will vary from one app to another. on the other hand the MAY clause doesn't require the host implementor to understand those implications. it would therefore be better to remove the MAY clause entirely. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 20 21:28:42 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5L4Sfk7012670; Thu, 20 Jun 2002 21:28:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5L4Sf3D012669; Thu, 20 Jun 2002 21:28:41 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5L4Sck7012662 for ; Thu, 20 Jun 2002 21:28:38 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA16510 for ; Thu, 20 Jun 2002 21:28:42 -0700 (PDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA19097 for ; Thu, 20 Jun 2002 22:28:42 -0600 (MDT) Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 20 Jun 2002 21:28:41 -0700 Received: from 157.54.8.109 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 20 Jun 2002 21:28:41 -0700 Received: from red-msg-06.redmond.corp.microsoft.com ([157.54.12.71]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 20 Jun 2002 21:28:41 -0700 x-mimeole: Produced By Microsoft Exchange V6.0.6177.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: I-D ACTION:draft-ietf-ipv6-default-addr-select-08.txt Date: Thu, 20 Jun 2002 21:28:40 -0700 Message-ID: <7695E2F6903F7A41961F8CF888D87EA8063CED6F@red-msg-06.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-ietf-ipv6-default-addr-select-08.txt Thread-Index: AcIY2Ui6yNl703alT0+nVH3eDLasmQAAYSwQ From: "Richard Draves" To: "Keith Moore" Cc: "Alain Durand" , X-OriginalArrivalTime: 21 Jun 2002 04:28:41.0243 (UTC) FILETIME=[1F0A36B0:01C218DC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5L4Sck7012663 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > the point is that the host implementation is almost the worst possible > place to override that default. the app knows what kind of > addresses > it needs, so it is in a good position to make such decisions. the > user understands his own need for privacy, but he probably doesn't > understand the implications of such a decision for his apps, > so he's not in the best position. the host implementor knows > even less than the user - unless you are talking about > appliance hosts cannot be programmed by the user. in the > latter situation the app implementor and the host implementor > can be considered the same, and it's as easy for the app to > select the proper kind of address than for the host > implementor to do so. I agree that the app is in the best position - hence the change in 08 to require the API to give the app the tools to make a decision. It sounds like you agree with that. The question is what to do when the app hasn't made a decision. There's more than one kind of bug. Having an app break because it chose an address that expires in a week is a bug. Having an app compromise a user's privacy is also a bug. The implementor must consider what kind of bug is more important to their user community, how many apps are not using the API to make a decision, what are the relative likelihoods of a problem, etc. > as you say, the SHOULD clause already allows an escape in the > case where the host implementor clearly understands the > implications of the decision - though that tends to require > the host implementor to understand what apps will be run on > the host, since the implications will vary from one app to another. > > on the other hand the MAY clause doesn't require the host > implementor to understand those implications. it would > therefore be better to > remove the MAY clause entirely. The MAY clause is not intended to let implementors prefer temporary addresses without understanding the implications. The paragraph containing the MAY discusses the implications. Perhaps you would be more comfortable if it were "may" instead of "MAY"? 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 Jun 20 21:40:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5L4ebk7012703; Thu, 20 Jun 2002 21:40:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5L4ebqe012702; Thu, 20 Jun 2002 21:40:37 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5L4eXk7012695 for ; Thu, 20 Jun 2002 21:40:33 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA25117 for ; Thu, 20 Jun 2002 21:40:37 -0700 (PDT) Received: from astro.cs.utk.edu ([160.36.58.43]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA22336; Thu, 20 Jun 2002 22:40:37 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5L4dt203754; Fri, 21 Jun 2002 00:39:55 -0400 (EDT) Message-Id: <200206210439.g5L4dt203754@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Richard Draves" cc: "Keith Moore" , "Alain Durand" , ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-ietf-ipv6-default-addr-select-08.txt In-reply-to: (Your message of "Thu, 20 Jun 2002 21:28:40 PDT.") <7695E2F6903F7A41961F8CF888D87EA8063CED6F@red-msg-06.redmond.corp.microsoft.com> Date: Fri, 21 Jun 2002 00:39:55 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > the point is that the host implementation is almost the worst possible > > place to override that default. the app knows what kind of > > addresses > > it needs, so it is in a good position to make such decisions. the > > user understands his own need for privacy, but he probably doesn't > > understand the implications of such a decision for his apps, > > so he's not in the best position. the host implementor knows > > even less than the user - unless you are talking about > > appliance hosts cannot be programmed by the user. in the > > latter situation the app implementor and the host implementor > > can be considered the same, and it's as easy for the app to > > select the proper kind of address than for the host > > implementor to do so. > > I agree that the app is in the best position - hence the change in 08 to > require the API to give the app the tools to make a decision. It sounds > like you agree with that. yes. > The question is what to do when the app hasn't made a decision. the host has no way of knowing that, since the way that apps have traditionally (for the past 20 years) asked for a stable address was by listening on a port or establishing a connection - because stable addresses were (until recently) all that was available. > There's > more than one kind of bug. Having an app break because it chose an > address that expires in a week is a bug. Having an app compromise a > user's privacy is also a bug. right, but surely you're familiar with the phenomenon that a significant percentage of bug fixes cause multiple bugs, often because the "fix" makes unwarranted assumptions. to fix the bugs in apps that compromise users' privacy without creating lots of new bugs in the process you have to fix those apps. you can't do it in the host. > The implementor must consider what kind of > bug is more important to their user community, how many apps are not > using the API to make a decision, what are the relative likelihoods of a > problem, etc. the host implementor is generally not in a good position to consider such issues or to make such decisions. this is particularly true for a host implementation that is used for diverse purposes. > > as you say, the SHOULD clause already allows an escape in the > > case where the host implementor clearly understands the > > implications of the decision - though that tends to require > > the host implementor to understand what apps will be run on > > the host, since the implications will vary from one app to another. > > > > on the other hand the MAY clause doesn't require the host > > implementor to understand those implications. it would > > therefore be better to > > remove the MAY clause entirely. > > The MAY clause is not intended to let implementors prefer temporary > addresses without understanding the implications. The paragraph > containing the MAY discusses the implications. Perhaps you would be more > comfortable if it were "may" instead of "MAY"? no, because the MAY (or may) clause incorrectly implies that host implementors are in a good position to make such a decision. they're not. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 20 22:03:16 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5L53Gk7012782; Thu, 20 Jun 2002 22:03:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5L53FQv012781; Thu, 20 Jun 2002 22:03:15 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5L53Ck7012774 for ; Thu, 20 Jun 2002 22:03:12 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA22642 for ; Thu, 20 Jun 2002 22:03:17 -0700 (PDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA27971 for ; Thu, 20 Jun 2002 23:03:16 -0600 (MDT) Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 20 Jun 2002 22:03:14 -0700 Received: from 157.54.6.197 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 20 Jun 2002 22:03:16 -0700 Received: from red-msg-06.redmond.corp.microsoft.com ([157.54.12.71]) by inet-hub-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 20 Jun 2002 22:03:16 -0700 x-mimeole: Produced By Microsoft Exchange V6.0.6177.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: I-D ACTION:draft-ietf-ipv6-default-addr-select-08.txt Date: Thu, 20 Jun 2002 22:03:15 -0700 Message-ID: <7695E2F6903F7A41961F8CF888D87EA8063CED70@red-msg-06.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-ietf-ipv6-default-addr-select-08.txt Thread-Index: AcIY3bI/q8aKhLT0Rw2HuXmoVd6n+gAAiWlA From: "Richard Draves" To: "Keith Moore" Cc: "Alain Durand" , X-OriginalArrivalTime: 21 Jun 2002 05:03:16.0061 (UTC) FILETIME=[F3BA50D0:01C218E0] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5L53Dk7012775 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > no, because the MAY (or may) clause incorrectly implies that host > implementors are in a good position to make such a decision. > they're not. I'm not saying the host implementor is in a good position. I'm saying that if the app (or anybody else) hasn't made a decision, then the host implemention needs to have *some* default behavior. That's what the spec is about - default behavior. It's about making the best of bad situations - what to do when you have to choose between an address of the wrong scope and a deprecated address, etc, etc. In this case, the host implementor is choosing to prioritize one kind of bug (privacy) vs another (app-compat). The spec says we believe the host implementor SHOULD prefer public addresses, reflecting our rough consensus that app-compat is more important than privacy. But I want it to be clearly stated that in some circumstances an implementor may decide that privacy is more important than app-compat. This language is a compromise to a controversial issue, so if we're all unhappy with the outcome then it's good. :-) 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 Jun 20 22:11:14 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5L5BEk7012811; Thu, 20 Jun 2002 22:11:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5L5BESu012810; Thu, 20 Jun 2002 22:11:14 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5L5BAk7012803 for ; Thu, 20 Jun 2002 22:11:10 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA23893 for ; Thu, 20 Jun 2002 22:11:15 -0700 (PDT) Received: from astro.cs.utk.edu ([160.36.58.43]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA26111 for ; Thu, 20 Jun 2002 22:11:14 -0700 (PDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5L5BC203908; Fri, 21 Jun 2002 01:11:12 -0400 (EDT) Message-Id: <200206210511.g5L5BC203908@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Richard Draves" cc: "Keith Moore" , "Alain Durand" , ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-ietf-ipv6-default-addr-select-08.txt In-reply-to: (Your message of "Thu, 20 Jun 2002 22:03:15 PDT.") <7695E2F6903F7A41961F8CF888D87EA8063CED70@red-msg-06.redmond.corp.microsoft.com> Date: Fri, 21 Jun 2002 01:11:12 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > no, because the MAY (or may) clause incorrectly implies that host > > implementors are in a good position to make such a decision. > > they're not. > > I'm not saying the host implementor is in a good position. I'm saying > that if the app (or anybody else) hasn't made a decision, but you have no way of knowing whether the app has made that decision. neither does the host. we have a clear consensus to not change the existing API behavior, which assumes stable addresses by default, and this implies that an app can 'choose' a stable address merely by not taking any special action. this is as it should be. > In this case, the > host implementor is choosing to prioritize one kind of bug (privacy) vs > another (app-compat). host implementors have no business making such decisions. or at least, IETF shouldn't endorse such brain-damage if they do. > But I want it to be clearly > stated that in some circumstances an implementor may decide that privacy > is more important than app-compat. yes I understand what you want. and it's simply unacceptable. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 20 22:31:18 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5L5VIk7012860; Thu, 20 Jun 2002 22:31:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5L5VHQs012859; Thu, 20 Jun 2002 22:31:17 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5L5VEk7012852 for ; Thu, 20 Jun 2002 22:31:14 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA27451 for ; Thu, 20 Jun 2002 22:31:19 -0700 (PDT) Received: from mail6.microsoft.com (mail6.microsoft.com [131.107.3.126]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA05788 for ; Thu, 20 Jun 2002 23:31:19 -0600 (MDT) Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 20 Jun 2002 22:31:18 -0700 Received: from 157.54.5.25 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 20 Jun 2002 22:31:18 -0700 Received: from red-msg-06.redmond.corp.microsoft.com ([157.54.12.71]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 20 Jun 2002 22:31:17 -0700 x-mimeole: Produced By Microsoft Exchange V6.0.6177.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: I-D ACTION:draft-ietf-ipv6-default-addr-select-08.txt Date: Thu, 20 Jun 2002 22:31:17 -0700 Message-ID: <7695E2F6903F7A41961F8CF888D87EA8063CED71@red-msg-06.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-ietf-ipv6-default-addr-select-08.txt Thread-Index: AcIY4hHu4SOJLseZQqu7YN9NjG7P3QAAfJXA From: "Richard Draves" To: "Keith Moore" Cc: "Alain Durand" , X-OriginalArrivalTime: 21 Jun 2002 05:31:17.0995 (UTC) FILETIME=[DE3D13B0:01C218E4] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5L5VFk7012853 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > but you have no way of knowing whether the app has made that > decision. > neither does the host. we have a clear consensus to not change the > existing API behavior, which assumes stable addresses by > default, and this implies that an app can 'choose' a stable > address merely by not taking any special action. this is as > it should be. The IETF does not standardize APIs and it's perfectly OK for different implementations to have different APIs with different assumptions about address stability. RFC 2553 is Informational. > > In this case, the > > host implementor is choosing to prioritize one kind of bug > (privacy) > > vs another (app-compat). > > host implementors have no business making such decisions. or > at least, IETF shouldn't endorse such brain-damage if they do. The host implementor *must* make a decision about what to do when there is no input to override the implementation's default behavior. > > But I want it to be clearly > > stated that in some circumstances an implementor may decide that > > privacy is more important than app-compat. > > yes I understand what you want. and it's simply unacceptable. I guess this consensus will be more rough than most. :-) 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 Jun 20 23:13:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5L6Dfk7012971; Thu, 20 Jun 2002 23:13:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5L6De8o012970; Thu, 20 Jun 2002 23:13:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5L6Dak7012963 for ; Thu, 20 Jun 2002 23:13:37 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA10553 for ; Thu, 20 Jun 2002 23:13:42 -0700 (PDT) Received: from astro.cs.utk.edu ([160.36.58.43]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA15278 for ; Thu, 20 Jun 2002 23:13:41 -0700 (PDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5L6D4203984; Fri, 21 Jun 2002 02:13:04 -0400 (EDT) Message-Id: <200206210613.g5L6D4203984@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Richard Draves" cc: "Keith Moore" , "Alain Durand" , ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-ietf-ipv6-default-addr-select-08.txt In-reply-to: (Your message of "Thu, 20 Jun 2002 22:31:17 PDT.") <7695E2F6903F7A41961F8CF888D87EA8063CED71@red-msg-06.redmond.corp.microsoft.com> Date: Fri, 21 Jun 2002 02:13:04 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > but you have no way of knowing whether the app has made that > > decision. > > neither does the host. we have a clear consensus to not change the > > existing API behavior, which assumes stable addresses by > > default, and this implies that an app can 'choose' a stable > > address merely by not taking any special action. this is as > > it should be. > > The IETF does not standardize APIs As a categorical statement, this is wrong. The IETF can and does sometimes standardize APIs, it's just that the IETF emphasizes interoperability at the "bits on the wire" level rather than at the API level. this is both because experience indicates that API-level standards aren't sufficient to allow different implementations to interoperate, and because there's no need to insist that everyone use the same API - it actually degrades interoperability to do so. > and it's perfectly OK for different > implementations to have different APIs with different assumptions about > address stability. I agree with this part. If you want to design a new API in which the default behavior is to assign a temporary address and apps have to ask for a stable address, I have no problem with that. However, I have a big problem with this document saying it's okay to change the behavior of existing APIs to assign temporary addresses to apps that were designed and coded to expect stable addresses. > > host implementors have no business making such decisions. or > > at least, IETF shouldn't endorse such brain-damage if they do. > > The host implementor *must* make a decision about what to do when there > is no input to override the implementation's default behavior. That's a cumbersome statement; it's like saying tha the host implementor must have a default behavior when the default behavior isn't specified. A simpler but equivalent statement is that there must be a default behavior for any option for which the API doesn't force an explicit choice. That's true on its face, but it really doesn't illuminate the quesiton. The real question is whether this document should endorse the idea that the host can change existing APIs in such a way that it may alter the behavior of programs written to those APIs. The only reasonable answer is "no". Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 20 23:23:12 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5L6NCk7013010; Thu, 20 Jun 2002 23:23:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5L6NC1E013009; Thu, 20 Jun 2002 23:23:12 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5L6N9k7013002 for ; Thu, 20 Jun 2002 23:23:09 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA25996 for ; Thu, 20 Jun 2002 23:23:14 -0700 (PDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA20579 for ; Fri, 21 Jun 2002 00:23:14 -0600 (MDT) Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 20 Jun 2002 23:23:08 -0700 Received: from 157.54.8.23 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 20 Jun 2002 23:23:10 -0700 Received: from red-msg-06.redmond.corp.microsoft.com ([157.54.12.71]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 20 Jun 2002 23:23:09 -0700 x-mimeole: Produced By Microsoft Exchange V6.0.6177.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: I-D ACTION:draft-ietf-ipv6-default-addr-select-08.txt Date: Thu, 20 Jun 2002 23:23:08 -0700 Message-ID: <7695E2F6903F7A41961F8CF888D87EA8063CED73@red-msg-06.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-ietf-ipv6-default-addr-select-08.txt Thread-Index: AcIY6rroEmiDyfXqRhyZgZE9+fvZDgAAL5TA From: "Richard Draves" To: "Keith Moore" Cc: "Alain Durand" , X-OriginalArrivalTime: 21 Jun 2002 06:23:09.0887 (UTC) FILETIME=[1D121CF0:01C218EC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5L6N9k7013003 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The real question is whether this document should endorse the > idea that the > host can change existing APIs in such a way that it may alter > the behavior of programs written to those APIs. The only > reasonable answer is "no". And in fact, the document recommends (the SHOULD part) the "no" answer. But I think there will be circumstances in which an implementor could reasonably conclude to give priority to privacy over app-compat, and the "escape clause" is really just pointing out the right to make an informed decision that the implementor has anyway. 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 Jun 20 23:29:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5L6T9k7013045; Thu, 20 Jun 2002 23:29:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5L6T95I013044; Thu, 20 Jun 2002 23:29:09 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5L6T5k7013037 for ; Thu, 20 Jun 2002 23:29:05 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA27377 for ; Thu, 20 Jun 2002 23:29:10 -0700 (PDT) Received: from astro.cs.utk.edu ([160.36.58.43]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA19583 for ; Fri, 21 Jun 2002 00:29:09 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5L6SV204058; Fri, 21 Jun 2002 02:28:31 -0400 (EDT) Message-Id: <200206210628.g5L6SV204058@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Richard Draves" cc: "Keith Moore" , "Alain Durand" , ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-ietf-ipv6-default-addr-select-08.txt In-reply-to: (Your message of "Thu, 20 Jun 2002 23:23:08 PDT.") <7695E2F6903F7A41961F8CF888D87EA8063CED73@red-msg-06.redmond.corp.microsoft.com> Date: Fri, 21 Jun 2002 02:28:31 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > The real question is whether this document should endorse the > > idea that the > > host can change existing APIs in such a way that it may alter > > the behavior of programs written to those APIs. The only > > reasonable answer is "no". > > And in fact, the document recommends (the SHOULD part) the "no" answer. > But I think there will be circumstances in which an implementor could > reasonably conclude to give priority to privacy over app-compat, and the > "escape clause" is really just pointing out the right to make an > informed decision that the implementor has anyway. the implementor can do whatever it wants, whether or not it conforms to the standard. but it's not IETF's job to endorse implementors' poor decisions. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 20 23:29:51 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5L6Tok7013064; Thu, 20 Jun 2002 23:29:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5L6Tohr013063; Thu, 20 Jun 2002 23:29:50 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5L6Tjk7013056 for ; Thu, 20 Jun 2002 23:29:46 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA12339 for ; Thu, 20 Jun 2002 23:29:51 -0700 (PDT) Received: from astro.cs.utk.edu ([160.36.58.43]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA09140; Fri, 21 Jun 2002 00:32:07 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5L6Tm204100; Fri, 21 Jun 2002 02:29:48 -0400 (EDT) Message-Id: <200206210629.g5L6Tm204100@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Richard Draves" cc: "Keith Moore" , "Alain Durand" , ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-ietf-ipv6-default-addr-select-08.txt In-reply-to: (Your message of "Thu, 20 Jun 2002 22:03:15 PDT.") <7695E2F6903F7A41961F8CF888D87EA8063CED70@red-msg-06.redmond.corp.microsoft.com> Date: Fri, 21 Jun 2002 02:29:48 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > This language is a compromise to a controversial issue, so if we're all > unhappy with the outcome then it's good. :-) sorry, that doesn't follow. and it's not true. why in the world do you keep insisting that IETF endorse an implementor's decision to break applications? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 20 23:36:57 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5L6auk7013101; Thu, 20 Jun 2002 23:36:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5L6auwj013100; Thu, 20 Jun 2002 23:36:56 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5L6aqk7013093 for ; Thu, 20 Jun 2002 23:36:52 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA14624 for ; Thu, 20 Jun 2002 23:36:55 -0700 (PDT) Received: from astro.cs.utk.edu ([160.36.58.43]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA23397; Thu, 20 Jun 2002 23:36:55 -0700 (PDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5L6aD204147; Fri, 21 Jun 2002 02:36:13 -0400 (EDT) Message-Id: <200206210636.g5L6aD204147@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Richard Draves" cc: "Keith Moore" , "Alain Durand" , ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-ietf-ipv6-default-addr-select-08.txt In-reply-to: (Your message of "Thu, 20 Jun 2002 23:23:08 PDT.") <7695E2F6903F7A41961F8CF888D87EA8063CED73@red-msg-06.redmond.corp.microsoft.com> Date: Fri, 21 Jun 2002 02:36:13 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk one more thing: > But I think there will be circumstances in which an implementor could > reasonably conclude to give priority to privacy over app-compat, and the > "escape clause" is really just pointing out the right to make an > informed decision that the implementor has anyway. it's impossible for the host implementor is able to make an "informed decision" about the needs of apps that aren't chosen by the host implementor. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 20 23:45:02 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5L6j2k7013184; Thu, 20 Jun 2002 23:45:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5L6j1LU013183; Thu, 20 Jun 2002 23:45:01 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5L6itk7013176 for ; Thu, 20 Jun 2002 23:44:55 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA21795 for ; Thu, 20 Jun 2002 23:44:59 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA08231 for ; Fri, 21 Jun 2002 00:44:57 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id 957426A904; Fri, 21 Jun 2002 09:44:41 +0300 (EEST) Received: from ericsson.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 456FD6A901; Fri, 21 Jun 2002 09:44:40 +0300 (EEST) Message-ID: <3D12CBAD.50002@ericsson.fi> Date: Fri, 21 Jun 2002 09:46:05 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Adam Machalek Cc: ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-ietf-ipv6-node-requirements-00.txt References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Adam Machalek wrote: > While it is clearly defined in the text of the draft, I would have > appreciated an Appendix with nothing more then a list of the relevent > RFCs/Drafts grouped into those 3 catagories. I agree. [If there is a special case where an RFC has parts that belong to different categories, we can list them as "RFC nnnn (partially)" on those categories.] Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 21 00:48:34 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5L7mYk7013309; Fri, 21 Jun 2002 00:48:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5L7mYaU013308; Fri, 21 Jun 2002 00:48:34 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5L7mVk7013301 for ; Fri, 21 Jun 2002 00:48:31 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA13766 for ; Fri, 21 Jun 2002 00:48:35 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.96.3]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA21704 for ; Fri, 21 Jun 2002 00:48:31 -0700 (PDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g5L7lhM21300; Fri, 21 Jun 2002 14:47:44 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g5L7lAE07151; Fri, 21 Jun 2002 14:47:11 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Keith Moore cc: "Richard Draves" , ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-ietf-ipv6-default-addr-select-08.txt In-Reply-To: <200206210007.g5L07X202749@astro.cs.utk.edu> References: <200206210007.g5L07X202749@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 21 Jun 2002 14:47:10 +0700 Message-ID: <7149.1024645630@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 20 Jun 2002 20:07:33 -0400 From: Keith Moore Message-ID: <200206210007.g5L07X202749@astro.cs.utk.edu> | I don't think it's reasonable to allow host implementations to reverse | this default - this will break apps. This cannot possibly be true, as all addresses are temporary in the current environment (all globals anyway). The only difference is in their expected duration. So, to work at all, all apps always need to work with temporary addresses, as that's all they're ever going to get. I like the current default of preferring "normal" addresses over 3041 addrs, and I certainly see no problem with an application toggle to change that. But nor do I see any problem with a per system toggle. Eg: on my laptop, which is rarely turned on for more than 24 hours, hence no app survives longer than that, a 3041 address (default timers) is exactly as stable as a global address, and if I wanted, I see no reason that I shouldn't make all apps default to using them (without having to recompile every one). 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 Fri Jun 21 00:56:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5L7uOk7013335; Fri, 21 Jun 2002 00:56:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5L7uNTE013334; Fri, 21 Jun 2002 00:56:23 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5L7uKk7013327 for ; Fri, 21 Jun 2002 00:56:20 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA15376 for ; Fri, 21 Jun 2002 00:56:25 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.96.3]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA22700 for ; Fri, 21 Jun 2002 00:56:05 -0700 (PDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g5L7tDM26305; Fri, 21 Jun 2002 14:55:16 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g5L7sWE07175; Fri, 21 Jun 2002 14:54:44 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Margaret Wasserman cc: ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-Reply-To: <4.2.2.20020619092327.022a1d60@mail.windriver.com> References: <4.2.2.20020619092327.022a1d60@mail.windriver.com> <200206181540.g5IFecY19885@astro.cs.utk.edu> <200206181540.g5IFecY19885@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 21 Jun 2002 14:54:32 +0700 Message-ID: <7173.1024646072@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 19 Jun 2002 09:32:10 -0400 From: Margaret Wasserman Message-ID: <4.2.2.20020619092327.022a1d60@mail.windriver.com> | If site-local addressing is "really insurance", and may "fade away" later, | would this be an argument for: | | - Moving site-local out of the base IPv6 specs No, insurance is only useful if you have it from the start. Planning to leave it in the background, and then pay for it after things break simply doesn't work... | - Making site-local implementation optional? That one I have no problem with. If implementations don't want to bother with it, or with all the possible ways they can be used (mult-site nodes, etc) that's just fine. For some uses I would have no problems using nodes that don't support SL addressing, for others, such an implementation would rule itself out of contention immediately. On the other actually requiring multi-site nodes is something that I might never need (and very few sites might) so that one might become more of a speciality item. kre ps: I also agree with (I think) everthing that is in Tim Hartrick's 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 Fri Jun 21 01:24:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5L8O7k7013501; Fri, 21 Jun 2002 01:24:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5L8O76m013500; Fri, 21 Jun 2002 01:24:07 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5L8O4k7013493 for ; Fri, 21 Jun 2002 01:24:04 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA01894 for ; Fri, 21 Jun 2002 01:24:09 -0700 (PDT) Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.211]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA20290 for ; Fri, 21 Jun 2002 02:26:25 -0600 (MDT) Received: from tarski.cs.uni-bonn.de (tarski.cs.uni-bonn.de [131.220.4.200]) by theory.cs.uni-bonn.de (8.9.1a/8.9.1) with ESMTP id KAA27255 for ; Fri, 21 Jun 2002 10:24:06 +0200 (MET DST) Received: (from ignatios@localhost) by tarski.cs.uni-bonn.de (8.9.1a/8.9.1) id KAA06812 for ipng@sunroof.eng.sun.com; Fri, 21 Jun 2002 10:23:20 +0200 (CEST) Date: Fri, 21 Jun 2002 10:23:20 +0200 From: Ignatios Souvatzis To: ipng@sunroof.eng.sun.com Subject: Re: IESG comments on draft-ietf-ipngwg-default-addr-select-06.txt Message-ID: <20020621102320.A6630@tarski.cs.uni-bonn.de> References: <200206132001.g5DK1SY07170@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="jI8keyz6grp/JLjh" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from alh-ietf@tndh.net on Thu, Jun 13, 2002 at 03:37:29PM -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --jI8keyz6grp/JLjh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hello, On Thu, Jun 13, 2002 at 03:37:29PM -0700, Tony Hain wrote: > Any app that doesn't need a forward or reverse record in DNS will work > with a private address, why do they need a special API. What you are > looking for is a simple way during address selection to know which > address is recorded in DNS. Thats not true. Applications that need an identified source address (or their peer that requires to see an identified destination address) won't work with temporary addresses - unless you give the whole /64 prefix the same IPSEC identification, in which case doing so is mostly useless. This is independent of DNS. Regards, -is --jI8keyz6grp/JLjh Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: 2.6.i iQEVAgUBPRLidTCn4om+4LhpAQHcqwf+MMeTUGS7nILAwYSvbUxeh4Jw7FapVRj1 gvY09Eca1S+JPKRq6hGmzNT+Zv/DoxI6lOgJ7yLVbCBG2/fTt1GXFRWegkKbmDrU XUrAgM+VPnMNvSPup7TUH5h/jbIA7XmcB1fnT6Bbq/r2B0uAbtX+6Nocz6c4BNd3 tyAuWSr42RurMtk87uZFBZ4dPdwVeAUBbs0Hg9SXKiqsH1+6fSTqkCJmLhIsnose N57qCwy5LsNcHkSZp6T1hXcbTBMEYRoLgzn4owfZGLQm5+hrJByKBsJsyGrEnDXs E/a9OUXZ6JHxU030sQtWO+mOxIDAgSU/yIZv0M90GP3dLxa+TyhYlQ== =6NMf -----END PGP SIGNATURE----- --jI8keyz6grp/JLjh-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 21 01:25:01 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5L8P1k7013511; Fri, 21 Jun 2002 01:25:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5L8Op1s013510; Fri, 21 Jun 2002 01:24:51 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5L8Omk7013503 for ; Fri, 21 Jun 2002 01:24:48 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA21896 for ; Fri, 21 Jun 2002 01:24:53 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.96.3]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA04484 for ; Fri, 21 Jun 2002 01:24:22 -0700 (PDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g5L8NIM17874; Fri, 21 Jun 2002 15:23:19 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g5L8MiE07215; Fri, 21 Jun 2002 15:22:44 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Keith Moore cc: Bill Fenner , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-Reply-To: <200206191507.g5JF7AK15279@astro.cs.utk.edu> References: <200206191507.g5JF7AK15279@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 21 Jun 2002 15:22:44 +0700 Message-ID: <7213.1024647764@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 19 Jun 2002 11:07:10 -0400 From: Keith Moore Message-ID: <200206191507.g5JF7AK15279@astro.cs.utk.edu> | but it depends to some degree on how LL is pitched to the public. Yes, exactly - and one of its planned uses (right from day 1) was to support "dentist office" networks - perhaps more likely these days as "IETF attendees on a bus" (not a plane as using 802.11 there is probably frowned upon, I haven't risked trying it to see if anyone would notice...) who just happen to create an ad-hoc network, with no external support at all. | I don't think use of LL by apps is a good idea for either v4 or v6. To eliminate this completely, you need to find a way to assign a global address with no delay (no more than a minute anyway) and no network connectivity required to obtain it. I think that means a well known prefix - which is exactly what the SL prefix is. So if you really want to prevent this usage of LL's, I think you not only have to support SL addresses - but actually make implementation of them mandatory. I'd just keep SL support optional (require as little as possible) and have the apps deal with LL addresses when the situation arises. | the danger is that SL addrs are clearly meant for use by apps, while | it can be argued that LLs aren't meant for GP use. You could try arguing that, but you'd be arguing against the design. | ISPs that pull that kind of stunt deserve to go out of business quickly. Unfortunately, that requires the customers to desert, quickly, which requires yet another renumbering. And remember, that while an ISP could do this as a stunt, the more likely cause is going to be the network (via a nanog or similar meeting) deciding that the routing table is simply getting too big, too fast, and that some realigning of addresses is required to allow topological aggregation to work again with the network configured in the state that it has developed into at the time. That is, it isn't a "stunt". And while you can argue that such a change should be properly planned, my counter is that no amount of proper planning is sufficient - I want connections to be able to exist where the address will *never* change (other than at my specific demand - no-one else can ever instigate it). | to some degree this is govered by public perception about what is | reasonable, and such perception can be influenced by standards. | so we do have some influence here. we should try to use it. Yes. To do that in an honest way, we first need to decide how to avoid requiring addresses with either topological or geographical significance (both of which require renumbering sometimes). The original (70's-80's) IP allocation scheme would be OK (allocate 1 2 3 4 ... to however asks in the order they ask). Just make routing work with that. Or, propose something else. | there's no way to absolutely | prevent brain-damage like unannounced renumbering, I am not worried about unannounced renumbering, but *any* renumbering. Announced 5 years in advance or not... | easiest way to fix this is to have NFS (and those other apps) use mobile IP. Doesn't work. That requires a stable address to use as the home agent. And if the net has been renumbered, the stable address doesn't work. If we had designed good EIDs instead of just having addresses, then mobile IP would have been almost a no-brainer. (And so would renumbering, mobile-IP then just treated as one reason for renumbering). But we didn't, and now mobile-IP depends upon stable addresses just like everything else (it trades off one stable address for another). | I don't think it flies as long as we're requiring sites to connect | to the public net to get global addresses, and some sites don't want to | connect to the public net at all. Hmm - maybe I'm not being clear, or you just missed my point. No requirement for a site to connect to the public net, certainly. A site that isn't connected just uses SL addresses as if they were global addresses (they go in its disconnected DNS - or however it does address lookups) and are used exactly like anyone else would use a global address. The site boundaries are the ends of the net as we know it, so there's no magic at all here. To allow two disconnected sites to communicate, they need either global addresses (in which case they're just becoming another internet and as many sites as like, and are permitted, can connect to that, instead of the public net) or we need some kind of site ID in SL addresses (and in the latter case, they just go on acting as if they were global, in the former, SL's are the same as SL's on the public net, and there is a global address to use to make the SL's work). Groups of sites, talking to each other, but disconnected from the "one true internet" is something that the current addressing plans really haven't allowed for, and should. | with global non-routable addresses, the site-id is carried along with the | address, it's exposed as part of the address (assuming a reserved prefix | for such addresses), it's returned in the same kind of DNS RR that carries | a normal address. the address is globally scoped so there is no chance | of mistaking an address from a remote site as being one from a local site | or a different remote site. But there's no way to tell from the address that it is one that you cannot reach from outside, which makes it annoying (at best) to pass around. Of course, we could have such addresses marked by a magic prefix, that people could recognise. Then there'd be no problem. And of course, that is exactly what a SL address with a site-id in it is. (Note: I think I'm one of comparatively few people who actually support site-id's in SL addresses). | again, I don't think that flies. too many enterprise nets are not | connected to the public internet have no way to get globals. | in the current IPv6 view, they have no way to get global IPv6 addresses . See above. | even if they borrow a prefix from somewhere, those addresses won't | really be global in the sense that they're reachable from elsewhere. If the site is not connected, then "reachable from elsewhere" is a pretty meaningless concept. If a "borrowed" prefix is what it takes to make things work in some rare cases, then that's exactly what people will do. If renumbering out of it into a "proper" address is not too hard or disruptive, then they will do that too when they connect. But borrowed or a true advertised topological global address, wouldn't matter (in the very rare case that such a thing would be needed). | But it seems to me that if we do have these, we don't need SL anymore. We don't need SL with the bit pattern that we have, but non-routable global addresses would just be the same thing for most purposes (just avoid the scope issue in the API etc). So would SL's with site-id's. | perhaps (and I probably agree), but right now we're insisting on just | the opposite. You mean in IPv4? Yes, that need to be corrected. If you meant IPv6, then I don't understand what you're trying to say. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 21 01:25:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5L8POk7013521; Fri, 21 Jun 2002 01:25:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5L8POtX013520; Fri, 21 Jun 2002 01:25:24 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5L8PIk7013513 for ; Fri, 21 Jun 2002 01:25:18 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g5L8PIb25664; Fri, 21 Jun 2002 10:25:18 +0200 (MEST) Date: Fri, 21 Jun 2002 10:24:02 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Comments on draft-ietf-ipngwg-ipv6-anycast-analysis To: itojun@iijlab.net Cc: Erik Nordmark , ettikan.kandasamy.karuppiah@intel.com, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <20020620100940.8C83B4B24@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > as far as I remember from the past presentations, Hardie draft did > propose interdomain anycast scheme. the diagram in appendix A look > like intradomain, however, section 1.4 and 1.5 does not have any > restriction on intra/interdomain. the diagram I saw at dnsop meeting > was interdomain (single prefix advertised with a single AS #, from > multiple different location). The latter sounds like the Ohta draft. > >> distribution of servers is worldwide. BGP anycast is being used for > >> specific upper-layer protocols only, like DNS and HTTP. There is no > >Where is it being used for HTTP? The documents you cite talk about DNS > >and UDP exclusively. > > webserver for past olympic games. i don't have any citable document > on it. Was this usage interdomain or not? Perhaps there is some IBM reference (even if it is not stable) that can be added. Independent of that some more explanation of how it's been used with http would be helpful. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 21 01:40:23 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5L8eNk7013579; Fri, 21 Jun 2002 01:40:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5L8eNmQ013578; Fri, 21 Jun 2002 01:40:23 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5L8eJk7013571 for ; Fri, 21 Jun 2002 01:40:19 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA19275 for ; Fri, 21 Jun 2002 01:40:24 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA26131 for ; Fri, 21 Jun 2002 02:42:39 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id F1CC54B24; Fri, 21 Jun 2002 17:40:18 +0900 (JST) To: Erik Nordmark Cc: ettikan.kandasamy.karuppiah@intel.com, ipng@sunroof.eng.sun.com In-reply-to: Erik.Nordmark's message of Fri, 21 Jun 2002 10:24:02 +0200. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Comments on draft-ietf-ipngwg-ipv6-anycast-analysis From: itojun@iijlab.net Date: Fri, 21 Jun 2002 17:40:18 +0900 Message-Id: <20020621084019.F1CC54B24@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> as far as I remember from the past presentations, Hardie draft did >> propose interdomain anycast scheme. the diagram in appendix A look >> like intradomain, however, section 1.4 and 1.5 does not have any >> restriction on intra/interdomain. the diagram I saw at dnsop meeting >> was interdomain (single prefix advertised with a single AS #, from >> multiple different location). > >The latter sounds like the Ohta draft. it seemed to me Ohta draft and Hardie draft were exactly the same, modulo the usage policy of AS #s. also for me Hardie draft (now RFC) does not seem to put any restriction to be intradomain. it just doesn't say anything about intra/interdomain. >> webserver for past olympic games. i don't have any citable document >> on it. >Was this usage interdomain or not? >Perhaps there is some IBM reference (even if it is not stable) that can be >added. Independent of that some more explanation of how it's been used >with http would be helpful. interdomain. single prefix advertised with a single AS #, from multiple different location (route injected into multiple different ISPs). 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 Jun 21 01:40:50 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5L8enk7013589; Fri, 21 Jun 2002 01:40:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5L8enUA013588; Fri, 21 Jun 2002 01:40:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5L8ejk7013581 for ; Fri, 21 Jun 2002 01:40:45 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA24899 for ; Fri, 21 Jun 2002 01:40:50 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.96.3]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA08648 for ; Fri, 21 Jun 2002 01:40:46 -0700 (PDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g5L8dxM00993; Fri, 21 Jun 2002 15:39:59 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g5L8dRE07240; Fri, 21 Jun 2002 15:39:29 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: "Bound, Jim" cc: ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B020B8B15@tayexc13.americas.cpqcorp.net> References: <9C422444DE99BC46B3AD3C6EAFC9711B020B8B15@tayexc13.americas.cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 21 Jun 2002 15:39:27 +0700 Message-ID: <7238.1024648767@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 19 Jun 2002 17:41:13 -0400 From: "Bound, Jim" Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B8B15@tayexc13.americas.cpqcorp.net> | Site identification requires a site-zone-id to differenentiate fec0::1 | from fec0::1 on a node with two sites. Absolutely, as does link local for fe80::1 | Under the site-identifier for the two sites are local links that | also require zone ids for the link-locals. Yes, though I wouldn't say "under" (though I guess you can draw it like that). | So the structure for an interface requires site-zone-id and then | within each site link-local-zone ids. Not within - an interface has a site-zone-id and a link-zone-id yes (though an implementation could probably combine those into one number if it wanted to - treat the whole value as the link-zone-id, and some number of bits of it as the site-zone-id). | What I am saying is the site-id abstraction now requires another level | of indirection when determining which interface the packet should be sent No. If the address is link local, you have to consider the link-zone-id (and perhaps just that - depending upon the multi-interface link stuff). If the address is site-local you have to consider the site-zone-id, and the forwarding table. If it is global, you consider neither id, just the forwarding table. So, while there is a little bit of extra code involved here, the mechanisms to consider the zone-id, and the forwarding table, both already exist. | for interface data structures, Maybe one extra number. This I don't think counts as lots of extra overhead... | routing data structures, yes, routing is the one place where there is some extra work, but not anything extraordinarily difficult I don't think. | and tansport data structures. No, nothing needed there at all - there needs to be a zone-id field, but that's needed in case the transport is using LL addresses (like BGP). If it is using SL addresses, the same field can be used for the site-zone-id. | It also requires more intelligence for SCTP as example that uses addresses | as failover in this case. For site-local just the addresses is not enough | but also the site-id now. As would a fail-over to a LL address require the link-id. Nothing new added by SL's there. | Rather than debate site-local existence maybe it would be good to just get | consensus on their complexity and what they mean regarding added work for | implementations? Yes, if we could get consensus on that - but I would never set implementation work as the arbiter by which we decide upon what we include and what we exclude. If implementation work was the test, then nothing involving security would ever be implemented. Eg: look at the other discussion going on in this list (another discussion anyway) - related to securing neighbour discovery. Unless "do nothing" is the outcome from that, that's likely to require lots more implementation than anything related to SL's (even assuming the answer is just to use ESP or AH, assumed to already exist). | But as someone pointed out to me privately I don't want people printing | on my site printer from the Internet. That's probably true (though at Melbourne for a while we had a printer established precisely to allow people (anyone) to print from anywhere...) | So is it the job of the address type or the filters in IPv6 routing or | firewalls to prevent that? Firewalls absolutely. The "I can use SL addresses to restrict nodes so they can only be accessed locally" argument that is occasionally made seems to serve not much better purpose than be easy to show how flawed it is. Site local addresses are for address stability, not for security, information hiding, or any other dumb uses like that. 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 Fri Jun 21 03:31:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5LAV9k7013744; Fri, 21 Jun 2002 03:31:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5LAV83V013743; Fri, 21 Jun 2002 03:31:08 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5LAV5k7013736 for ; Fri, 21 Jun 2002 03:31:05 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA21994 for ; Fri, 21 Jun 2002 03:31:10 -0700 (PDT) From: john.loughney@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA21143 for ; Fri, 21 Jun 2002 03:31:09 -0700 (PDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g5LAVZi23061 for ; Fri, 21 Jun 2002 13:31:35 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 21 Jun 2002 13:31:08 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 21 Jun 2002 13:31:07 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2190E.C0B723C9" Subject: RE: I-D ACTION:draft-ietf-ipv6-node-requirements-00.txt Date: Fri, 21 Jun 2002 13:31:07 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC654CE@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-ietf-ipv6-node-requirements-00.txt Thread-Index: AcIYjq066SH3EItLQI+ORsIDtiANrQAf+6YA To: , X-OriginalArrivalTime: 21 Jun 2002 10:31:07.0917 (UTC) FILETIME=[C11153D0:01C2190E] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C2190E.C0B723C9 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Adam, =20 I agree. We are planning on doing that (I thought I put a placeholder = in the doc for this). I actually wanted to add this after we get some = feedback on the draft, just to ease document editing. =20 John -----Original Message----- From: ext Adam Machalek [mailto:Adam_Machalek@nmss.com] Sent: 20 June, 2002 22:12 To: ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-ietf-ipv6-node-requirements-00.txt My first comment is structural in nature. Six months ago when we = started our IPv6 implementation I spent several weeks wading through all = the IPv6 and NGTrans RFCs and drafts in order to catagorize them into = what this draft terms "unconditional manditory", "conditional = mandatory", and "unconditionally optional". From there we were able to = focus our effort. =20 While it is clearly defined in the text of the draft, I would have = appreciated an Appendix with nothing more then a list of the relevent = RFCs/Drafts grouped into those 3 catagories. =20 Adam Machalek ------_=_NextPart_001_01C2190E.C0B723C9 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi=20 Adam,
 
I=20 agree.  We are planning on doing that (I thought I put a = placeholder in the=20 doc for this).  I actually wanted to add this after we get some = feedback on=20 the draft, just to ease document editing.
 
John
-----Original Message-----
From: ext Adam Machalek=20 [mailto:Adam_Machalek@nmss.com]
Sent: 20 June, 2002=20 22:12
To: ipng@sunroof.eng.sun.com
Subject: Re: = I-D=20 = ACTION:draft-ietf-ipv6-node-requirements-00.txt


<= FONT=20 face=3Dsans-serif size=3D2>My first comment is structural in nature. =  Six=20 months ago when we started our IPv6 implementation I spent several = weeks=20 wading through all the IPv6 and NGTrans RFCs and drafts in order to = catagorize=20 them into what this draft terms "unconditional manditory", = "conditional=20 mandatory", and "unconditionally optional".  From there we were = able to=20 focus our effort.  

While it=20 is clearly defined in the text of the draft, I would have appreciated = an=20 Appendix with nothing more then a list of the relevent RFCs/Drafts = grouped=20 into those 3 catagories.  

Adam Machalek ------_=_NextPart_001_01C2190E.C0B723C9-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 21 04:36:57 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5LBavk7013920; Fri, 21 Jun 2002 04:36:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5LBavFc013919; Fri, 21 Jun 2002 04:36:57 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5LBark7013912 for ; Fri, 21 Jun 2002 04:36:53 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA13495 for ; Fri, 21 Jun 2002 04:36:58 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA12838 for ; Fri, 21 Jun 2002 04:36:58 -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 HAA07859; Fri, 21 Jun 2002 07:36:03 -0400 (EDT) Message-Id: <200206211136.HAA07859@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-ipv6-flow-label-02.txt Date: Fri, 21 Jun 2002 07:36:03 -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 IP Version 6 Working Group Working Group of the IETF. Title : IPv6 Flow Label Specification Author(s) : J. Rajahalme, A. Conta, B. Carpenter, S. Deering Filename : draft-ietf-ipv6-flow-label-02.txt Pages : 7 Date : 20-Jun-02 This document specifies the usage of the IPv6 Flow Label field, the requirements for IPv6 source nodes labeling flows, and the requirements for flow state establishment methods. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-flow-label-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipv6-flow-label-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-ipv6-flow-label-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: <20020620141448.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-flow-label-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-flow-label-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020620141448.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 21 06:48:02 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5LDm2k7014199; Fri, 21 Jun 2002 06:48:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5LDm26l014198; Fri, 21 Jun 2002 06:48:02 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5LDlxk7014191 for ; Fri, 21 Jun 2002 06:47:59 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA04874 for ; Fri, 21 Jun 2002 06:48:03 -0700 (PDT) Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA28505; Fri, 21 Jun 2002 07:48:02 -0600 (MDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5LDlscK045216; Fri, 21 Jun 2002 15:47:54 +0200 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with SMTP id g5LDls768802; Fri, 21 Jun 2002 15:47:54 +0200 Received: from gsine02.us.sine.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA28066 from ; Fri, 21 Jun 2002 15:47:51 +0200 Message-Id: <3D13234B.4A705A11@hursley.ibm.com> Date: Fri, 21 Jun 2002 14:59:55 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Keith Moore Cc: Richard Draves , Alain Durand , ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-ietf-ipv6-default-addr-select-08.txt References: <200206210613.g5L6D4203984@astro.cs.utk.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith Moore wrote: ... > > > > host implementors have no business making such decisions. or > > > at least, IETF shouldn't endorse such brain-damage if they do. > > > > The host implementor *must* make a decision about what to do when there > > is no input to override the implementation's default behavior. > > That's a cumbersome statement; it's like saying tha the host implementor > must have a default behavior when the default behavior isn't specified. > > A simpler but equivalent statement is that there must be a default > behavior for any option for which the API doesn't force an explicit choice. > That's true on its face, but it really doesn't illuminate the quesiton. > > The real question is whether this document should endorse the idea that the > host can change existing APIs in such a way that it may alter the behavior > of programs written to those APIs. The only reasonable answer is "no". The fact is that any implementation *will* have a default behavior in the case that an app ignores this whole issue, which will be the case for most apps when first ported to IPv6. The question for the IETF is whether we leave this open (thereby maximising chaos) or define a default (thereby reducing chaos). I think we need to define a default to reduce chaos. I'd argue that the only hosts likely to have temporary addresses are pure clients. Servers, or hosts trying to play in a genuine peer2peer world, will need permanent addresses anyway. Since we care about preserving client privacy, but presumably don't care about preserving server privacy, I'd argue for Rich's default, i.e. the document as it is. 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 Jun 21 07:51:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5LEp9k7014310; Fri, 21 Jun 2002 07:51:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5LEp8fa014309; Fri, 21 Jun 2002 07:51:08 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5LEp4k7014302 for ; Fri, 21 Jun 2002 07:51:05 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA19398 for ; Fri, 21 Jun 2002 07:51:09 -0700 (PDT) Received: from astro.cs.utk.edu ([160.36.58.43]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA28448 for ; Fri, 21 Jun 2002 08:53:27 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5LEjK208003; Fri, 21 Jun 2002 10:45:21 -0400 (EDT) Message-Id: <200206211445.g5LEjK208003@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Robert Elz cc: Keith Moore , "Richard Draves" , ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-ietf-ipv6-default-addr-select-08.txt In-reply-to: (Your message of "Fri, 21 Jun 2002 14:47:10 +0700.") <7149.1024645630@munnari.OZ.AU> Date: Fri, 21 Jun 2002 10:45:20 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Date: Thu, 20 Jun 2002 20:07:33 -0400 > From: Keith Moore > Message-ID: <200206210007.g5L07X202749@astro.cs.utk.edu> > > | I don't think it's reasonable to allow host implementations to reverse > | this default - this will break apps. > > This cannot possibly be true, as all addresses are temporary in the > current environment (all globals anyway). The only difference is in > their expected duration. true, it might be more precise to talk about the expected duration of addresses; all addresses are at least potentially 'temporary' in some sense. however we're using the term 'temporary addresses' as it's used in RFC 3041, rather than in the more general sense of the term 'temporary' > So, to work at all, all apps always need to work with temporary addresses, > as that's all they're ever going to get. that's rather unrealistic; the current architecture is nowhere close to supporting the ability of apps to survive arbitrary address changes. > I like the current default of preferring "normal" addresses over 3041 addrs, > and I certainly see no problem with an application toggle to change that. > But nor do I see any problem with a per system toggle. Eg: on my laptop, > which is rarely turned on for more than 24 hours, hence no app survives > longer than that, a 3041 address (default timers) is exactly as stable as > a global address, and if I wanted, I see no reason that I shouldn't make > all apps default to using them (without having to recompile every one). I have less problem with a per-system toggle that the user can set than with allowing the vendor to change the default. but the vast majority of users won't understand the implications of such a toggle, and implementors of apps for which temporary addresses are appropriate will find it easy to enable them. by the time your laptop's OS is upgraded to support temporary addresses, chances are that the apps will support them also... so I suspect that the main effect of a user-settable per-system toggle would be to cause more apps to break with little or no improvement in privacy. that and I think the SHOULD clause already allows vendors to change the default behavior (or to allow users to do so) when they fully understand the implications of that behavior. so the draft does not prohibit a vendor from putting such a toggle on your laptop OS, just as long as they explain the implicatoins of that behavior to you. however I think it would generally be a foolish thing for vendors to do (at least commercial vendors) as it would increase their support costs while providing little additional functionality to users. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 21 08:10:54 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5LFArk7014383; Fri, 21 Jun 2002 08:10:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5LFArFM014382; Fri, 21 Jun 2002 08:10:53 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5LFAok7014375 for ; Fri, 21 Jun 2002 08:10:50 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA12606 for ; Fri, 21 Jun 2002 08:10:55 -0700 (PDT) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA25389 for ; Fri, 21 Jun 2002 08:10:54 -0700 (PDT) Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 21 Jun 2002 08:10:50 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Message-ID: <2B81403386729140A3A899A8B39B046405E143@server2000.arneill-py.sacramento.ca.us> content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Fwd: IPv6 Scoped Addresses and Routing Protocols Thread-Index: AcIY/XP3IPhpH6QqShKTl95nLjEv+wANV55w From: "Michel Py" To: "Robert Elz" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5LFAok7014376 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > kre wrote: > (Note: I think I'm one of comparatively few people who actually > support site-id's in SL addresses). If I understand correctly, what you are advocating for is SL addresses that are globally unique (by using a mechanism such as embedding the ASN in the higher bits). Therefore, when two networks merge, they don't have to renumber one of them (which is what happens today when two networks using 192.168.0.0/16 merge). There is one thing that worries me about such a scheme: it does in fact give a PI address to everybody. It is to be feared that people using these addresses will make arrangements with their upstreams to have these leaked in the global table. Money talks. It will not be possible to technically prevent this, as the very purpose of site ids is to exchange routing info about SL addresses between two sites. In no time, this scheme could be extended to the entire Internet. What I don't like with side-ids in SL addresses is not that that they give a unique address to everyone, which is great; but that there is no control over how far the routing of these can go except "don't do it". I support having no site-ids in SL addresses. The fact that fec0::1 is pretty much like 192.168.1.1, called re-usability I think, is the only guarantee that SL addresses would not be perverted into unaggregatable PI. As I mentioned before, PA addresses alone are not a satisfactory solution. There is a need for some independent, globally unique addresses. I think that these addresses must be subject to a specific protocol, not a free-for-all ride. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 21 08:15:40 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5LFFdk7014440; Fri, 21 Jun 2002 08:15:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5LFFc46014436; Fri, 21 Jun 2002 08:15:38 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5LFFZk7014426 for ; Fri, 21 Jun 2002 08:15:35 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA13530 for ; Fri, 21 Jun 2002 08:15:30 -0700 (PDT) Received: from web20420.mail.yahoo.com (web20408.mail.yahoo.com [66.163.169.96]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id JAA08636 for ; Fri, 21 Jun 2002 09:15:29 -0600 (MDT) Message-ID: <20020621151529.36585.qmail@web20420.mail.yahoo.com> Received: from [12.234.194.61] by web20408.mail.yahoo.com via HTTP; Fri, 21 Jun 2002 08:15:29 PDT Date: Fri, 21 Jun 2002 08:15:29 -0700 (PDT) From: Tissa Senevirathne Subject: Re: ID on BGP extensions to Tag IPv6 routes that has IPv4 tunnels To: ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jerome et.al Hopefully it is readable this time.. Consider the following digram AS2 AS1. AS3 Site A | | Site B | | Relay A ----- | |---------- Relay B sites c,d,.... M Relays... c,d...Nn 1. If we the remote relay routers are across multiple AS . In such a case BGP NEXT_HOP attribute would not represent the IP address of the relay routers. 2. In general, and most commonly, remote relay sites may not be known in advance and there can be multiple of such sites. In this case explicit peering and thus use of BGP NEXT_HOP attribute is not possibile. 3. When relay routers IP address is hidden in the NLRI, it is not convinent to apply BGP policies. So abstracting relay router address as an attribute allows us to address all that.. Why simple ? Proposed method use BGP4+ and extended attributes.. There is no special tunnel specific parsers needed. It is all driven by BGP policy engine Why scalable ? It does not need any explcit peering or anything for tunneling purpose. Hence it scale as much the BGP 4+ scale __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 21 08:29:20 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5LFTJk7014496; Fri, 21 Jun 2002 08:29:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5LFTJXO014495; Fri, 21 Jun 2002 08:29:19 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5LFTBk7014485 for ; Fri, 21 Jun 2002 08:29:12 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA01745 for ; Fri, 21 Jun 2002 08:29:17 -0700 (PDT) Received: from astro.cs.utk.edu ([160.36.58.43]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA05575 for ; Fri, 21 Jun 2002 08:29:17 -0700 (PDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5LFMR213095; Fri, 21 Jun 2002 11:22:27 -0400 (EDT) Message-Id: <200206211522.g5LFMR213095@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Robert Elz cc: Keith Moore , Bill Fenner , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-reply-to: (Your message of "Fri, 21 Jun 2002 15:22:44 +0700.") <7213.1024647764@munnari.OZ.AU> Date: Fri, 21 Jun 2002 11:22:27 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > | but it depends to some degree on how LL is pitched to the public. > > Yes, exactly - and one of its planned uses (right from day 1) was to > support "dentist office" networks - perhaps more likely these days > as "IETF attendees on a bus" (not a plane as using 802.11 there is > probably frowned upon, I haven't risked trying it to see if anyone > would notice...) who just happen to create an ad-hoc network, with > no external support at all. okay. but there's a fairly fundamental conflict here between this use of LL (in a network that will never be connected to the internet) and the use of LL on a network that is only temporarily disconnected from the internet. apps need to know which kind of address to use. if they start assuming an LL-only network they won't be able to send referrals to nodes outside that network; if they start assuming a network with globals they won't be able to send referrals to LL-only nodes. and to try to use both kinds of addrs requires that the app know about network topology. bascially LLs and SLs create a big mess (if apps use them at all) and don't provide any good way to solve those problems. of course, many apps don't do referrals and don't have any problem with LLs or SLs (other than the problem of using LLs on a multiple-interface box) but some apps do, so when you use LLs and SLs for apps you get the confusing situation where some apps work (so the network is "up") while others fail in odd ways. I don't know how to solve this problem entirely, but I think it can be minimized by discouraging use of LLs when they're not needed, and by replacing SLs with a better mechanism. I do see a use case for LLs but I think we could provide SL-like functionality in a better way which was less confusing to apps, and at the same time solve the problem of allowing isolated networks (not having provider-based addresses) to privately interconnect to other networks without NAT. > | ISPs that pull that kind of stunt deserve to go out of business quickly. > > Unfortunately, that requires the customers to desert, quickly, which requires > yet another renumbering. well, if the customer is being forced to renumber, then the customer might as well switch ISPs at the same time... > And remember, that while an ISP could do this as a stunt, the more likely > cause is going to be the network (via a nanog or similar meeting) deciding > that the routing table is simply getting too big, too fast, and that some > realigning of addresses is required to allow topological aggregation to > work again with the network configured in the state that it has developed > into at the time. well, one hopes that nanog or whoever provides adequate advance notice, and that they don't try to force everybody to renumber at once. management of this kind of change will be tricky and I don't think anyone's demonstrated how to do it yet. > That is, it isn't a "stunt". And while you can argue that such a > change should be properly planned, my counter is that no amount of > proper planning is sufficient - surely being able to plan for this for weeks or months causes fewer problems than having 24 hours notice... though I don't pretend that we're anywhere close to having entirely painless renumbering no matter how much notice is given. (like 'painless dentistry' there is no such thing...) > I want connections to be able to > exist where the address will *never* change (other than at my specific > demand - no-one else can ever instigate it). yes, I understand that use case. I just think that there are better ways of providing for it than SLs. and I'm not saying we should forbid hosts or sites or apps from using SLs, nor that we should reallocate those addresses for other purposes - but I think we would do well to provide a better way to solve this problem and to recommend that non-routable global prefixes be used in preference to SLs. that way, apps wouldn't need to try to deal with SLs specially. > | to some degree this is govered by public perception about what is > | reasonable, and such perception can be influenced by standards. > | so we do have some influence here. we should try to use it. > > Yes. To do that in an honest way, we first need to decide how to > avoid requiring addresses with either topological or geographical > significance (both of which require renumbering sometimes). > The original (70's-80's) IP allocation scheme would be OK (allocate > 1 2 3 4 ... to however asks in the order they ask). Just make routing > work with that. Or, propose something else. don't even try to solve the problem of routing these things and accept that (at least for the time being) that addresses used in the public internet still have to be based on topology. have icann set up a web page to request a non-routable prefix which explains the limitations of such prefixes, accepts a credit-card # (for a one-time fee to cover the cost of maintaining the registry and web page only) and then assigns a prefix. another idea is to allow sites to pick their own in a 6to4-like fashion, say by taking some well-known prefix, appending an ethernet (or other) MAC address from a device in their possession, and then the rest of the bits are theirs to play with... two problems with that approach: 1) you probably end up with a /64 prefix which might be a pain for some sites, 2) the site can't sell the device with that MAC address to some other site :) > Hmm - maybe I'm not being clear, or you just missed my point. No > requirement for a site to connect to the public net, certainly. > A site that isn't connected just uses SL addresses as if they were > global addresses (they go in its disconnected DNS - or however it does > address lookups) and are used exactly like anyone else would use a > global address. The site boundaries are the ends of the net as we > know it, so there's no magic at all here. such sites often want to connect privately with other networks, though not to the public net. SLs aren't good for that. > To allow two disconnected sites to communicate, they need either > global addresses right, but to get those they (currently) need to connect with the public network, which they don't want to do. > Groups of sites, talking to each other, but disconnected from the "one > true internet" is something that the current addressing plans really > haven't allowed for, and should. agreed. and note also that some of those sites may be connected to the public network (not providing transit for the others), while others aren't connected. > | with global non-routable addresses, the site-id is carried along with the > | address, it's exposed as part of the address (assuming a reserved prefix > | for such addresses), it's returned in the same kind of DNS RR that carries > | a normal address. the address is globally scoped so there is no chance > | of mistaking an address from a remote site as being one from a local site > | or a different remote site. > > But there's no way to tell from the address that it is one that you > cannot reach from outside, which makes it annoying (at best) to pass > around. assuming a reserved prefix, an app could tell a non-publically-routable (NPR) address from a 'normal' address. but it still would have a difficult time knowing whether the address was usable to a random peer. as I said, it's better than SL, but it still doesn't solve all the problems. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 21 08:29:27 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5LFTQk7014507; Fri, 21 Jun 2002 08:29:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5LFTQHH014505; Fri, 21 Jun 2002 08:29:26 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5LFTMk7014498 for ; Fri, 21 Jun 2002 08:29:22 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA18483 for ; Fri, 21 Jun 2002 08:29:28 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA05732 for ; Fri, 21 Jun 2002 08:29:27 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id IAA14468 for ; Fri, 21 Jun 2002 08:29:27 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g5LFTQc04073; Fri, 21 Jun 2002 08:29:26 -0700 X-mProtect: <200206211529> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (198.77.202.22, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpda4PkZh; Fri, 21 Jun 2002 08:29:25 PDT Message-Id: <4.3.2.7.2.20020621082643.0261f930@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 21 Jun 2002 08:29:02 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: Consensus on Site-Local Discussion Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IPv6 working group chairs reading of the mailing list discussion regarding removing site-local addresses from the IPv6 architecture is that there is not a consensus to make this change. From the email discussion we also believe there is a consensus to not require IPv6 implementations to support connectivity to multiple sites. The suggestion made by Tim Hartrick on the list is a reasonable way to resolve the requirement level of site-local. Specifically: >What I would like to see come out of this long discussion is simply some text >in the in progress "Node Requirements" document that specifies how much of the >scoped address architecture MUST be implemented and that that text would say >that the rules specified in Draves' draft are the only MUST implement portion >of the architecture. There should be no requirement that a node be able to be >part of more than one zone. We believe the resulting actions from this discussion are: - No change to the IPv6 address architecture regarding site local - No change to the "Default Address Selection for IPv6" draft - Text to be added to the "IPv6 Node Requirements" draft as outlined by Tim Hartrick text (above). - The working group should complete the Scoped Address Architecture draft. Bob Hinden, Steve Deering, Margaret Wasserman IPv6 working group chairs -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 21 08:30:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5LFUbk7014530; Fri, 21 Jun 2002 08:30:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5LFUaNJ014529; Fri, 21 Jun 2002 08:30:36 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5LFUTk7014522 for ; Fri, 21 Jun 2002 08:30:29 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA06152 for ; Fri, 21 Jun 2002 08:30:34 -0700 (PDT) Received: from astro.cs.utk.edu ([160.36.58.43]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA05772 for ; Fri, 21 Jun 2002 09:30:34 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5LFTk214329; Fri, 21 Jun 2002 11:29:46 -0400 (EDT) Message-Id: <200206211529.g5LFTk214329@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Brian E Carpenter cc: Keith Moore , Richard Draves , Alain Durand , ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-ietf-ipv6-default-addr-select-08.txt In-reply-to: (Your message of "Fri, 21 Jun 2002 14:59:55 +0200.") <3D13234B.4A705A11@hursley.ibm.com> Date: Fri, 21 Jun 2002 11:29:46 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The fact is that any implementation *will* have a default behavior in the case > that an app ignores this whole issue, which will be the case for most apps > when first ported to IPv6. The question for the IETF is whether we leave > this open (thereby maximising chaos) or define a default (thereby reducing > chaos). I think we need to define a default to reduce chaos. > > I'd argue that the only hosts likely to have temporary addresses are pure clients. > Servers, or hosts trying to play in a genuine peer2peer world, will need permanent > addresses anyway. Since we care about preserving client privacy, but presumably don't > care about preserving server privacy, I'd argue for Rich's default, i.e. the document > as it is. If we were starting with a brand-new API I'd agree with you. But we're talking about APIs which are in some cases 20 years old, and the default has long been to have stable addresses. it's too late to change it. (and yes, there are lots of programs written to the v4 API which have been ported to v6 with minimal changes - we don't want to break them.) that, and I don't think there is such a thing as a user-programmable, pure-client host. my palm pilot can run a web server, and it's even useful for it to do so. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 21 08:52:32 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5LFqWk7014586; Fri, 21 Jun 2002 08:52:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5LFqWpJ014585; Fri, 21 Jun 2002 08:52:32 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5LFqTk7014578 for ; Fri, 21 Jun 2002 08:52:29 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA13864 for ; Fri, 21 Jun 2002 08:52:34 -0700 (PDT) Received: from [208.236.204.65] (gateus.nmss.com [208.236.204.65]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id JAA04370 for ; Fri, 21 Jun 2002 09:54:52 -0600 (MDT) To: ipng@sunroof.eng.sun.com Received: from [10.1.3.12] by [208.236.204.65] via smtpd (for patan.Sun.COM [192.18.98.43]) with SMTP; 21 Jun 2002 10:48:27 UT Subject: Stateful Address Config - I-D ACTION:draft-ietf-ipv6-node-requirements-00.txt X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Adam Machalek" Date: Fri, 21 Jun 2002 10:52:29 -0500 X-MIMETrack: Serialize by Router on NAMASMTP02/NMS Communications(Release 5.0.10 |March 22, 2002) at 06/21/2002 11:48:45 AM, Serialize complete at 06/21/2002 11:48:45 AM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 0057335786256BDF_=" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multipart message in MIME format. --=_alternative 0057335786256BDF_= Content-Type: text/plain; charset="us-ascii" John, Section 5.4 on DHCPv6 states that DHCPv6 is unconditionally optional, which today implicitly makes Stateful Address config optional. However, I'd like to see some direct clarification in this document on Stateful Address config, probably directly after Section 4.5.2 discussing Stateless Address config. RFC2462 has some ambiguities, in particular, it states "a managed address configuration flag indicates whether hosts should use stateful autoconfiguration", not SHOULD. Later in 2462 in section 5.2 it continues this ambiguity by never explicitly using MAY/SHOULD/MUST anywhere. Still later in section RFC2462 5.5.2 Absence of Router Advertisements, it finally states that in the absence of a router, a host MUST attempt to use stateful autoconfiguration. And lastly, the DHCPv6 draft states "DHCP is one vehicle to perform stateful autoconfiguration", implying that there may be others. So in the end, even with DHCPv6 optional, this doesn't clarify exactly what a host should do about Stateful Address autoconfiguration. Adam Machalek --=_alternative 0057335786256BDF_= Content-Type: text/html; charset="us-ascii"
John,

Section 5.4 on DHCPv6 states that DHCPv6 is unconditionally optional, which today implicitly makes Stateful Address config optional.  

However, I'd like to see some direct clarification in this document on Stateful Address config, probably directly after Section 4.5.2 discussing Stateless Address config.  

RFC2462 has some ambiguities, in particular, it states "a managed address configuration flag indicates whether hosts should use stateful autoconfiguration", not SHOULD.   Later in 2462 in section 5.2 it continues this ambiguity by never explicitly using MAY/SHOULD/MUST anywhere.

Still later in section RFC2462 5.5.2 Absence of Router Advertisements, it finally states that in the absence of a router, a host MUST attempt to use stateful autoconfiguration.

And lastly, the DHCPv6 draft states "DHCP is one vehicle to perform stateful autoconfiguration", implying that there may be others.

So in the end, even with DHCPv6 optional, this doesn't clarify exactly what a host should do about Stateful Address autoconfiguration.

Adam Machalek --=_alternative 0057335786256BDF_=-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 21 09:24:55 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5LGOtk7014855; Fri, 21 Jun 2002 09:24:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5LGOs80014854; Fri, 21 Jun 2002 09:24:54 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5LGOok7014847 for ; Fri, 21 Jun 2002 09:24:51 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA19779 for ; Fri, 21 Jun 2002 09:24:57 -0700 (PDT) Received: from astro.cs.utk.edu ([160.36.58.43]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA02844 for ; Fri, 21 Jun 2002 09:24:56 -0700 (PDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5LGIX221460; Fri, 21 Jun 2002 12:18:33 -0400 (EDT) Message-Id: <200206211618.g5LGIX221460@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Michel Py" cc: "Robert Elz" , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-reply-to: (Your message of "Fri, 21 Jun 2002 08:10:50 PDT.") <2B81403386729140A3A899A8B39B046405E143@server2000.arneill-py.sacramento.ca.us> Date: Fri, 21 Jun 2002 12:18:33 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > There is one thing that worries me about such a scheme: it does in fact > give a PI address to everybody. It is to be feared that people using > these addresses will make arrangements with their upstreams to have > these leaked in the global table. and everybody else will filter them, and refuse to forward such advertisements, as they should. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 21 09:29:34 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5LGTXk7014886; Fri, 21 Jun 2002 09:29:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5LGTXq8014885; Fri, 21 Jun 2002 09:29:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5LGTUk7014878 for ; Fri, 21 Jun 2002 09:29:30 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA08682 for ; Fri, 21 Jun 2002 09:29:36 -0700 (PDT) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA05540 for ; Fri, 21 Jun 2002 09:29:36 -0700 (PDT) Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 21 Jun 2002 09:29:34 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Message-ID: <2B81403386729140A3A899A8B39B046405E144@server2000.arneill-py.sacramento.ca.us> content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Fwd: IPv6 Scoped Addresses and Routing Protocols Thread-Index: AcIZP24zbBqFZiztTx2YWodaVMVdUQAAGUDg From: "Michel Py" To: "Keith Moore" Cc: "Robert Elz" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5LGTUk7014879 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith, >> There is one thing that worries me about such a scheme: it does in fact >> give a PI address to everybody. It is to be feared that people using >> these addresses will make arrangements with their upstreams to have >> these leaked in the global table. > Keith Moore wrote > and everybody else will filter them, and refuse to forward > such advertisements, as they should. This is what I would _hope_, but we just don't know. If there is demand and money for it, it will happen whether you and I like it or not. Please allow me to rephrase my point: Site-ids for SL addresses do fulfill a need that I acknowledge (I mostly share kre's views on renumbering). However, I do think that we should not get started on this slippery slope _before_ we provide another solution to people that would push pervert them into unaggregated PI. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 21 09:33:23 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5LGXMk7014918; Fri, 21 Jun 2002 09:33:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5LGXMh6014917; Fri, 21 Jun 2002 09:33:22 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5LGXIk7014910 for ; Fri, 21 Jun 2002 09:33:18 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA23677 for ; Fri, 21 Jun 2002 09:33:24 -0700 (PDT) Received: from astro.cs.utk.edu ([160.36.58.43]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA07578 for ; Fri, 21 Jun 2002 09:33:24 -0700 (PDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5LGTd222997; Fri, 21 Jun 2002 12:29:39 -0400 (EDT) Message-Id: <200206211629.g5LGTd222997@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Bob Hinden cc: ipng@sunroof.eng.sun.com Subject: Re: Consensus on Site-Local Discussion In-reply-to: (Your message of "Fri, 21 Jun 2002 08:29:02 PDT.") <4.3.2.7.2.20020621082643.0261f930@mailhost.iprg.nokia.com> Date: Fri, 21 Jun 2002 12:29:39 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I agree that there's probably not consensus to deprecate SL, but I think we should consider finding ways to discourage its use, and to remove the burden from apps of having to support it specially. I don't agree that the Default Address Selection document should be published without change, and I don't think we have consensus on that at all. though perhaps the sections on SL are okay. (not sure what you meant here by "no change") the introduction of scoped addresses into the Internet architecture has caused several problems for apps which are difficult to solve . even if there's not consensus to do away with them entirely, we need to understand how to minimize the damage, and that probably means minimizing the use of limited-scope addresses. So it's not clear to me that having the WG complete the current Scoped Address Architecture document is an appropriate goal. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 21 09:37:27 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5LGbRk7014970; Fri, 21 Jun 2002 09:37:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5LGbQ1L014969; Fri, 21 Jun 2002 09:37:26 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5LGbMk7014962 for ; Fri, 21 Jun 2002 09:37:23 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA02840 for ; Fri, 21 Jun 2002 09:37:28 -0700 (PDT) Received: from astro.cs.utk.edu ([160.36.58.43]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA19013 for ; Fri, 21 Jun 2002 10:37:27 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5LGV5223204; Fri, 21 Jun 2002 12:31:05 -0400 (EDT) Message-Id: <200206211631.g5LGV5223204@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Michel Py" cc: "Keith Moore" , "Robert Elz" , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-reply-to: (Your message of "Fri, 21 Jun 2002 09:29:34 PDT.") <2B81403386729140A3A899A8B39B046405E144@server2000.arneill-py.sacramento.ca.us> Date: Fri, 21 Jun 2002 12:31:05 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >> There is one thing that worries me about such a scheme: it does in > fact > >> give a PI address to everybody. It is to be feared that people using > >> these addresses will make arrangements with their upstreams to have > >> these leaked in the global table. > > > Keith Moore wrote > > and everybody else will filter them, and refuse to forward > > such advertisements, as they should. > > This is what I would _hope_, but we just don't know. If there is demand > and money for it, it will happen whether you and I like it or not. well, if the default is that everybody filters these things, then you have to pay money to everybody if you want them to not filter them. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 21 09:47:18 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5LGlIk7015039; Fri, 21 Jun 2002 09:47:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5LGlIRB015038; Fri, 21 Jun 2002 09:47:18 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5LGlFk7015031 for ; Fri, 21 Jun 2002 09:47:15 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA28468 for ; Fri, 21 Jun 2002 09:47:21 -0700 (PDT) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA22361 for ; Fri, 21 Jun 2002 10:47:20 -0600 (MDT) Subject: RE: Consensus on Site-Local Discussion MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 21 Jun 2002 09:47:19 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Message-ID: <2B81403386729140A3A899A8B39B046406C872@server2000.arneill-py.sacramento.ca.us> content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Consensus on Site-Local Discussion Thread-Index: AcIZOOIDiMiLti32RfCHbKz4EdgGugACiPRA From: "Michel Py" To: "Bob Hinden" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5LGlFk7015032 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Bob Hinden wrote: > The IPv6 working group chairs reading of the mailing list > discussion [snip] I am in agreement with the chair's reading of this. Time to move on. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 21 10:45:47 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5LHjlk7015346; Fri, 21 Jun 2002 10:45:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5LHjlCd015345; Fri, 21 Jun 2002 10:45:47 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5LHjik7015338 for ; Fri, 21 Jun 2002 10:45:44 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA22693 for ; Fri, 21 Jun 2002 10:45:48 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA09522 for ; Fri, 21 Jun 2002 11:48:06 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA21420; Fri, 21 Jun 2002 10:45:46 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g5LHjjC09354; Fri, 21 Jun 2002 10:45:45 -0700 X-mProtect: <200206211745> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (198.77.202.22, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdXD6tmO; Fri, 21 Jun 2002 10:45:43 PDT Message-Id: <4.3.2.7.2.20020621094504.0261f930@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 21 Jun 2002 10:45:23 -0700 To: Keith Moore From: Bob Hinden Subject: Re: Consensus on Site-Local Discussion Cc: ipng@sunroof.eng.sun.com In-Reply-To: <200206211629.g5LGTd222997@astro.cs.utk.edu> References: <(Your message of "Fri, 21 Jun 2002 08:29:02 PDT.") <4.3.2.7.2.20020621082643.0261f930@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 Keith, At 09:29 AM 6/21/2002, Keith Moore wrote: >I agree that there's probably not consensus to deprecate SL, >but I think we should consider finding ways to discourage its use, >and to remove the burden from apps of having to support it specially. > >I don't agree that the Default Address Selection document should >be published without change, and I don't think we have consensus on >that at all. though perhaps the sections on SL are okay. >(not sure what you meant here by "no change") The intent of the line was regarding site-local only, specifically not the current discussion on permanent/temporary preferences. >the introduction of scoped addresses into the Internet architecture >has caused several problems for apps which are difficult to solve . >even if there's not consensus to do away with them entirely, >we need to understand how to minimize the damage, and that probably >means minimizing the use of limited-scope addresses. So it's not >clear to me that having the WG complete the current Scoped Address >Architecture document is an appropriate goal. The intent behind the "complete the Scoped Address Architecture" action was that if we are going to have site-local we need to define how they work. I think you are suggesting that will need to do additional work to provide guidance as to the appropriate use of limited scope addresses, specifically including application considerations. Agree? Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 21 11:42:42 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5LIgfk7015467; Fri, 21 Jun 2002 11:42:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5LIgfC9015466; Fri, 21 Jun 2002 11:42:41 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5LIgbk7015459 for ; Fri, 21 Jun 2002 11:42:37 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA03064 for ; Fri, 21 Jun 2002 11:42:43 -0700 (PDT) Received: from astro.cs.utk.edu ([160.36.58.43]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA10238 for ; Fri, 21 Jun 2002 12:45:01 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5LIeQ201639; Fri, 21 Jun 2002 14:40:26 -0400 (EDT) Message-Id: <200206211840.g5LIeQ201639@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Bob Hinden cc: Keith Moore , ipng@sunroof.eng.sun.com Subject: Re: Consensus on Site-Local Discussion In-reply-to: (Your message of "Fri, 21 Jun 2002 10:45:23 PDT.") <4.3.2.7.2.20020621094504.0261f930@mailhost.iprg.nokia.com> Date: Fri, 21 Jun 2002 14:40:26 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >the introduction of scoped addresses into the Internet architecture > >has caused several problems for apps which are difficult to solve . > >even if there's not consensus to do away with them entirely, > >we need to understand how to minimize the damage, and that probably > >means minimizing the use of limited-scope addresses. So it's not > >clear to me that having the WG complete the current Scoped Address > >Architecture document is an appropriate goal. > > The intent behind the "complete the Scoped Address Architecture" action was > that if we are going to have site-local we need to define how they work. I > think you are suggesting that will need to do additional work to provide > guidance as to the appropriate use of limited scope addresses, specifically > including application considerations. Agree? more or less agree. and I still think we are better off providing a better alternative to SL addresses, even if we don't completely deprecate them. in other words, I think we need to seriously question some of the assumptions behind the scoped addressing architecture, and I'm not confident that "completing the work on the Scoped Address Architecture document" will accomplish that. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 21 14:13:43 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5LLDhk7016056; Fri, 21 Jun 2002 14:13:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5LLDhTU016055; Fri, 21 Jun 2002 14:13:43 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5LLDek7016048 for ; Fri, 21 Jun 2002 14:13:40 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA08667 for ; Fri, 21 Jun 2002 14:13:45 -0700 (PDT) Received: from mail7.nc.rr.com (mail7.southeast.rr.com [24.93.67.54]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA06652 for ; Fri, 21 Jun 2002 14:13:44 -0700 (PDT) Received: from nc.rr.com ([24.162.252.183]) by mail7.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Fri, 21 Jun 2002 17:13:16 -0400 Message-ID: <3D13963B.DBD7085D@nc.rr.com> Date: Fri, 21 Jun 2002 17:10:19 -0400 From: Brian Haberman X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Keith Moore CC: ipng@sunroof.eng.sun.com Subject: Re: Consensus on Site-Local Discussion References: <200206211840.g5LIeQ201639@astro.cs.utk.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith, Keith Moore wrote: > > in other words, I think we need to seriously question some of the assumptions > behind the scoped addressing architecture, and I'm not confident that > "completing the work on the Scoped Address Architecture document" will > accomplish that. Can you enumerate what assumptions you are concerned about? That would give us the authors a better understanding of your concerns. 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 Jun 21 14:27:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5LLR8k7016094; Fri, 21 Jun 2002 14:27:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5LLR8Wx016093; Fri, 21 Jun 2002 14:27:08 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5LLR4k7016086 for ; Fri, 21 Jun 2002 14:27:04 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA25758 for ; Fri, 21 Jun 2002 14:27:09 -0700 (PDT) Received: from astro.cs.utk.edu ([160.36.58.43]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA29941 for ; Fri, 21 Jun 2002 15:27:08 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5LLLK202968; Fri, 21 Jun 2002 17:21:20 -0400 (EDT) Message-Id: <200206212121.g5LLLK202968@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Brian Haberman cc: Keith Moore , ipng@sunroof.eng.sun.com Subject: Re: Consensus on Site-Local Discussion In-reply-to: (Your message of "Fri, 21 Jun 2002 17:10:19 EDT.") <3D13963B.DBD7085D@nc.rr.com> Date: Fri, 21 Jun 2002 17:21:19 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Can you enumerate what assumptions you are concerned about? That would > give us the authors a better understanding of your concerns. I've about decided to write up an I-D before 9 AM Monday on this topic, but here's the capsule summary: the basic problem with limited-scope addresses is that they force some kinds of apps (in particular those that need to do referrals) to a) know about network topology and/or b) to provide lists of addresses in referrals and do trial-and-failure to determine which address works (best or at all) in any context to which a referral might be propagated. limited-duration addresses (such as v6 temporary addresses or v4 LLs) impose other problems - apps that use them have to recover from address changes. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 21 17:48:04 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5M0m4k7016450; Fri, 21 Jun 2002 17:48:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5M0m4ev016449; Fri, 21 Jun 2002 17:48:04 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5M0m0k7016442 for ; Fri, 21 Jun 2002 17:48:00 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA26409 for ; Fri, 21 Jun 2002 17:48:04 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA14611 for ; Fri, 21 Jun 2002 18:48:04 -0600 (MDT) Received: from kenawang ([147.11.233.7]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id RAA03642; Fri, 21 Jun 2002 17:46:27 -0700 (PDT) Message-Id: <4.2.2.20020621204653.0234b490@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 21 Jun 2002 20:47:56 -0400 To: Keith Moore From: Margaret Wasserman Subject: Re: Consensus on Site-Local Discussion Cc: Brian Haberman , Keith Moore , ipng@sunroof.eng.sun.com In-Reply-To: <200206212121.g5LLLK202968@astro.cs.utk.edu> References: <(Your message of "Fri, 21 Jun 2002 17:10:19 EDT.") <3D13963B.DBD7085D@nc.rr.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 05:21 PM 6/21/02 , Keith Moore wrote: > > Can you enumerate what assumptions you are concerned about? That would > > give us the authors a better understanding of your concerns. > >I've about decided to write up an I-D before 9 AM Monday on this topic, >but here's the capsule summary: It would be great if you can get a draft out. I'd like to understand these issues better, and I think that it would be good for the group to discuss them once the issues are better understood. Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 21 22:12:43 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5M5Chk7016978; Fri, 21 Jun 2002 22:12:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5M5ChTC016977; Fri, 21 Jun 2002 22:12:43 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5M5Cek7016970 for ; Fri, 21 Jun 2002 22:12:40 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA20520 for ; Fri, 21 Jun 2002 22:12:45 -0700 (PDT) Received: from smtp.cs.nthu.edu.tw (smtp.cs.nthu.edu.tw [140.114.87.30]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA22160 for ; Fri, 21 Jun 2002 23:12:44 -0600 (MDT) Received: from mosquito (mosquito.cs.nthu.edu.tw [140.114.79.57]) by smtp.cs.nthu.edu.tw (8.9.3/8.9.3) with SMTP id NAA11378 for ; Sat, 22 Jun 2002 13:12:38 +0800 (CST) Message-ID: <006001c219ab$63966d60$394f728c@mosquito> From: "jmc_cs" To: Subject: tcpdump ipv6 tcp traffic with routing header can't see ack window Date: Sat, 22 Jun 2002 13:12:21 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all: I have a problem about tcpdump on Linux IPv6 TCP traffic. I have dumped tcp traffic log at on computer, and I want to trace the ack window. I dumped the traffic with the command: #> tcpdump -n -w log1 And I parsed it to make the log1 readable by do : #>tcpdump -n -r log1 > log1.dat In log1.dat, I can see packets' information. The general packets are ok to see the ack window, for example: 13:53:36.392395 3002:1:1:4::6.1042 > 3000:1:1:1:202:2dff:fe22:de1c.5001: .1:1313(1312) ack 1 win 5760 ^^^^^^^^^^^^^^^^ 13:53:36.401866 3000:1:1:1:202:2dff:fe22:de1c.5001 > 3002:1:1:4::6.1042: .ack 1313 win 7872 ^^^^^^^^^^^^^^ But when the packets are with a routing header, I can't see the ack win info. All I see is "srcrt(len=***********[|tcp|])" as below: 13:53:55.688766 3002:1:1:4::6 > 3000:1:1:5:202:2dff:fe22:de1c: srcrt (len=2,type=0, segleft=1, [0]3000:1:1:1:202:2dff:fe22:de1c) 1042 > 5001: [|tcp] ^^^^^ ^^^^^ 13:53:55.701903 3000:1:1:1:202:2dff:fe22:de1c > 3002:1:1:4::6: DSTOPT 5001 >1042: [|tcp] ^^^^ How can I exactly see the TCP information? Can anyone please tell me that how can I see the packets' ack win that is with routing headers????? Thanks~~~~~~~ jmc -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 22 00:52:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5M7qfk7017172; Sat, 22 Jun 2002 00:52:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5M7qeGV017171; Sat, 22 Jun 2002 00:52:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5M7qbk7017164 for ; Sat, 22 Jun 2002 00:52:37 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA26882 for ; Sat, 22 Jun 2002 00:52:42 -0700 (PDT) From: john.loughney@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA12194 for ; Sat, 22 Jun 2002 00:52:41 -0700 (PDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g5M7r7i03952 for ; Sat, 22 Jun 2002 10:53:07 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Sat, 22 Jun 2002 10:52:39 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Sat, 22 Jun 2002 10:52:40 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Consensus on Site-Local Discussion Date: Sat, 22 Jun 2002 10:52:39 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF01130369@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Consensus on Site-Local Discussion Thread-Index: AcIZONiUUkMqRjzaTIOLzapM7p+XBQAKtbAw To: , X-OriginalArrivalTime: 22 Jun 2002 07:52:40.0003 (UTC) FILETIME=[C8528930:01C219C1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5M7qck7017165 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Bob & Tim, > > What I would like to see come out of this long discussion is simply some text > > in the in progress "Node Requirements" document that specifies how much > > of the scoped address architecture MUST be implemented and that > > that text would say that the rules specified in Draves' draft are the only MUST > > implement portion of the architecture. There should be no requirement that a > > node be able to be part of more than one zone. > > We believe the resulting actions from this discussion are: > > - No change to the IPv6 address architecture regarding site local > - No change to the "Default Address Selection for IPv6" draft > - Text to be added to the "IPv6 Node Requirements" draft as > outlined by Tim Hartrick text (above). I'll add text about this when I revise the Node requirements. thanks, John -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 22 00:53:36 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5M7rak7017189; Sat, 22 Jun 2002 00:53:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5M7rZo8017188; Sat, 22 Jun 2002 00:53:35 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5M7rWk7017181 for ; Sat, 22 Jun 2002 00:53:32 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA08694 for ; Sat, 22 Jun 2002 00:53:37 -0700 (PDT) From: john.loughney@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA11519 for ; Sat, 22 Jun 2002 01:53:35 -0600 (MDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g5M7s2i04080 for ; Sat, 22 Jun 2002 10:54:02 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sat, 22 Jun 2002 10:53:34 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Sat, 22 Jun 2002 10:53:34 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C219C1.E89F9912" Subject: RE: Stateful Address Config - I-D ACTION:draft-ietf-ipv6-node-requirements-00.txt Date: Sat, 22 Jun 2002 10:53:34 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF01130370@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Stateful Address Config - I-D ACTION:draft-ietf-ipv6-node-requirements-00.txt Thread-Index: AcIZPZgy8+uKW4V4QuqxPGtOHAtoKwAKybQA To: , X-OriginalArrivalTime: 22 Jun 2002 07:53:34.0569 (UTC) FILETIME=[E8D8A590:01C219C1] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C219C1.E89F9912 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Adam, Very good point, I knew I was forgetting this point. I will try to add = some test to the update about this. =20 I think that that stateful address config is probably conditionally = mandatory (or even unconditionally=20 mandatory. The section on 2462 needs this info. Also, we need some = extra text in DHCPv6 to discuss this, as well. =20 Thanks, John -----Original Message----- From: ext Adam Machalek [mailto:Adam_Machalek@nmss.com] Sent: 21 June, 2002 18:52 To: ipng@sunroof.eng.sun.com Subject: Stateful Address Config - I-D = ACTION:draft-ietf-ipv6-node-requirements-00.txt John,=20 Section 5.4 on DHCPv6 states that DHCPv6 is unconditionally optional, = which today implicitly makes Stateful Address config optional. =20 However, I'd like to see some direct clarification in this document on = Stateful Address config, probably directly after Section 4.5.2 = discussing Stateless Address config. =20 RFC2462 has some ambiguities, in particular, it states "a managed = address configuration flag indicates whether hosts should use stateful = autoconfiguration", not SHOULD. Later in 2462 in section 5.2 it = continues this ambiguity by never explicitly using MAY/SHOULD/MUST = anywhere.=20 Still later in section RFC2462 5.5.2 Absence of Router Advertisements, = it finally states that in the absence of a router, a host MUST attempt = to use stateful autoconfiguration.=20 And lastly, the DHCPv6 draft states "DHCP is one vehicle to perform = stateful autoconfiguration", implying that there may be others.=20 So in the end, even with DHCPv6 optional, this doesn't clarify exactly = what a host should do about Stateful Address autoconfiguration.=20 Adam Machalek ------_=_NextPart_001_01C219C1.E89F9912 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi=20 Adam,

Very good point, I = knew I was=20 forgetting this point.  I will try to add some test to the update = about=20 this.
 
I think that that stateful address config is probably = conditionally=20 mandatory (or even unconditionally
mandatory.  The section on 2462 needs this info.  = Also, we need=20 some extra text in DHCPv6 to discuss this,
as=20 well.
 
Thanks,
John
-----Original Message-----
From: ext Adam Machalek=20 [mailto:Adam_Machalek@nmss.com]
Sent: 21 June, 2002=20 18:52
To: ipng@sunroof.eng.sun.com
Subject: = Stateful=20 Address Config - I-D=20 = ACTION:draft-ietf-ipv6-node-requirements-00.txt


<= FONT=20 face=3Dsans-serif size=3D2>John,

Section 5.4 on DHCPv6 states that DHCPv6 is unconditionally = optional,=20 which today implicitly makes Stateful Address config optional. =  =20

However, I'd like to see some = direct=20 clarification in this document on Stateful Address config, probably = directly=20 after Section 4.5.2 discussing Stateless Address config.   =

RFC2462 has some ambiguities, = in=20 particular, it states "a managed address configuration flag indicates = whether=20 hosts should use stateful autoconfiguration", not SHOULD.   Later = in 2462=20 in section 5.2 it continues this ambiguity by never explicitly using=20 MAY/SHOULD/MUST anywhere.

Still=20 later in section RFC2462 5.5.2 Absence of Router Advertisements, it = finally=20 states that in the absence of a router, a host MUST attempt to use = stateful=20 autoconfiguration.

And = lastly, the=20 DHCPv6 draft states "DHCP is one vehicle to perform stateful=20 autoconfiguration", implying that there may be others. =

So in the end, even with DHCPv6 optional, = this doesn't=20 clarify exactly what a host should do about Stateful Address=20 autoconfiguration.

Adam=20 Machalek ------_=_NextPart_001_01C219C1.E89F9912-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 23 10:20:12 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5NHKCk7019150; Sun, 23 Jun 2002 10:20:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5NHKClb019149; Sun, 23 Jun 2002 10:20:12 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5NHK9k7019142 for ; Sun, 23 Jun 2002 10:20:09 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA02484 for ; Sun, 23 Jun 2002 10:20:13 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.96.7]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA02104 for ; Sun, 23 Jun 2002 10:20:12 -0700 (PDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g5NHJYM09359; Mon, 24 Jun 2002 00:19:35 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g5NHJ3E25450; Mon, 24 Jun 2002 00:19:03 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Keith Moore cc: ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-Reply-To: <200206211522.g5LFMR213095@astro.cs.utk.edu> References: <200206211522.g5LFMR213095@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 24 Jun 2002 00:19:03 +0700 Message-ID: <25448.1024852743@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 21 Jun 2002 11:22:27 -0400 From: Keith Moore Message-ID: <200206211522.g5LFMR213095@astro.cs.utk.edu> I think this discussion is mostly over (for now), so I will respond to just one point in your message, and leave the rest for perhaps some other time... | okay. but there's a fairly fundamental conflict here between this | use of LL (in a network that will never be connected to the internet) | and the use of LL on a network that is only temporarily disconnected | from the internet. apps need to know which kind of address to use. Hmm - I think apps (&/or the system, or something) need to be able to do something here (if they're the kind that survive long enough for changes to occur). Things like MTAs, DNS servers, ... all do already (or do if they're worth using). That is, it is entirely likely that a node will power up with no net connected (hence no global addresses - v4 or v6), and apps will start running. Later it connects to a net, and globals appear. Later still, the net goes away again, and the globals expire. When the net comes back again, the global addresses that reappear may be the same as before, or they might be different. All this happens all the time - as things are now (regardless of whether scoped addresses exist or not). Apart from simply refusing to work if a global addr isn't available (as distinct from being able to contact some remote site, which is kind of inevitable) apps really need to be able to deal with things like this. Like it or not, the world has changed in the past 20 years - your typical internet node is no longer a half ton (or more) beast that runs forever, and never turns off or gets disconnected. Apps, and app designers just have to adapt - regardless if this means doing more work. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jun 23 10:51:27 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5NHpRk7019278; Sun, 23 Jun 2002 10:51:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5NHpRCm019277; Sun, 23 Jun 2002 10:51:27 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5NHpNk7019270 for ; Sun, 23 Jun 2002 10:51:23 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA06192 for ; Sun, 23 Jun 2002 10:51:28 -0700 (PDT) Received: from astro.cs.utk.edu ([160.36.58.43]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA12850 for ; Sun, 23 Jun 2002 11:51:27 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5NHj5200892; Sun, 23 Jun 2002 13:45:05 -0400 (EDT) Message-Id: <200206231745.g5NHj5200892@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Robert Elz cc: Keith Moore , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-reply-to: (Your message of "Mon, 24 Jun 2002 00:19:03 +0700.") <25448.1024852743@munnari.OZ.AU> Date: Sun, 23 Jun 2002 13:45:05 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I think this discussion is mostly over (for now), so I will respond > to just one point in your message, and leave the rest for > perhaps some other time... > > | okay. but there's a fairly fundamental conflict here between this > | use of LL (in a network that will never be connected to the internet) > | and the use of LL on a network that is only temporarily disconnected > | from the internet. apps need to know which kind of address to use. > > Hmm - I think apps (&/or the system, or something) need to be able to > do something here (if they're the kind that survive long enough for > changes to occur). Things like MTAs, DNS servers, ... all do already > (or do if they're worth using). > > That is, it is entirely likely that a node will power up with no net > connected (hence no global addresses - v4 or v6), and apps will > start running. Later it connects to a net, and globals appear. > Later still, the net goes away again, and the globals expire. > When the net comes back again, the global addresses that reappear > may be the same as before, or they might be different. > > All this happens all the time - as things are now (regardless of whether > scoped addresses exist or not). indeed. > Apart from simply refusing to work if a global addr isn't available > (as distinct from being able to contact some remote site, which is > kind of inevitable) apps really need to be able to deal with things > like this. agreed. apps really do need a way to deal with things like this. unfortunately, they don't have a good way of dealing with things like this, and it's not at all clear that placing the responsibility with the apps to deal with things like this is architecturally sane. > Like it or not, the world has changed in the past 20 years indeed it has (and along with it the net), and this is the entire point. the net has changed in such a way that it doesn't support some kinds of applications very well. at the same time, we have an even greater desire to support those kinds of applications. > - your > typical internet node is no longer a half ton (or more) beast that > runs forever, and never turns off or gets disconnected. Apps, and > app designers just have to adapt - regardless if this means doing > more work. it's not at all clear that the problem can be solved effectively by placing the burden on the apps - in fact it's clear that the problem *cannot* be solved effectively merely by expecting apps to do "more work". like you say, the net has changed in the past 20 years, and the days in which somebody could make a change to one aspect of the net and claim that whatever difficulties those changes caused are somebody else's problem, are long gone. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jun 23 20:33:42 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5O3Xfk7019934; Sun, 23 Jun 2002 20:33:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5O3XfVA019933; Sun, 23 Jun 2002 20:33:41 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5O3Xck7019926 for ; Sun, 23 Jun 2002 20:33:38 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA08483 for ; Sun, 23 Jun 2002 20:33:44 -0700 (PDT) Received: from i2soft_web ([211.240.20.130]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id VAA14033 for ; Sun, 23 Jun 2002 21:33:42 -0600 (MDT) Received: by i2soft_web with MERCUR-SMTP/POP3/IMAP4-Server (v3.00.25 RI-0000000) for at Mon, 24 Jun 2002 12:37:30 +0900 From: "Yongseung Bae" To: Subject: RE: I-D ACTION:draft-ietf-ipv6-flow-label-02.txt Date: Mon, 24 Jun 2002 12:33:36 +0900 Message-ID: <000301c21b2f$ed03d760$b170fe81@jeremiah> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <200206211136.HAA07859@ietf.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi! I have been read a draft(draft-ietf-ipv6-flow-label-02.txt). This time, I have some question. Where do I look for information that interface about flow labeling and flow state establishment method? Thanks regards -----Original Message----- From: owner-ipng@sunroof.eng.sun.com [mailto:owner-ipng@sunroof.eng.sun.com] On Behalf Of Internet-Drafts@ietf.org Sent: Friday, June 21, 2002 8:36 PM To: IETF-Announce: Cc: ipng@sunroof.eng.sun.com Subject: I-D ACTION:draft-ietf-ipv6-flow-label-02.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. Title : IPv6 Flow Label Specification Author(s) : J. Rajahalme, A. Conta, B. Carpenter, S. Deering Filename : draft-ietf-ipv6-flow-label-02.txt Pages : 7 Date : 20-Jun-02 This document specifies the usage of the IPv6 Flow Label field, the requirements for IPv6 source nodes labeling flows, and the requirements for flow state establishment methods. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-flow-label-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipv6-flow-label-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-ipv6-flow-label-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. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 23 23:52:59 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5O6qxk7020290; Sun, 23 Jun 2002 23:52:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5O6qwak020289; Sun, 23 Jun 2002 23:52:58 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5O6qtk7020282 for ; Sun, 23 Jun 2002 23:52:55 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA00663 for ; Sun, 23 Jun 2002 23:53:00 -0700 (PDT) Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA25242 for ; Sun, 23 Jun 2002 23:52:59 -0700 (PDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5O6qncK014170; Mon, 24 Jun 2002 08:52:54 +0200 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with SMTP id g5O6qmo126400; Mon, 24 Jun 2002 08:52:48 +0200 Received: from dhcp23-199.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA44792 from ; Mon, 24 Jun 2002 08:52:46 +0200 Message-Id: <3D16C1F4.673ED607@hursley.ibm.com> Date: Mon, 24 Jun 2002 08:53:40 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Yongseung Bae Cc: ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-ietf-ipv6-flow-label-02.txt References: <000301c21b2f$ed03d760$b170fe81@jeremiah> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Yongseung Bae wrote: > > Hi! > I have been read a draft(draft-ietf-ipv6-flow-label-02.txt). > This time, I have some question. > Where do I look for information that interface about flow labeling and > flow state establishment method? The draft was carefully written to be neutral about these questions. It intends to define the minimum requirements for supporting the flow label, not to describe how to use 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 Mon Jun 24 03:13:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5OADWk7020514; Mon, 24 Jun 2002 03:13:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5OADWm8020513; Mon, 24 Jun 2002 03:13:32 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5OADTk7020506 for ; Mon, 24 Jun 2002 03:13:29 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA05827 for ; Mon, 24 Jun 2002 03:13:33 -0700 (PDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA19200 for ; Mon, 24 Jun 2002 04:13:32 -0600 (MDT) Received: from rdroms-w2k.cisco.com (rtp-vpn2-115.cisco.com [10.82.240.115]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id GAA09885; Mon, 24 Jun 2002 06:06:06 -0400 (EDT) Message-Id: <4.3.2.7.2.20020623173820.00ba1978@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 23 Jun 2002 17:44:17 -0400 To: "Michel Py" From: Ralph Droms Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols Cc: "Robert Elz" , In-Reply-To: <2B81403386729140A3A899A8B39B046405E143@server2000.arneill- py.sacramento.ca.us> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I agree 100% with Micehls' point - assigning unique IDs to sites for use in site-local addresses moves the site-local addresses into a globally routable address space, with the additional feature that those addresses are provider independent. The result would be an address space that is site-local by (potentially unenforceable) executive fiat rather than by technical design. - Ralph At 08:10 AM 6/21/2002 -0700, Michel Py wrote: >If I understand correctly, what you are advocating for is SL addresses >that are globally unique (by using a mechanism such as embedding the ASN >in the higher bits). [...] > >There is one thing that worries me about such a scheme: it does in fact >give a PI address to everybody. It is to be feared that people using >these addresses will make arrangements with their upstreams to have >these leaked in the global table. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 24 06:04:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5OD4mk7021130; Mon, 24 Jun 2002 06:04:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5OD4m6w021129; Mon, 24 Jun 2002 06:04:48 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5OD4jk7021122 for ; Mon, 24 Jun 2002 06:04:45 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA22563 for ; Mon, 24 Jun 2002 06:04:51 -0700 (PDT) Received: from gateus.nmss.com (gateus.nmss.com [208.236.204.65]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with SMTP id HAA14319 for ; Mon, 24 Jun 2002 07:04:50 -0600 (MDT) Received: from [10.1.3.12] by gateus.nmss.com via smtpd (for pheriche.sun.com [192.18.98.34]) with SMTP; 24 Jun 2002 08:00:43 UT Subject: Section 4.2.1 - draft-ietf-ipv6-node-requirements-00.txt To: ipng@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Adam Machalek" Date: Mon, 24 Jun 2002 08:04:45 -0500 X-MIMETrack: Serialize by Router on NAMASMTP02/NMS Communications(Release 5.0.10 |March 22, 2002) at 06/24/2002 09:01:01 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk John, In section 4.2.1 on RFC2461, you repeat that Router Discovery is Unconditionally manatory twice. Also, I'd like to understand why the ability to disable Router Discovery is marked as a SHOULD instead of a MAY. I don't recall anything in 2461 that calls this out. With the way I do things, making this a SHOULD in this type of document pretty much means I'm going to have to add and document yet another configuration toggle, one that I personally don't see any value to (at least for the type of equipment we are producing). Making this a MAY allows those vendors who see this as a requirment to go ahead and implement this, while giving other vendors who see no such requirement the option to leave it out. Adam Machalek -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 24 07:06:02 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5OE62k7021284; Mon, 24 Jun 2002 07:06:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5OE61jR021283; Mon, 24 Jun 2002 07:06:01 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5OE5vk7021276 for ; Mon, 24 Jun 2002 07:05:58 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g5OE5wb03860; Mon, 24 Jun 2002 16:05:58 +0200 (MEST) Date: Mon, 24 Jun 2002 16:04:40 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Consensus on Site-Local Discussion To: Keith Moore Cc: Bob Hinden , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <200206211629.g5LGTd222997@astro.cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > the introduction of scoped addresses into the Internet architecture > has caused several problems for apps which are difficult to solve . > even if there's not consensus to do away with them entirely, > we need to understand how to minimize the damage, and that probably > means minimizing the use of limited-scope addresses. So it's not > clear to me that having the WG complete the current Scoped Address > Architecture document is an appropriate goal. Keith, Would it make sense to add the issues that limited-scoped addresses create for applications as issues to the scoped address architecture? I think having both this, plus the implementation issues for multi-sited nodes, listed in that document would provide useful information to the community. Another thing that can be contemplated relates to the "zeroconf" case (where some implementations might end up unnecessarily using smaller scope addresses when the "home" temporarily is disconnected) would be a recommendation that implementations try to provide address stability using stable storage. For instance, I think it is quite reasoanble that implementations that have stable storage retain their addresses and expiry times (preferred and valid) whether the addresses were acquired using RFC 2462 or DHCP. Assuming the lifetimes used are reasonable this techniques implies that a temporary outage (less than the preferred lifetime) will never result in the node loosing its global address even if the node were to reboot. Having said that, it isn't obvious to me in which document it would make sense to add such a recommendation. RFC2462bis? The scoped address architecture document? 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 Jun 24 07:21:17 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5OELGk7021313; Mon, 24 Jun 2002 07:21:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5OELGkO021312; Mon, 24 Jun 2002 07:21:16 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5OELCk7021305 for ; Mon, 24 Jun 2002 07:21:12 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA14313 for ; Mon, 24 Jun 2002 07:21:16 -0700 (PDT) Received: from astro.cs.utk.edu ([160.36.58.43]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA29375 for ; Mon, 24 Jun 2002 07:21:16 -0700 (PDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5OEHU205691; Mon, 24 Jun 2002 10:17:30 -0400 (EDT) Message-Id: <200206241417.g5OEHU205691@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Erik Nordmark cc: Keith Moore , Bob Hinden , ipng@sunroof.eng.sun.com Subject: Re: Consensus on Site-Local Discussion In-reply-to: (Your message of "Mon, 24 Jun 2002 16:04:40 +0200.") Date: Mon, 24 Jun 2002 10:17:30 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Would it make sense to add the issues that limited-scoped addresses > create for applications as issues to the scoped address architecture? maybe, but it's an issue for both v4 and v6, and it ties in with issues related to limited-duration addresses. it's kind of a mess, actually, both in that the issues are thorny and not easily reasolved, and in that the topic touches on so many different areas. I started working on a document to describe the problems that limited-scope addresses cause for apps, but I didn't finish by today's deadline. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 24 07:21:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5OELck7021341; Mon, 24 Jun 2002 07:21:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5OELcg4021340; Mon, 24 Jun 2002 07:21:38 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5OELYk7021333 for ; Mon, 24 Jun 2002 07:21:34 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA16437 for ; Mon, 24 Jun 2002 07:21:39 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.96.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA06773 for ; Mon, 24 Jun 2002 08:21:37 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g5OEKrM10146; Mon, 24 Jun 2002 21:20:55 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g5OEKCE18783; Mon, 24 Jun 2002 21:20:12 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Ralph Droms cc: "Michel Py" , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-Reply-To: <4.3.2.7.2.20020623173820.00ba1978@funnel.cisco.com> References: <4.3.2.7.2.20020623173820.00ba1978@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 24 Jun 2002 21:20:12 +0700 Message-ID: <18781.1024928412@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Sun, 23 Jun 2002 17:44:17 -0400 From: Ralph Droms Message-ID: <4.3.2.7.2.20020623173820.00ba1978@funnel.cisco.com> | I agree 100% with Micehls' point - assigning unique IDs to sites for use in | site-local addresses moves the site-local addresses into a globally | routable address space, with the additional feature that those addresses | are provider independent. Yes, as I've said - the proposals to stick IDs into SL addresses keeps getting shot down. I'm not sure that I think a lot of an argument that goes "well, someday someone might misuse it, so we'd better not have it at all", but that's not important for now. What matters here, is that "global" addresses from a non routable prefix have all of the same problems (they are identical, other than the bit pattern that makes up the prefix). 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 Jun 24 07:28:19 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5OESJk7021499; Mon, 24 Jun 2002 07:28:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5OESJNN021498; Mon, 24 Jun 2002 07:28:19 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5OESFk7021491 for ; Mon, 24 Jun 2002 07:28:15 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA11238 for ; Mon, 24 Jun 2002 07:28:19 -0700 (PDT) Received: from astro.cs.utk.edu ([160.36.58.43]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA25376 for ; Mon, 24 Jun 2002 08:28:19 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5OEKx206412; Mon, 24 Jun 2002 10:20:59 -0400 (EDT) Message-Id: <200206241420.g5OEKx206412@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Ralph Droms cc: "Michel Py" , "Robert Elz" , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-reply-to: (Your message of "Sun, 23 Jun 2002 17:44:17 EDT.") <4.3.2.7.2.20020623173820.00ba1978@funnel.cisco.com> Date: Mon, 24 Jun 2002 10:20:59 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I agree 100% with Micehls' point - assigning unique IDs to sites for use in > site-local addresses moves the site-local addresses into a globally > routable address space, with the additional feature that those addresses > are provider independent. The result would be an address space that is > site-local by (potentially unenforceable) executive fiat rather than by > technical design. this sounds like a feature to me, because it would allow hosts using such addresses to have their traffic routed between sites without NAT. private addresses were a bad idea; we should not repeat them in v6. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 24 07:51:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5OEpdk7021779; Mon, 24 Jun 2002 07:51:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5OEpc69021778; Mon, 24 Jun 2002 07:51:38 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5OEpZk7021771 for ; Mon, 24 Jun 2002 07:51:35 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA24378 for ; Mon, 24 Jun 2002 07:51:40 -0700 (PDT) Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA07669 for ; Mon, 24 Jun 2002 08:51:38 -0600 (MDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5OEow3o049476; Mon, 24 Jun 2002 16:50:59 +0200 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with SMTP id g5OEowx32730; Mon, 24 Jun 2002 16:50:58 +0200 Received: from dhcp23-199.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA31888 from ; Mon, 24 Jun 2002 16:50:53 +0200 Message-Id: <3D173202.89F09F64@hursley.ibm.com> Date: Mon, 24 Jun 2002 16:51:46 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Keith Moore Cc: Ralph Droms , Michel Py , Robert Elz , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols References: <200206241420.g5OEKx206412@astro.cs.utk.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith Moore wrote: > > > I agree 100% with Micehls' point - assigning unique IDs to sites for use in > > site-local addresses moves the site-local addresses into a globally > > routable address space, with the additional feature that those addresses > > are provider independent. The result would be an address space that is > > site-local by (potentially unenforceable) executive fiat rather than by > > technical design. > > this sounds like a feature to me, because it would allow hosts using > such addresses to have their traffic routed between sites without NAT. Not in the real world; these addresses wouldn't be routable because they won't aggregate. > > private addresses were a bad idea; we should not repeat them in v6. Indeed. That's not what SL addresses are, fortunately. Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 24 08:08:51 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5OF8ok7021952; Mon, 24 Jun 2002 08:08:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5OF8oVL021951; Mon, 24 Jun 2002 08:08:50 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5OF8lk7021944 for ; Mon, 24 Jun 2002 08:08:47 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA25490 for ; Mon, 24 Jun 2002 08:08:52 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA28113 for ; Mon, 24 Jun 2002 08:08:51 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g5OF8aW14359; Mon, 24 Jun 2002 18:08:36 +0300 Date: Mon, 24 Jun 2002 18:08:35 +0300 (EEST) From: Pekka Savola To: Adam Machalek cc: ipng@sunroof.eng.sun.com Subject: Re: Section 4.2.1 - draft-ietf-ipv6-node-requirements-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 Mon, 24 Jun 2002, Adam Machalek wrote: > With the way I do things, making this a SHOULD in this type of document > pretty much means I'm going to have to add and document yet another > configuration toggle, one that I personally don't see any value to (at > least for the type of equipment we are producing). Making this a MAY > allows those vendors who see this as a requirment to go ahead and implement > this, while giving other vendors who see no such requirement the option to > leave it out. You apparently consider SHOULD as almost a MUST. I support SHOULD in this case; it's meant for manually configured nodes, really. I certainly want to be able to manually configure my systems _if I want to_. You've convincing reasons why you don't want to implement that -- always use autoconfiguration. (I suspect you're dealing with small devices which cannot really be "configured" anyway). It's okay. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 24 08:13:44 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5OFDhk7022070; Mon, 24 Jun 2002 08:13:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5OFDhqV022069; Mon, 24 Jun 2002 08:13:43 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5OFDdk7022062 for ; Mon, 24 Jun 2002 08:13:39 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA26944 for ; Mon, 24 Jun 2002 08:13:44 -0700 (PDT) Received: from astro.cs.utk.edu ([160.36.58.43]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA18214 for ; Mon, 24 Jun 2002 09:13:43 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5OF4v212348; Mon, 24 Jun 2002 11:04:57 -0400 (EDT) Message-Id: <200206241504.g5OF4v212348@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Brian E Carpenter cc: Keith Moore , Ralph Droms , Michel Py , Robert Elz , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-reply-to: (Your message of "Mon, 24 Jun 2002 16:51:46 +0200.") <3D173202.89F09F64@hursley.ibm.com> Date: Mon, 24 Jun 2002 11:04:57 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > I agree 100% with Micehls' point - assigning unique IDs to sites for use in > > > site-local addresses moves the site-local addresses into a globally > > > routable address space, with the additional feature that those addresses > > > are provider independent. The result would be an address space that is > > > site-local by (potentially unenforceable) executive fiat rather than by > > > technical design. > > > > this sounds like a feature to me, because it would allow hosts using > > such addresses to have their traffic routed between sites without NAT. > > Not in the real world; these addresses wouldn't be routable because > they won't aggregate. they will be routable between private networks using bilateral agreements. one of the common use cases for NAT in v4 is to map between two or more networks that use private (thus overlapping) address space. if we want to avoid NATs in v6 we need to ensure that v6 addresses never overlap; that sites can get unique v6 addresses whether or not they're connected to the global internet. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 24 08:19:30 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5OFJTk7022130; Mon, 24 Jun 2002 08:19:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5OFJTdx022129; Mon, 24 Jun 2002 08:19:29 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5OFJQk7022122 for ; Mon, 24 Jun 2002 08:19:26 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA28039 for ; Mon, 24 Jun 2002 08:19:31 -0700 (PDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA16222 for ; Mon, 24 Jun 2002 09:19:30 -0600 (MDT) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g5OFBmK5020263; Mon, 24 Jun 2002 08:11:48 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ABX82992; Mon, 24 Jun 2002 08:08:59 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA16767; Mon, 24 Jun 2002 08:11:48 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15639.14004.691748.496554@thomasm-u1.cisco.com> Date: Mon, 24 Jun 2002 08:11:48 -0700 (PDT) To: Keith Moore Cc: Ralph Droms , "Michel Py" , "Robert Elz" , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-Reply-To: <200206241420.g5OEKx206412@astro.cs.utk.edu> References: <4.3.2.7.2.20020623173820.00ba1978@funnel.cisco.com> <200206241420.g5OEKx206412@astro.cs.utk.edu> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith Moore writes: > > I agree 100% with Micehls' point - assigning unique IDs to sites for use in > > site-local addresses moves the site-local addresses into a globally > > routable address space, with the additional feature that those addresses > > are provider independent. The result would be an address space that is > > site-local by (potentially unenforceable) executive fiat rather than by > > technical design. > > this sounds like a feature to me, because it would allow hosts using > such addresses to have their traffic routed between sites without NAT. > > private addresses were a bad idea; we should not repeat them in v6. So it seems to me that what's at issue here is what is the lesser of evils. I think one thing which we should all be able to agree about is that local addresses regardless of original intent will be used to access global address space. The basic problem here is renumbering -- and the fact that people don't want to do that. Since, its a tragedy of the commons problem, there is simply nothing we can do about this unless we create the Address Police who can arrest and execute those recalcitrant addressing scofflaws. Thus, we have the two options: site locals which are actually globally unique could relatively easily be made globally routable by simply advertising the prefix. The downside here is prefix aggregation doesn't happen. For large sites, this is probably not a big problem, but for small sites it could be a huge issue. The other alternative is essentially NAT/ALG's. We all know how that works, and what it does to the net. The thing I don't understand is whether the address aggregation problem introduced by a new class of globally unique addresses is really any worse than the existing problems with route aggregation, and specifically about mobility and multihoming. It's quite possible that we could make things significantly worse by introducing a new class of routing prefixes, but as far as I understand, the ultimate fix for routing table explosion isn't especially well understood, and it may require its own set of draconian measures *regardless* of site locals. On the other hand, we know for absolute certain that NAT's completely pooch the end to end principle and are well known evil. I guess I come down slightly in favor of avoiding the known evil in favor of the potentially unknown evil, but as they say, ignorance is bliss. Mike -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 24 08:30:05 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5OFU5k7022222; Mon, 24 Jun 2002 08:30:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5OFU5I2022221; Mon, 24 Jun 2002 08:30:05 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5OFU1k7022214 for ; Mon, 24 Jun 2002 08:30:01 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA00934 for ; Mon, 24 Jun 2002 08:30:05 -0700 (PDT) Received: from astro.cs.utk.edu ([160.36.58.43]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA25986 for ; Mon, 24 Jun 2002 09:30:04 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5OFM8214785; Mon, 24 Jun 2002 11:22:08 -0400 (EDT) Message-Id: <200206241522.g5OFM8214785@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Michael Thomas cc: Keith Moore , Ralph Droms , "Michel Py" , "Robert Elz" , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-reply-to: (Your message of "Mon, 24 Jun 2002 08:11:48 PDT.") <15639.14004.691748.496554@thomasm-u1.cisco.com> Date: Mon, 24 Jun 2002 11:22:07 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Keith Moore writes: > > > I agree 100% with Micehls' point - assigning unique IDs to sites for use in > > > site-local addresses moves the site-local addresses into a globally > > > routable address space, with the additional feature that those addresses > > > are provider independent. The result would be an address space that is > > > site-local by (potentially unenforceable) executive fiat rather than by > > > technical design. > > > > this sounds like a feature to me, because it would allow hosts using > > such addresses to have their traffic routed between sites without NAT. > > > > private addresses were a bad idea; we should not repeat them in v6. > > So it seems to me that what's at issue here is what > is the lesser of evils. I think this is a bit over-simplistic. Just because an address prefix is globally unique does not mean it will be widely advertised in routing tables, especially when such prefixes are easily distinguished from globally-routable prefixes. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 24 08:40:11 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5OFeBk7022680; Mon, 24 Jun 2002 08:40:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5OFeBkJ022679; Mon, 24 Jun 2002 08:40:11 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5OFe8k7022672 for ; Mon, 24 Jun 2002 08:40:08 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA08117 for ; Mon, 24 Jun 2002 08:40:13 -0700 (PDT) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA09345 for ; Mon, 24 Jun 2002 09:40:12 -0600 (MDT) Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 24 Jun 2002 08:40:12 -0700 Message-ID: <2B81403386729140A3A899A8B39B046405E14B@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Fwd: IPv6 Scoped Addresses and Routing Protocols Thread-Index: AcIbkzTOflJRuc5OQjSIKQqkEIE/bAAAPqmQ From: "Michel Py" To: "Keith Moore" , "Michael Thomas" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5OFe8k7022673 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> Michael Thomas wrote: >> So it seems to me that what's at issue here is what >> is the lesser of evils. >> Keith Moore >> I think this is a bit over-simplistic. Just because an >> address prefix is globally unique does not mean it will >> be widely advertised in routing tables, especially when >> such prefixes are easily distinguished from globally >> routable prefixes. Maybe, maybe not. We just don't know. Although I am not opposed in principle to site IDs in SL addresses, having this feature in the addressing architecture _now_ is a walking hazard. kre has convinced me to keep fe80::/10 instead of reducing it to fe80::/48 keeping the door open, but I oppose doing something about it now. About the lesser of evils, we don't have to make that choice either. There are other models being developed, have a sneak preview at: http://arneill-py.sacramento.ca.us/ipv6mh/geov6.txt Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 24 08:48:54 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5OFmsk7022901; Mon, 24 Jun 2002 08:48:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5OFmr53022900; Mon, 24 Jun 2002 08:48:53 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5OFmok7022890 for ; Mon, 24 Jun 2002 08:48:50 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA11025 for ; Mon, 24 Jun 2002 08:48:55 -0700 (PDT) Received: from [208.236.204.65] (gateus.nmss.com [208.236.204.65]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with SMTP id JAA15233 for ; Mon, 24 Jun 2002 09:48:55 -0600 (MDT) Received: from [10.1.3.12] by [208.236.204.65] via smtpd (for pheriche.sun.com [192.18.98.34]) with SMTP; 24 Jun 2002 10:44:47 UT Subject: Re: Section 4.2.1 - draft-ietf-ipv6-node-requirements-00.txt To: Pekka Savola Cc: Adam Machalek , ipng@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Adam Machalek" Date: Mon, 24 Jun 2002 10:48:49 -0500 X-MIMETrack: Serialize by Router on NAMASMTP02/NMS Communications(Release 5.0.10 |March 22, 2002) at 06/24/2002 11:45:06 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka wrote: >You apparently consider SHOULD as almost a MUST. >I support SHOULD in this case; it's meant for manually configured >nodes, really. I certainly want to be able to manually configure my >systems _if I want to_. >You've convincing reasons why you don't want to implement that -- always >use autoconfiguration. (I suspect you're dealing with small devices >which cannot really be "configured" anyway). It's okay. You are correct, as I interpret things, SHOULD implys you better have a good reason not to do something, and be able to back it up. I typically interrpret shoulds as almost a must is because sooner or later we'll get an RFP based on this type of document, and anything marked MUST and SHOULD gets marked as MUST in the RFP. Happens all the time. MAY on the otherhand is vendor specific, if you want to do it, or your customers desire it, go right ahead. It doesn't stop manually configured nodes the ability to manually configure. Adam Machalek -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 24 08:56:55 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5OFutk7022978; Mon, 24 Jun 2002 08:56:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5OFusHf022977; Mon, 24 Jun 2002 08:56:54 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5OFupk7022970 for ; Mon, 24 Jun 2002 08:56:51 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA08554 for ; Mon, 24 Jun 2002 08:56:56 -0700 (PDT) Received: from astro.cs.utk.edu ([160.36.58.43]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA29442 for ; Mon, 24 Jun 2002 08:56:56 -0700 (PDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5OFsD219281; Mon, 24 Jun 2002 11:54:14 -0400 (EDT) Message-Id: <200206241554.g5OFsD219281@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Michel Py" cc: "Keith Moore" , "Michael Thomas" , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-reply-to: (Your message of "Mon, 24 Jun 2002 08:40:12 PDT.") <2B81403386729140A3A899A8B39B046405E14B@server2000.arneill-py.sacramento.ca.us> Date: Mon, 24 Jun 2002 11:54:13 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >> Michael Thomas wrote: > >> So it seems to me that what's at issue here is what > >> is the lesser of evils. > > >> Keith Moore > >> I think this is a bit over-simplistic. Just because an > >> address prefix is globally unique does not mean it will > >> be widely advertised in routing tables, especially when > >> such prefixes are easily distinguished from globally > >> routable prefixes. > > Maybe, maybe not. We just don't know. Although I am not opposed in > principle to site IDs in SL addresses, having this feature in the > addressing architecture _now_ is a walking hazard. so is having SL addresses without site IDs. it's just that in one case the hazard is to the routing system, and in the other case the hazard is to apps and their ability to interoperate. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 24 09:10:28 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5OGARk7023029; Mon, 24 Jun 2002 09:10:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5OGARO0023028; Mon, 24 Jun 2002 09:10:27 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5OGANk7023021 for ; Mon, 24 Jun 2002 09:10:23 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA17632 for ; Mon, 24 Jun 2002 09:10:28 -0700 (PDT) Received: from astro.cs.utk.edu ([160.36.58.43]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA17811 for ; Mon, 24 Jun 2002 10:10:28 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5OG2O220497; Mon, 24 Jun 2002 12:02:24 -0400 (EDT) Message-Id: <200206241602.g5OG2O220497@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Robert Elz cc: Ralph Droms , "Michel Py" , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-reply-to: (Your message of "Mon, 24 Jun 2002 21:20:12 +0700.") <18781.1024928412@munnari.OZ.AU> Date: Mon, 24 Jun 2002 12:02:24 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I'm not sure that I think a lot of an argument that goes "well, someday > someone might misuse it, so we'd better not have it at all", but that's > not important for now. I don't think much of such arguments either To me arguments of the form "people need to solve problem X, and if we don't give them a way to do it that is friendly to the network they'll do it in a way that might not be friendly, so we'd better solve problem X" are much more convincing. There are several problems meeting this description - renumbering and routing between private sites being two that are handy. > What matters here, is that "global" addresses from a non routable prefix > have all of the same problems (they are identical, other than the bit > pattern that makes up the prefix). I think this is right. actually I think SLs with a site-id may actually be preferable than a global with a non-routable prefix, because the SL may be more easily distinguished from a normal address than the global. mainly I want a solution to the problem. apps need to be able to do address referrals and right now the algorithm for selecting which address to use is little better than a guess. anything we can do to make this faster or more reliable is a good thing, and SLs with site-ids are better for this than SLs without site-ids. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 24 16:21:13 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5ONLDk7024500; Mon, 24 Jun 2002 16:21:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5ONLDBA024499; Mon, 24 Jun 2002 16:21:13 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5ONLAk7024492 for ; Mon, 24 Jun 2002 16:21:10 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA03032 for ; Mon, 24 Jun 2002 16:21:15 -0700 (PDT) Received: from basit.cc (wireless.cs.twsu.edu [156.26.10.125]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA29260 for ; Mon, 24 Jun 2002 17:21:14 -0600 (MDT) Received: from localhost ([127.0.0.1]) by basit.cc with esmtp (Exim 4.05) id 17Md8y-0000ie-00 for ipng@sunroof.eng.sun.com; Mon, 24 Jun 2002 18:21:12 -0500 Date: Mon, 24 Jun 2002 18:21:12 -0500 (CDT) From: Abdul Basit X-X-Sender: basit@wireless.cs.twsu.edu To: ipng@sunroof.eng.sun.com Subject: stateless name auto-configuration? In-Reply-To: <200206241602.g5OG2O220497@astro.cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, I was just wondering whether we can put the 'stateless address auto-configuratition' schema inside the dns server somehow so it will the part of dns itself instead of a seprate router advertisement daemon. in this way, we will be able to dynamically assign the ipv6 address along with some sort of name as it is easy to remember the name and with rapid growth of devices in your network its almost impossible to manually configure dns for each and e very device (cell phones ).. p[leae let me know if theren is already some mechanism there to solve this problem ? - basit -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 24 17:05:50 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5P05ok7024581; Mon, 24 Jun 2002 17:05:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5P05ojr024580; Mon, 24 Jun 2002 17:05:50 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5P05lk7024573 for ; Mon, 24 Jun 2002 17:05:47 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA01804 for ; Mon, 24 Jun 2002 17:05:53 -0700 (PDT) Received: from tndh.net (evrtwa1-ar8-4-65-028-011.evrtwa1.dsl-verizon.net [4.65.28.11]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA14594 for ; Mon, 24 Jun 2002 18:05:48 -0600 (MDT) Received: from eagleswings (127.0.0.1) by localhost (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Mon, 24 Jun 2002 17:05:59 -0700 From: "Tony Hain" To: "Abdul Basit" , Subject: RE: stateless name auto-configuration? Date: Mon, 24 Jun 2002 17:04:57 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Abdul Basit wrote: > Hi, > > I was just wondering whether we can put the 'stateless > address auto-configuratition' schema inside the dns server somehow > so it will the part of dns itself instead of a seprate > router advertisement daemon. > > in this way, we will be able to dynamically assign the ipv6 > address along with some sort of name as it is easy to remember > the name and with rapid growth of devices in your network > its almost impossible to manually configure dns for each and e very > device (cell phones ).. > > p[leae let me know if theren is already some mechanism there > to solve this problem ? > RFC 3007 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 24 19:15:05 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5P2F5k7024934; Mon, 24 Jun 2002 19:15:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5P2F5K0024933; Mon, 24 Jun 2002 19:15:05 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5P2F2k7024926 for ; Mon, 24 Jun 2002 19:15:02 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA03869 for ; Mon, 24 Jun 2002 19:15:07 -0700 (PDT) Received: from cichlid.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA28901 for ; Mon, 24 Jun 2002 20:15:06 -0600 (MDT) Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id g5P2Dd202762; Mon, 24 Jun 2002 22:13:39 -0400 Message-Id: <200206250213.g5P2Dd202762@cichlid.adsl.duke.edu> To: Keith Moore cc: ipng@sunroof.eng.sun.com Subject: Re: Consensus on Site-Local Discussion In-Reply-To: Message from Keith Moore of "Fri, 21 Jun 2002 12:29:39 EDT." <200206211629.g5LGTd222997@astro.cs.utk.edu> Date: Mon, 24 Jun 2002 22:13:39 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith, > I don't agree that the Default Address Selection document should > be published without change, and I don't think we have consensus on > that at all. though perhaps the sections on SL are okay. > (not sure what you meant here by "no change") Could you please be clear on what you mean above? A revised version of draft-ietf-ipv6-default-addr-select-08.txt was submitted last week with a note summarizing changes to the list. If you (or anyone) has issues with that document, please be specific about what wording you disagree with and how you think it needs changing. 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 Mon Jun 24 23:06:10 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5P669k7025289; Mon, 24 Jun 2002 23:06:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5P669kd025288; Mon, 24 Jun 2002 23:06:09 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5P666k7025281 for ; Mon, 24 Jun 2002 23:06:06 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA06196 for ; Mon, 24 Jun 2002 23:06:12 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA02497 for ; Tue, 25 Jun 2002 00:06:11 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g5P661g21899; Tue, 25 Jun 2002 09:06:02 +0300 Date: Tue, 25 Jun 2002 09:06:01 +0300 (EEST) From: Pekka Savola To: Abdul Basit cc: ipng@sunroof.eng.sun.com Subject: Re: stateless name auto-configuration? 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 http://search.ietf.org/internet-drafts/draft-kitamura-ipv6-name-auto-reg-01.txt http://search.ietf.org/internet-drafts/draft-gopinath-ipv6-hostname-auto-reg-01.txt On Mon, 24 Jun 2002, Abdul Basit wrote: > > Hi, > > I was just wondering whether we can put the 'stateless > address auto-configuratition' schema inside the dns server somehow > so it will the part of dns itself instead of a seprate > router advertisement daemon. > > in this way, we will be able to dynamically assign the ipv6 > address along with some sort of name as it is easy to remember > the name and with rapid growth of devices in your network > its almost impossible to manually configure dns for each and e very > device (cell phones ).. > > p[leae let me know if theren is already some mechanism there > to solve this problem ? > > - basit > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 25 01:13:13 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5P8DCk7025601; Tue, 25 Jun 2002 01:13:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5P8DC0H025600; Tue, 25 Jun 2002 01:13:12 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5P8D9k7025593 for ; Tue, 25 Jun 2002 01:13:09 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA04604 for ; Tue, 25 Jun 2002 01:13:14 -0700 (PDT) Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA12744 for ; Tue, 25 Jun 2002 02:13:13 -0600 (MDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5P8D5Qs073432; Tue, 25 Jun 2002 10:13:05 +0200 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with SMTP id g5P8D5Y63430; Tue, 25 Jun 2002 10:13:05 +0200 Received: from dhcp23-199.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA53704 from ; Tue, 25 Jun 2002 10:13:03 +0200 Message-Id: <3D182644.D50B45B1@hursley.ibm.com> Date: Tue, 25 Jun 2002 10:13:56 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Michel Py Cc: ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols References: <2B81403386729140A3A899A8B39B046405E14B@server2000.arneill-py.sacramento.ca.us> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Michel Py wrote: ... > There are other models being developed, have a sneak preview at: > http://arneill-py.sacramento.ca.us/ipv6mh/geov6.txt Nobody doubts that we have enough addresses to allocate them geographically. What we don't know is how to route them geographically, so I confess that I fail to see the value of compiling long lists of numbers. 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 Jun 25 04:06:27 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5PB6Rk7026276; Tue, 25 Jun 2002 04:06:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5PB6RKb026275; Tue, 25 Jun 2002 04:06:27 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5PB6Nk7026263 for ; Tue, 25 Jun 2002 04:06:23 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA03141 for ; Tue, 25 Jun 2002 04:06:27 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA15217 for ; Tue, 25 Jun 2002 05:06:26 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g5PB6NI25936 for ; Tue, 25 Jun 2002 14:06:23 +0300 Date: Tue, 25 Jun 2002 14:06:23 +0300 (EEST) From: Pekka Savola To: ipng@sunroof.eng.sun.com Subject: Comments on Node Requirements document Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, Some comments. In general, I think the approach is a good one. However, in the next revisions (as was probably intended) there possibly needs to be much more detailed descriptions on what is really necessary and what not. Also, in some areas there may be need for a "Discussion" part. And more detailed ones.. 3.2 RFC2467 - A Method for the Transmission of IPv6 Packets over FDDI Networks A Method for the Transmission of IPv6 Packets over FDDI Networks [RFC-2467] is conditionally mandatory if the node has a FDDI interface. [and others] ==> I'm not sure if this 'has XXX interface' is the right wording. IMO, it's perfectly ok for an OS to be a conformant IPv6 node and NOT support some legacy interfaces like FDDI or Token Ring, or whatnot. This is more of a question what are the supported interfaces. 3.6 RFC2492 - IPv6 over ATM Networks IPv6 over ATM Networks [RFC2492] is conditionally mandatory if the node has an ATM interface. ==> PVC features yes, but are SVC functionalities also mandatory? 4.1.1 RFC2460 - Internet Protocol Version 6 Nodes must always be able to receive fragment headers. However, if it does not implement path MTU it may not need to send fragment headers. ==> path MTU discovery. ==> take a look at draft-savola-ipv6-rh-hosts-00.txt, does some text regarding the processing of RH's belong here or do we need to issue some corrective/clarificative RFC's? 4.2.1 RFC2461 - Neighbor Discovery for IPv6 Receiving Router Advertisement is unconditionally mandatory for host implementation, with a configuration option to disable this functionality. ==> I guess the node must also process the RA, but that's semantics. Are all features (now and future :-) in RA's a must to implement and support? 4.3.2 RFC2675 - IPv6 Jumbograms IPv6 Jumbograms [RFC2675] is unconditionally optional. 4.4 ICMPv6 ICMPv6 [RFC 2463] is Unconditionally Mandatory. ==> there seem to be some differences with the capitalization of the magic words. 4.6.2 RFC2710 - Multicast Listener Discovery (MLD) for IPv6 Multicast Listener Discovery [RFC-2710] is Conditionally Mandatory, where the condition is if the node joins any multicast groups other than the all-nodes-on-link group (which will always be the case if it runs ND or DAD on the link). ==> That condition is this? The node always joins its solicited multicast addresses (at least for link-local addresses), so this section would seem to always evaluate to "Mandatory" ?? 9.1 RFC2711 - IPv6 Router Alert Option The Router Alert Option [RFC-2711] is conditionally mandatory if the node does performs packet forwarding at the IP layer. ==> s/does performs/does perform/ ? ==> what kind of IP router is it if it doesn't forward packets at the IP layer? (I have no idea..) -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 25 04:15:11 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5PBFBk7026353; Tue, 25 Jun 2002 04:15:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5PBFBss026352; Tue, 25 Jun 2002 04:15:11 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5PBF8k7026345 for ; Tue, 25 Jun 2002 04:15:08 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA04179 for ; Tue, 25 Jun 2002 04:15:12 -0700 (PDT) Received: from Mistralsoftware.com (ptil-243-146-ban.primus-india.net [203.196.146.243] (may be forged)) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA02705 for ; Tue, 25 Jun 2002 05:15:07 -0600 (MDT) Received: from anji [192.168.15.19] by mistralsoftware.com [192.168.10.12] with SMTP (MDaemon.PRO.v5.0.0.R) for ; Tue, 25 Jun 2002 16:58:38 +0530 Message-ID: <009501c21c39$5ff99160$130fa8c0@anji> From: "Anjaneyulu" To: Subject: Hop Limit in Router Advertisement????????? Date: Tue, 25 Jun 2002 16:43:46 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0092_01C21C67.798EB500" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-MDRemoteIP: 192.168.15.19 X-Return-Path: anjaneyulu@mistralsoftware.com X-MDaemon-Deliver-To: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0092_01C21C67.798EB500 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi All, The ND RFC 2461 specifies that the Hop Limit in the IPv6 Header be set = to 255 for Router Advertisement. But as far as i understand the router Advertisement should not be = propagated out of the Link by a router. Why is the Hop Limit Value 255???? it can be set to 1 same as that in = IPv4!!!!!!! Does this value 255 value that the router advertisement can be = propagated across 255 Hops???? Regards, Anj ------=_NextPart_000_0092_01C21C67.798EB500 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi All,
The ND RFC 2461 specifies that the Hop = Limit in the=20 IPv6 Header be set to 255 for Router Advertisement.
 
But as far as i understand the router = Advertisement=20 should not be propagated out of the Link by a router.
Why is the Hop Limit Value 255???? it = can be set to=20 1 same as that in IPv4!!!!!!!
 
Does this value 255 value that the = router=20 advertisement can be propagated  across 255 = Hops????
 
 
Regards,
Anj
------=_NextPart_000_0092_01C21C67.798EB500-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 25 04:22:44 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5PBMik7026384; Tue, 25 Jun 2002 04:22:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5PBMivS026383; Tue, 25 Jun 2002 04:22:44 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5PBMfk7026376 for ; Tue, 25 Jun 2002 04:22:41 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA28729 for ; Tue, 25 Jun 2002 04:22:45 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA05119 for ; Tue, 25 Jun 2002 05:22:44 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g5PBMeI26064; Tue, 25 Jun 2002 14:22:40 +0300 Date: Tue, 25 Jun 2002 14:22:40 +0300 (EEST) From: Pekka Savola To: Anjaneyulu cc: ipng@sunroof.eng.sun.com Subject: Re: Hop Limit in Router Advertisement????????? In-Reply-To: <009501c21c39$5ff99160$130fa8c0@anji> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 25 Jun 2002, Anjaneyulu wrote: > Hi All, > The ND RFC 2461 specifies that the Hop Limit in the IPv6 Header be set to 255 for Router Advertisement. > > But as far as i understand the router Advertisement should not be propagated out of the Link by a router. > Why is the Hop Limit Value 255???? it can be set to 1 same as that in IPv4!!!!!!! > > Does this value 255 value that the router advertisement can be propagated across 255 Hops???? Please read RFC2461 again, in particular section 3.1!!!!!!!!!!!!!!!!!!!!! -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 25 05:05:17 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5PC5Hk7026615; Tue, 25 Jun 2002 05:05:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5PC5Hvs026614; Tue, 25 Jun 2002 05:05:17 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5PC5Ek7026607 for ; Tue, 25 Jun 2002 05:05:14 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA06179 for ; Tue, 25 Jun 2002 05:05:19 -0700 (PDT) From: john.loughney@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA28050 for ; Tue, 25 Jun 2002 05:05:18 -0700 (PDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g5PC5ki00241 for ; Tue, 25 Jun 2002 15:05:46 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 25 Jun 2002 15:05:17 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 25 Jun 2002 15:05:17 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Comments on Node Requirements document Date: Tue, 25 Jun 2002 15:05:16 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC6551D@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on Node Requirements document Thread-Index: AcIcOJkPCvMcr05bTruVTRvHTTiCowABziTg To: , X-OriginalArrivalTime: 25 Jun 2002 12:05:17.0017 (UTC) FILETIME=[91D89490:01C21C40] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5PC5Ek7026608 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Pekka, > In general, I think the approach is a good one. Thanks, I was initially trying to get feedback on the format ... > However, in the next revisions (as was probably intended) there possibly needs to > be much more detailed descriptions on what is really necessary and what > not. Also, in some areas there may be need for a "Discussion" part. Definately, feel free to suggest text. > > > And more detailed ones.. > > 3.2 RFC2467 - A Method for the Transmission of IPv6 Packets > over FDDI > Networks > > A Method for the Transmission of IPv6 Packets over FDDI Networks > [RFC-2467] is conditionally mandatory if the node has a FDDI > interface. > [and others] > > ==> I'm not sure if this 'has XXX interface' is the right wording. IMO, > it's perfectly ok for an OS to be a conformant IPv6 node and NOT support > some legacy interfaces like FDDI or Token Ring, or whatnot. This is more > of a question what are the supported interfaces. The idea is that these only need to be implemented if there to use one of the interfaces. In most cases, you won't need support for legacy interfaces. > 3.6 RFC2492 - IPv6 over ATM Networks > > IPv6 over ATM Networks [RFC2492] is conditionally mandatory if the > node has an ATM interface. > > ==> PVC features yes, but are SVC functionalities also mandatory? This one I need to dig into more, I must admit to not being an IPv6 over ATM expert. > 4.1.1 RFC2460 - Internet Protocol Version 6 > > Nodes must always be able to receive fragment headers. However, if it > does not implement path MTU it may not need to send fragment headers. > > ==> path MTU discovery. will fix. > ==> take a look at draft-savola-ipv6-rh-hosts-00.txt, does some text > regarding the processing of RH's belong here or do we need to > issue some corrective/clarificative RFC's? I will look at it and see what kind of text is needed. > 4.2.1 RFC2461 - Neighbor Discovery for IPv6 > > Receiving Router Advertisement is unconditionally > mandatory for host > implementation, with a configuration option to disable this > functionality. > > ==> I guess the node must also process the RA, but that's semantics. Are > all features (now and future :-) in RA's a must to implement > and support? I will need look into clarification fior this. > 4.3.2 RFC2675 - IPv6 Jumbograms > > IPv6 Jumbograms [RFC2675] is unconditionally optional. > > 4.4 ICMPv6 > > ICMPv6 [RFC 2463] is Unconditionally Mandatory. > > ==> there seem to be some differences with the capitalization > of the magic > words. Will fix. > 4.6.2 RFC2710 - Multicast Listener Discovery (MLD) for IPv6 > > Multicast Listener Discovery [RFC-2710] is Conditionally Mandatory, > where the condition is if the node joins any multicast groups other > than the all-nodes-on-link group (which will always be the case if it > runs ND or DAD on the link). > > ==> That condition is this? The node always joins its solicited multicast > addresses (at least for link-local addresses), so this section would seem > to always evaluate to "Mandatory" ?? There has been some off-list discussion that hosts may not be able to depend on MLD if there is no connection to a router, therefore this may not be Mandatory. I think we need some discussion on this. > 9.1 RFC2711 - IPv6 Router Alert Option > > The Router Alert Option [RFC-2711] is conditionally > mandatory if the > node does performs packet forwarding at the IP layer. > > ==> s/does performs/does perform/ ? Will fix. > ==> what kind of IP router is it if it doesn't forward > packets at the IP layer? (I have no idea..) I get your point ... John -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 25 07:48:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5PEmZk7027192; Tue, 25 Jun 2002 07:48:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5PEmYOK027191; Tue, 25 Jun 2002 07:48:34 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5PEmVk7027184 for ; Tue, 25 Jun 2002 07:48:31 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA15781 for ; Tue, 25 Jun 2002 07:48:35 -0700 (PDT) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA02721 for ; Tue, 25 Jun 2002 08:48:35 -0600 (MDT) Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 25 Jun 2002 07:48:34 -0700 Message-ID: <2B81403386729140A3A899A8B39B046406C893@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Fwd: IPv6 Scoped Addresses and Routing Protocols Thread-Index: AcIcIDMOGVne9rnWTCSDcBMRZ5Aa4gANtoqA From: "Michel Py" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5PEmWk7027185 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, >> Michel Py wrote: >> There are other models being developed, have a sneak preview at: >> http://arneill-py.sacramento.ca.us/ipv6mh/geov6.txt > Brian Carpenter wrote: > Nobody doubts that we have enough addresses to allocate them > geographically. What we don't know is how to route them > geographically, so I confess that I fail to see the value of > compiling long lists of numbers. The associated drafts are coming in a matter of days, stay tuned. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 25 08:02:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5PF28k7027416; Tue, 25 Jun 2002 08:02:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5PF282l027415; Tue, 25 Jun 2002 08:02:08 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5PF24k7027405 for ; Tue, 25 Jun 2002 08:02:04 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA14893 for ; Tue, 25 Jun 2002 08:02:08 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA16764 for ; Tue, 25 Jun 2002 09:02:07 -0600 (MDT) Received: from kenawang ([147.11.233.8]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id IAA08194; Tue, 25 Jun 2002 08:00:38 -0700 (PDT) Message-Id: <4.2.2.20020625105324.021f7e50@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 25 Jun 2002 11:02:15 -0400 To: ipng@sunroof.eng.sun.com From: Margaret Wasserman Subject: Re: I-D ACTION:draft-ietf-ipv6-default-addr-select-08.txt Cc: Robert Elz , Keith Moore , "Richard Draves" , Brian Carpenter In-Reply-To: <200206211445.g5LEjK208003@astro.cs.utk.edu> References: <(Your message of "Fri, 21 Jun 2002 14:47:10 +0700.") <7149.1024645630@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi All, The Default Address Selection draft is currently with IESG, waiting for approval for PS. There was clear consensus in the WG to send this document to the IESG, we held a WG last call, and it has since been updated based on IESG feedback. I have followed this discussion, and it is clear that one or two people object to the changes made based on IESG review. However, I don't see any WG consensus that there are problems with this document that should block its publication as a PS. Thoughts? Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 25 08:45:57 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5PFjuk7027515; Tue, 25 Jun 2002 08:45:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5PFjuTN027514; Tue, 25 Jun 2002 08:45:56 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5PFjqk7027507 for ; Tue, 25 Jun 2002 08:45:52 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA27849 for ; Tue, 25 Jun 2002 08:45:57 -0700 (PDT) Received: from astro.cs.utk.edu ([160.36.58.43]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA10221 for ; Tue, 25 Jun 2002 09:45:56 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5PFja218492; Tue, 25 Jun 2002 11:45:36 -0400 (EDT) Message-Id: <200206251545.g5PFja218492@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Margaret Wasserman cc: ipng@sunroof.eng.sun.com, Robert Elz , Keith Moore , "Richard Draves" , Brian Carpenter Subject: Re: I-D ACTION:draft-ietf-ipv6-default-addr-select-08.txt In-reply-to: (Your message of "Tue, 25 Jun 2002 11:02:15 EDT.") <4.2.2.20020625105324.021f7e50@mail.windriver.com> Date: Tue, 25 Jun 2002 11:45:36 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Hi All, > > The Default Address Selection draft is currently with IESG, waiting > for approval for PS. There was clear consensus in the WG to send this > document to the IESG, we held a WG last call, and it has since been > updated based on IESG feedback. > > I have followed this discussion, and it is clear that one or two people > object to the changes made based on IESG review. However, I don't see > any WG consensus that there are problems with this document that should > block its publication as a PS. > > Thoughts? > > Margaret I want to reread the current version of the document in its entirety (haven't had time to do that yet) before stating a specific opinion on this document. I continue to have strong reservations about the use of limited-scope addresses; and about the expectation that hosts and applications can make reasonable choices from a set of addresses where some of those addresses will not work efficiently, reliably or at all. Given that such choices are forced on applications and hosts, I also have reservations about a "one size fits all" set of rules for address selection, since it seems to me that different applications have different needs which conflict (e.g. some need address stability more than address portability, some vice versa) Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 25 14:56:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5PLumk7029041; Tue, 25 Jun 2002 14:56:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5PLumTA029040; Tue, 25 Jun 2002 14:56:48 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5PLuik7029033 for ; Tue, 25 Jun 2002 14:56:44 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA16767 for ; Tue, 25 Jun 2002 14:56:49 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA18954 for ; Tue, 25 Jun 2002 15:56:48 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA11139; Tue, 25 Jun 2002 14:56:47 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g5PLuls05204; Tue, 25 Jun 2002 14:56:47 -0700 X-mProtect: <200206252156> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (4.22.78.78, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpd58kbzM; Tue, 25 Jun 2002 14:56:44 PDT Message-Id: <4.3.2.7.2.20020625142522.0268e188@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 25 Jun 2002 14:56:41 -0700 To: Keith Moore From: Bob Hinden Subject: Re: I-D ACTION:draft-ietf-ipv6-default-addr-select-08.txt Cc: ipng@sunroof.eng.sun.com In-Reply-To: <200206251545.g5PFja218492@astro.cs.utk.edu> References: <(Your message of "Tue, 25 Jun 2002 11:02:15 EDT.") <4.2.2.20020625105324.021f7e50@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith, >I continue to have strong reservations about the use of limited-scope >addresses; and about the expectation that hosts and applications can >make reasonable choices from a set of addresses where some of those >addresses will not work efficiently, reliably or at all. Given that >such choices are forced on applications and hosts, I also have >reservations about a "one size fits all" set of rules for address >selection, since it seems to me that different applications have >different needs which conflict (e.g. some need address stability more >than address portability, some vice versa) To clarify this issue, is your main objection is in regard to the IESG requested text? Specifically: An implementation MUST support a per-connection configuration mechanism (for example, an API extension) to reverse the sense of this preference and prefer temporary addresses over public addresses. Your argument is that this choice can only be made by applications and should not be be made on a more granular basis (e.g., host, interface, etc.). Are you proposing that this text be removed? Other views on this? Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 25 15:21:00 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5PMKxk7029094; Tue, 25 Jun 2002 15:20:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5PMKxEj029093; Tue, 25 Jun 2002 15:20:59 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5PMKtk7029086 for ; Tue, 25 Jun 2002 15:20:55 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA26725 for ; Tue, 25 Jun 2002 15:21:00 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA00224 for ; Tue, 25 Jun 2002 15:20:59 -0700 (PDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5PMKv204922; Tue, 25 Jun 2002 18:20:57 -0400 (EDT) Message-Id: <200206252220.g5PMKv204922@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Bob Hinden cc: Keith Moore , ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-ietf-ipv6-default-addr-select-08.txt In-reply-to: (Your message of "Tue, 25 Jun 2002 14:56:41 PDT.") <4.3.2.7.2.20020625142522.0268e188@mailhost.iprg.nokia.com> Date: Tue, 25 Jun 2002 18:20:57 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > To clarify this issue, is your main objection is in regard to the IESG > requested text? Specifically: > > An implementation MUST support a per-connection configuration > mechanism (for example, an API extension) to reverse the sense of > this preference and prefer temporary addresses over public > addresses. > > Your argument is that this choice can only be made by applications and > should not be be made on a more granular basis (e.g., host, interface, > etc.). Are you proposing that this text be removed? No, I'm not proposing that the text be removed (though the wording seems awkward to me). Actually I'm not sure what changes to propose yet - I am still trying to understand all the implications of limited-scope addresses, limited-duration addresses, and expecting apps or hosts to do address selection. At this point I'm guessing that I would recommend slight tweaks to the algorithm itself, along with a strong statement as to the (narrowness of the) applicability of the algorithm and several of the types of addresses. But trying to address the question in dozens of short emails that are quick responses to things that other people wrote, really doesn't seem like an effective way to understand or argue for what is needed. So my earlier "strong reservations" statement was mainly intended to avoid my silence being taken as assent to the document as it stands. Keith p.s. to Bob: I don't know whether this will reach you directly, as your mailer has been bouncing mail from me, claiming that the host that it's sent from doesn't have a domain name...which of course it does. But maybe it will reach you via the list. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 26 03:35:44 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5QAZik7000571; Wed, 26 Jun 2002 03:35:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5QAZhUI000570; Wed, 26 Jun 2002 03:35:43 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5QAZdk7000563 for ; Wed, 26 Jun 2002 03:35:40 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA23792 for ; Wed, 26 Jun 2002 03:35:42 -0700 (PDT) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA25768 for ; Wed, 26 Jun 2002 04:35:41 -0600 (MDT) Date: Wed, 26 Jun 2002 04:35:41 -0600 (MDT) Message-Id: <200206261035.EAA25768@patan.sun.com> Received: from Tgcttxp ([24.201.61.27]) by relais.videotron.ca (Videotron-Netscape Messaging Server v4.15 MTA-PRD4) with SMTP id GYB6JQ00.TUQ for ; Wed, 26 Jun 2002 06:31:02 -0400 From: sekiya To: ipng@sunroof.eng.sun.com Subject: Hello,let's be friends MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=PNnNYkX839Mh969jK9c09G7 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --PNnNYkX839Mh969jK9c09G7 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable --PNnNYkX839Mh969jK9c09G7 Content-Type: audio/x-midi; name=where.pif Content-Transfer-Encoding: base64 Content-ID: TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAA2AAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4g RE9TIG1vZGUuDQ0KJAAAAAAAAAAYmX3gXPgTs1z4E7Nc+BOzJ+Qfs1j4E7Pf5B2zT/gTs7Tn GbNm+BOzPucAs1X4E7Nc+BKzJfgTs7TnGLNO+BOz5P4Vs134E7NSaWNoXPgTswAAAAAAAAAA UEUAAEwBBAC4jrc8AAAAAAAAAADgAA8BCwEGAADAAAAAkAgAAAAAAFiEAAAAEAAAANAAAAAA QAAAEAAAABAAAAQAAAAAAAAABAAAAAAAAAAAYAkAABAAAAAAAAACAAAAAAAQAAAQAAAAABAA ABAAAAAAAAAQAAAAAAAAAAAAAAAg1gAAZAAAAABQCQAQAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ANAAAOwBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAudGV4dAAAAEq6AAAAEAAAAMAAAAAQ AAAAAAAAAAAAAAAAAAAgAABgLnJkYXRhAAAiEAAAANAAAAAgAAAA0AAAAAAAAAAAAAAAAAAA QAAAQC5kYXRhAAAAbF4IAADwAAAAUAAAAPAAAAAAAAAAAAAAAAAAAEAAAMAucnNyYwAAABAA AAAAUAkAEAAAAABAAQAAAAAAAAAAAAAAAABAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFWL7IPsFItF EFNWM/ZXM9uJdeyJdfiJRfA7dRAPjW8BAACLRfBqA1o7wolV9H0DiUX0i030uD09PT2Nffxm q4XJqn4Vi0UIjX38A/CLwcHpAvOli8gjyvOkik38isHA6AKF24hF/3Qmi30Uhf9+J4vDi3UM K0X4mff/hdJ1G8YEMw1DxgQzCkODRfgC6wuLdQyLfRTrA4t1DA+2Rf+LFTDwQACA4QPA4QSK BBCIBDOKRf2K0EPA6gQCyoXbdCGF/34di8MrRfiZ9/+F0nUOxgQzDUPGBDMKQ4NF+AKKRf2L FTDwQAAkDw+2ycDgAooMEYgMM4pN/orRQ8DqBgLChduIRf90HoX/fhqLwytF+Jn3/4XSdQ7G BDMNQ8YEMwpDg0X4Ag+2Rf+LFTDwQACKBBCIBDNDg330An8FxkQz/z2A4T+F23Qehf9+GovD K0X4mff/hdJ1DsYEMw1DxgQzCkODRfgCD7bBiw0w8EAAigQIiAQzQ4N99AF/BcZEM/89i3Xs g8YDg23wA4l17OmI/v//X4vDXlvJw1WL7IHsEAEAAINl+ACNRfxQagRoUgJBAOjJIgAAWVlQ aAIAAID/FUzQQACFwA+FtwAAAFNWV7uLCUEAUFPo1CIAAFmJRfRZjYXw/v//aAQBAABQ/3X4 /3X8/xVQ0EAAhcB1e42F8P7//1DowbUAADP/WTl99H5fV1PoaCIAAFCNhfD+//9Q6GUqAACD xBCFwHQ+aJMLQQD/FfTQQACL8IX2dC1qAmiTDEEA6DciAABZWVBW/xU40UAAhcB0DI2N8P7/ /1H/dfz/0Fb/FfDQQABHO330fKH/Rfjpaf////91/P8VXNBAAF9eW8nDVYvsgewUCAAAjUUM VoNl/ABQ/3UMvgAEAACJdfSJdfj/dQj/FUzQQACFwHQHM8Dp7AAAAFNXv4sJQQBqAFfo5yEA AFmJRQhZjUX4M9tQjYXs9///UI1F8FCNRfRTUI2F7Pv//4l19FCJdfj/dfz/dQz/FUTQQACF wA+FlAAAAIN98AF0BiCF7Pf//42F7Pv//1DorbQAAI2F7Pf//1DoobQAAIN9CABZWX5gU1fo SCEAAIlF7FCNhez7//9Q6EIpAACDxBCFwHUs/3XsjYXs9///UOgsKQAAWYXAWXUXjYXs+/// aDTwQABQ6O1iAABZhcBZdRCNhez7//9Q/3UM/xVU0EAAQztdCHyg/0X86TX/////dQz/FVzQ QABfM8BbXsnCCABVi+yB7AACAABW6OD9//+NhQD+//9qAlDoHSkAAFmNhQD+//9ZvgIAAIBQ Vuiq/v//jYUA/v//agZQ6PsoAABZjYUA/v//WVBW6I3+//9eycNVi+yB7EQEAABTaMDwQADo MmQAADPbxwQkBA5BAFOJRezoKUAAAFNoxQtBAOiDIAAAg8QQiUX8jYW8+///aAQBAABQU/8V FNFAAP91CMeFwPz//yQCAABqCOjsYQAAjY3A/P//iUXoUVDo1mEAAIXAD4R/AQAAjYXg/f// UI2F5P7//1DozWIAAI2F5P7//1CNhbz7//9Q6Iq0AACDxBCFwA+ETgEAAP+1yPz//1No/w8f AP8VINFAADvDiUX0D4QxAQAAVr4AAAgAV1a/0DFBAFNX6B5iAACLhdj8//+DxAw7xnICi8Y5 XQyJXfh1HY1N+FFQV/+11Pz///919P8VGNFAAIXAD4TbAAAAOV38iV0ID4bPAAAA/3UIaMUL QQDoXx8AAFCJRfDoGGMAADP2g8QMOXUMi9h0CI1DbolF+OsDi0X4K8OD6AoPhIgAAAD/deyN vtAxQQBXaMDwQADoErMAAIPEDIXAdGaDfQwAdSBTV/918Oj7sgAAg8QMhcB0D4tF+EYrw4Po CjvwcsHrR2oA/3X0/xUo0UAAajL/FSzRQABqAWjwDUEA6NQeAABQjYXk/v//UOjRJgAAg8QQ hcB1DY2F5P7//1DoOykAAFmLRfxAiUUI/0UIi0UIO0X8D4Ix/////3X0/xUk0UAAagFbX17/ dej/FSTRQACLw1vJwggAVYvsgew4AgAAU1ZXal9eM9tTaIsJQQDokx4AAFmJRfxZjUYBamSZ Wff5agpZi8KJRfiZ9/mF0nUF6Gz9//9TagLHhcz+//8oAQAA6PVfAACNjcz+//+JRfRRUOjx XwAAhcAPhKcAAACNhcj9//9TUFONhfD+//9TUOg+YgAAjYXI/f//UOg/sQAAg8QYOV34dQxT /7XU/v//6F39//8z/zP2OV38fk5WaIsJQQDozR0AAFCNhcj9//9Q6GKyAACDxBCFwHUli0X8 SDvwdQg5HQA5SQB0FWoBX1f/tdT+///oFv3//4k9PBNBAEY7dfx8tjv7dQaJHTwTQQCNhcz+ //9Q/3X06EFfAADpUf////919P8VJNFAADkd8DhJAHQcaOQ1SQBo3DNJAGjgNEkAaAIAAIDo Ey8AAIPEEGpk/xUs0UAAi3X46dX+//+LwcNVi+xRUVNWV2oCWovxagQz/zl9EFm4AAAAgIva iU34iX38iT6JfgSJfgh1CrgAAADAi9mJVfg5fQh0NVdqIGoDV2oBUP91CP8V/NBAAIP4/4kG dF2NTfxRUP8V7NBAADl9/IlGDHUdi00MO890AokBV1dXU1f/Nv8VBNFAADvHiUYEdQr/Nv8V JNFAAOsjV1dX/3X4UP8VCNFAADvHiUYIdRH/dgSLPSTRQAD/1/82/9czwF9eW8nCDABWi/FX i0YIhcB0B1D/FfjQQACLRgSLPSTRQACFwHQDUP/XiwaFwHQDUP/XgyYAg2YEAINmCABfXsNT Vot0JAwz21dT6GYvAACD4AFqB4mGHAkAAGomjYa4CAAAagpQ6MQeAACDxBQ4Heg2SQB0E42G tAcAAGjoNkkAUOjJXgAAWVlW6I8BAAAPvoYsAQAAjb4sAQAAUOhgYQAAOJ6sAQAAWVmIB3UK x4YcCQAAAQAAADiesAYAAI2+sAYAAHUfagH/tiAJAABo3AFBAOimGwAAWVlQU1fofykAAIPE EF9eW8NVi+yD7BxTVo1F5FdQ/xXY0EAAM9u+5gZBAFNW6KQbAABZO8NZiUX0D44AAQAAvxjS QAAzwIH/KNJAAA+dwEiLD4PgColN/IPABYlN+PfYUI1F/FDoMzIAAFlZZotN+GY5Tfx+CWaD wQxmg0X6Hg+3ReYPv1X8O9B/HQ+/yTvBfxYPt0XqD79N/jvIfwoPv036QUE7wX4JQ4PHBDtd 9HyTO130D42FAAAAU1bo5RoAAGoAi9joFC4AAIvwi0UIg+YBVmhmB0EAjbgsAQAA6MMaAABQ V+iOXQAAagDo7S0AAIPEIDPSagNZ9/GF0nQEhfZ0LmoA6NQtAABqBjPSWffxUmikA0EA6Ioa AABQV+hlXQAAaDjwQABX6FpdAACDxBxTV+hQXQAAWVlqAVjrAjPAX15bycNVi+yB7AgMAABT Vot1CI2F+Pf//1dQjYX48///M9tQjUZkUIld/Iid+PP//+hpIQAAjYasAQAAU4lF+GjcAUEA iBiNhiwBAACInVz0//+Infj7//+JRQiIGIiesAYAAOgsGgAAU4v46CwtAAAz0lP394mWIAkA AOgcLQAAg8QcqAN1D1boQv7//4XAWQ+FTQMAAFPoAC0AAFkz0moYWffxhdJ1LGi0DkEAiZ4c CQAA/3UI6HtcAACBxsgAAABWaMoOQQD/dfjosGAAAOkMAwAAU+jCLAAAWTPSahhZ9/GF0g+F pwAAAMdF/AEAAABT6KUsAABZM9JqA1n38YXSD4TxAQAAOV38D4XoAQAAv/IDQQBTV+h4GQAA U4lF+Oh3LAAAM9L3dfhSV+gzGQAAU4v46GMsAACDxBgz0moDWffxhdIPhZ0BAABT6EssAABZ M9JqCln38YXSD4UnAQAAV1PoNCwAAIPgAYPABFBoEANBAOjrGAAAg8QMUP91COj6XwAAV1bo ZgYAAOlPAgAAU+gFLAAAqB9ZdQpoOPBAAOlDAQAAU+jwKwAAqAFZD4U8////OB3sN0kAD4Qw ////agFqMo2F+Pv//2oIv+w3SQBQV+hcHgAAg8QUhcAPhA3///9Tx4YcCQAAAQAAAOioKwAA WTPSagqInfj3//9Z9/GNhfj7//9QO9N1L1PoiSsAAIPgAYPABFBoEANBAOhAGAAAg8QMUP91 COhPXwAAjYX4+///UOlK/////3UI6PJaAABT6FIrAACDxAyoPw+FjgEAAGoBaCADAACNhfj3 //9qCFBXiJ349///6MQdAACNhfj3//9Q/3X46LZaAACDxBzpWwEAAFPoDisAAIPgA1BoEANB AOjIFwAAi3UIUFbokFoAAFPo8CoAAIPEGKgBdBuNhfjz//9QVuiGWgAAaDzwQABW6HtaAACD xBAPvgdQ6N1dAABXVogH6GZaAACDxAzp+wAAAFf/dQjoRVoAAFlZ6esAAABT6J4qAABZM9Jq BVn38Tld/Iv6dAIz/4sEvfDRQABTiUX8iwS9BNJAAIlF+OhzKgAAM9JZ93X4AVX8g/8EfWNT 6F8qAACoAVl1I4P/A3QeU+hPKgAAg+ABg8AIUGioBUEA6AYXAACDxAyL2OsFu6AxQQD/dfxo pANBAOjtFgAAWVlQU1doVANBAOjeFgAAWVlQjYX4+///UOjqXQAAg8QQ6y3/dfxopANBAOi9 FgAAWVlQV2hUA0EA6K8WAABZWVCNhfj7//9Q6LtdAACDxAyNhfj7//9Q/3UI6GBZAAD/dfxX VugIAAAAg8QUX15bycNVi+yB7GACAACDfQwEU1ZXD4SZAQAAM9tT6JYpAACoAVm+qAVBAHUg g30MA3QaU+iAKQAAg+ABg8AIUFboOxYAAIPEDIv46wW/oDFBAP91EGikA0EA6CIWAABZWVBX /3UMaFQDQQDoERYAAFlZUI2FaP7//1DoHV0AAFPoNCkAAIPgAYPAEFBW6O8VAACDxBxQU+gd KQAAagMz0ln38YPCElJW6NQVAACDxAxQag9W6MgVAABZWVCNhTD///9Q6NRcAABT6OsoAACD xBSoAXUmU+jeKAAAg+ABUGgQA0EA6JgVAABQi0UIBawBAABQ6FtYAACDxBSLRQhqDlaNuKwB AACJfRDochUAAFBX6E1YAACNhWj+//9QV+hAWAAAg8QYOV0Mv3YHQQB1ZFf/dRDoKlgAAGgz CUEA/3UQ6B1YAACLdQhTaHQNQQCJnhwJAACJniAJAADoURUAAFOJRfyBxrAGAADoSigAADPS 93X8Umh0DUEA6AIVAABQVujNVwAAaNwBQQBW6NJXAACDxDRX/3UQ6MZXAACNhTD///9Q/3UQ 6LdXAACDxBDpVgIAADPbU+j9JwAAg+ABvlgFQQCJRfyLRQhTVomYHAkAAImYIAkAAOjUFAAA U4v46NQnAAAz0vf3UlbokRQAAIlF+FCNhWj+//9Q6FNXAABT6LMnAACDxCS+qAVBAKgBdAnH RQygMUEA6xlT6JgnAACD4AGDwAhQVuhTFAAAg8QMiUUM/3UMagRW6EIUAABZWVCNhTD///9Q 6E5bAACNhTD///9QjYVo/v//UOgCVwAAi30QV2ikA0EA6BIUAACDxByJRRBQagRoVANBAOj/ EwAAWVlQjYUw////UOgLWwAAjYUw////UI2FaP7//1Dov1YAAP91EI2FMP///1DooFYAACs9 ANJAAIPHBldW6L4TAACDxCRQ/3UMagVW6K8TAABZWVCNhaD9//9Q6LtaAACNhaD9//9QjYUw ////UOhvVgAAi0UIg8QYOV38dC6NjWj+//8FrAEAAFFQ6EJWAACLRQi/dgdBAAWsAQAAV1Do PlYAAI2FMP///+ssjY0w////BawBAABRUOgUVgAAi0UIv3YHQQAFrAEAAFdQ6BBWAACNhWj+ //9Qi0UIBawBAABQ6PtVAACLRQiDxBgFrAEAAFdQ6OlVAACLRQhXjbisAQAAV+jZVQAAag1W 6O8SAABQV+jKVQAAagpW6OASAABQV+i7VQAAagtW6NESAABQV+isVQAAg8RA/3X4V+igVQAA agxW6LYSAABQV+iRVQAAi0UIU4mYHAkAAI2wsAYAAOjSJQAAg+ABUGh0DUEA6IwSAABQVuhX VQAAaNwBQQBW6FxVAACDxDRfXlvJw4PsZFOLXCRsVVaNq8gAAABXjbOsAQAAVWioBUEAVuhq WQAAv3YHQQBXVuglVQAAV1boHlUAAGiQBUEAVugTVQAAjUNkUFboCVUAAFdW6AJVAABqAWiQ BUEA6BQSAABQVujvVAAAg8REVVbo5VQAAFdW6N5UAABqAmiQBUEA6PARAABQVujLVAAA/7Qk nAAAAFbovlQAAFdW6LdUAABqAOgGJQAAg+ABv6gFQQBAUFfovhEAAFBW6JlUAACDxERqA1fo rBEAAFBW6IdUAACNRCQgUI1DZGoAUOjPGAAAagFofQdBAOiJEQAAUFXoVFQAAI1EJDxQVehZ VAAAg8Q0g6McCQAAAF9eXVuDxGTDVYvsgexoCAAAU1ZXi30MaJAFQQBX6B1UAACLXQiNhZj3 //9QjYWY+///jbPIAAAAUFboaBgAAI2FmPv//1ZQjYWY9///aCsNQQBQ6DBYAACNhZj3//9Q V+jqUwAAvn0HQQBWV+jeUwAAagFokAVBAOjwEAAAUFfoy1MAAIPERI1DZFBX6L5TAABWV+i3 UwAAagJokAVBAOjJEAAAUFfopFMAAI2DLAEAAFBX6JdTAABWV+iQUwAAaJ0HQQBX6IVTAACN g7gIAABQV4lFDOh1UwAAg8RAVlfoa1MAAFZX6GRTAABqB2oUjUWYaghQ6CQTAABqAf91DFfo NQIAAIPELIO7HAkAAACLxnQejUWYUI2FmPf//2j7CEEAUOhgVwAAg8QMjYWY9///UI2FmPv/ /2jhB0EAUOhFVwAAjYWY+///UFfo/1IAAI2DrAEAAFBX6PJSAABoTwhBAFfo51IAAFZX6OBS AABWV+jZUgAAagDoKCMAAIPEOIPgAYO7HAkAAACJRQh1B8dFCAIAAABqAf91DFfomQEAAIPE DI1FmFCNg7AGAABQ/3UIaMEIQQDosQ8AAFlZUI2FmPv//2hnCEEAUOi4VgAAjYWY+///UFfo clIAAFZX6GtSAABWV+hkUgAAjUX8agFQjYOsBQAAUOi6HAAAg8Q4iUUIhcB0ElBX6EFSAAD/ dQjoxFYAAIPEDFZX6C9SAACBw7QHAABZWYA7AA+E6wAAAFPozhgAAD0AyAAAWYlF/HIbPQDQ BwAPg88AAABqAOhRIgAAqAFZD4S/AAAAjUX8agBQU+hOHAAAg8QMiUUIhcAPhKUAAABqAf91 DFfouAAAAGoB/3UMV+itAAAAjYWY+///UI2FmPf//1BqAGoAU+gFUwAAjYWY+///UI2FmPf/ /1Dol1EAAIPENI1FmFCNhZj3//9QagJowQhBAOibDgAAWVlQjYWY+///aGcIQQBQ6KJVAACN hZj7//9QV+hcUQAAVlfoVVEAAFZX6E5RAAD/dQhX6EVRAABWV+g+UQAA/3UI6MFVAACDxEBq AP91DFfoEwAAAGhA8EAAV+gdUQAAg8QUX15bycNVi+xoQPBAAP91COgFUQAA/3UM/3UI6PpQ AACDxBCDfRAAdA9ofQdBAP91COjkUAAAWVldw1WL7IPsMFNWV/8V1NBAAIt9CDPbUFNo/w8f AIld8MdF9DIAAACJXfiIXdiIXdmIXdqIXduIXdzGRd0FiV3oiV3siV38iV3kiR//FSDRQACN TfCJReBRaghQ/xUg0EAAhcB1Dv8V4NBAAIlF/OkSAQAA/3X0U/8VlNBAADvDiUX4dOGNTfRR /3X0UGoC/3Xw/xUw0EAAizXg0EAAhcB1OP/Wg/h6dWv/dfj/FdzQQAD/dfRT/xWU0EAAO8OJ Rfh0UY1N9FH/dfRQagL/dfD/FTDQQACFwHQ6jUXoUFNTU1NTU1NqBI1F2GoBUP8VKNBAAIXA dB2NRexQU1NTU1NTU2oGjUXYagFQ/xUo0EAAhcB1B//W6VH///+LdfiJXQg5HnZSg8YE/3Xo iwaLTgSJRdBQiU3U/xUs0EAAhcB1Iv917P910P8VLNBAAIXAdR3/RQiLRfiLTQiDxgg7CHLH 6xTHReQBAAAAiR/rCccHAQAAAIld5DkfdQs5XeR1BscHAQAAADld7Is1PNBAAHQF/3Xs/9Y5 Xeh0Bf916P/WOV34dAn/dfj/FdzQQAA5XfCLNSTRQAB0Bf918P/WOV3gdAX/deD/1otF/F9e W8nDVYvsuOAtAADoBlcAAFMz2zldEFZXx0X8IAAAAIideP///3QT/3UQjYV4////UOjQTgAA WVnrFWoHagqNhXj///9qBVDomQ4AAIPEEDldGHQF/3UY6wVo5DVJAI2FePr//1DonE4AAIt1 CFlZjYV0/v//VlDoik4AAP91DI2FdP7//1Doi04AAIPEEDldFHQT/3UUjYVw/f//UOhkTgAA WVnrImoBaNwBQQDoQ1YAAGoCmVn3+Y2FcP3//1JQ6FIZAACDxBA5HfA4SQB0HmoBU+gdVgAA agKZWff5jYVw/f//UlDoLBkAAIPEEI2FdP7//1Do/E4AAIC8BXP+//9cjYQFc/7//1l1AogY gL1w/f//XHQTjYV0/v//aETwQABQ6O5NAABZWY2FcP3//1CNhXT+//9Q6NlNAABZjYV0/v// WVNQjYV4+v//UP8VfNBAAIXAD4RlAQAA6JRVAABqBZlZ9/mF0nQi6IVVAACZuQAoAAD3+Y2F dP7//4HCgFABAFJQ6JkWAABZWWh6IgAAjYUg0v//aMDwQABQ6BNSAACNhSDS//+InTTi//9Q jYV0/v//UOj/LAAAjYV0/v//UOgQKwAAg8QYOR3wOEkAD4XqAAAAjUX8UI1F3FD/FWTQQACN RdxQjUYCUOjkngAAWYXAWQ+ExQAAAGoCU1aLNQDQQAD/1ov4O/t1CTldHA+EqgAAAFNTU1ON hXT+//9TUFNqA2gQAQAAjYV4////U1CNhXj///9QV/8VSNBAAFeLPUDQQAD/12oBU/91CP/W i/CNhXj///9qEFBW/xU40EAAU1NQiUUQ/xUk0EAA/3UQiUUY/9dW/9c5XRgPhWUBAAC6gQAA ADPAi8qNvab2//9miZ2k9v//ZomdnPT///OrZquLyjPAjb2e9P//OR0EOUkA86uJXRCJXRhm q3UHM8DpJAEAAItFDIA4XHUHx0UYAQAAAL8EAQAAjYWk9v//V4s1eNBAAFBq//91CGoBU//W i00MjYWc9P//V1CLRRhq/wPBUGoBU//WjUUQUI2FnPT//2oCUI2FpPb//1D/FQQ5SQCFwA+F uwAAAFNTjYV8+///V1CLRRBq/4idfPv///9wGFNT/xWg0EAAjUUUUGgCAACA/3UI/xUc0EAA hcB1d42FrPj//2oDUOgnEQAAjYV8+///aETwQABQ6JNLAACNhXD9//9QjYV8+///UOiASwAA jYV0+f//U1BTjYV8+///U1CInXT5///ov0wAAI2FfPv//1CNhXT5//9QjYWs+P//UP91FOgy GgAAg8Q8/3UU/xVc0EAAoQw5SQA7w3QF/3UQ/9BqAVhfXlvJw1WL7ItFFFNWi/FXM9v/dQiJ RhiNRhyJHlCJXgzo9EoAAIt9EGaLRQxXZomGnAEAAGbHhp4BAAAZAOgWUwAAg8QMO8OJRgR1 DMeGpAEAAAIAAIDrY1fo+lIAADvDWYlGEHTmV1P/dgSJfgiJfhToQ0oAAFdT/3YQ6DlKAACD xBiNjqABAACJnqQBAACJnqgBAABqAWoB/3UMiZ6sAQAAiJ4cAQAA6D4FAACFwHUOx4akAQAA BQAAgDPA6xA5Xgx0CDkedARqAesCagJYX15bXcIQAFaL8VeLRgSFwHQHUOjNTgAAWYtGEIXA dAdQ6L9OAABZjb6gAQAAagBqBmhI8EAAi8/ojAUAAIvP6MEFAACFwHT1g/gBdRBo3QAAAIvO 6NUCAACL8OsDagFei8/okAUAAIvGX17DVovxV2aLhpwBAACNvqABAABQjUYcUIvP6N0EAACF wHUNuAEAAICJhqQBAADrK4vP6GQFAACFwHT1g/gBdQ5o3AAAAIvO6HgCAADrDWoBx4akAQAA AwAAgFhfXsNVi+yB7AQBAABTVovxV42GHAEAAFCNhfz+//9oYPBAAFDopU0AAIPEDI2F/P7/ /42+oAEAAGoAUOg1SgAAWVCNhfz+//9Qi8/otAQAAIvP6OkEAACFwHT1g/gBD4WdAAAAu/oA AACLzlPo+AEAAIXAD4WVAAAAi87olQAAAIXAD4WGAAAAIUX8OQaLfgR2IVeLzug1AQAAhcB1 cFfo0UkAAP9F/I18BwGLRfxZOwZy32oAjb6gAQAAagdoWPBAAIvP6DsEAABoYgEAAIvO6JQB AACFwHU1UIvP/3UM/3UI6B0EAABqAGoFaFDwQACLz+gNBAAAU4vO6GoBAADrDWoBx4akAQAA AwAAgFhfXlvJwggAU1aL8YtGFIPAZFDon1AAAIvYWYXbdQhqAljpmAAAAFVXaHDwQABT6ERI AACLfhAz7TluDFlZdiVXU+hBSAAAaDjwQABT6DZIAABX6BBJAACDxBRFO24MjXwHAXLbaGzw QABT6BhIAABZjb6gAQAAWWoAU+joSAAAWVBTi8/obQMAAIvP6KIDAACL6IXtdPNT6HZMAABZ agFYXzvoXXUOaPoAAACLzuipAAAA6wrHhqQBAAADAACAXlvDU1b/dCQMi9nomUgAAIPAZFDo 308AAIvwWYX2WXUFagJY63JVV2iA8EAAVuiGRwAA/3QkHFbojEcAAGhs8EAAVuiBRwAAg8QY jbugAQAAagBW6FBIAABZUFaLz+jVAgAAi8/oCgMAAIvohe1081bo3ksAAFlqAVhfO+hddQ5o +gAAAIvL6BEAAADrCseDpAEAAAMAAIBeW8IEAFWL7IHsBAQAAFaL8VdqAI2+oAEAAI2F/Pv/ /2gABAAAUIvP6IoCAACLz+ioAgAAhcB09YP4AXVAjUX8UI2F/Pv//2iM8EAAUOgcTwAAi0UI i038g8QMO8F0GseGpAEAAAQAAICJjqgBAACJhqwBAABqAusQM8DrDceGpAEAAAMAAIBqAVhf XsnCBAD/dCQEgcEcAQAAUeiBRgAAWVnCBABVi+xRU1ZXi/H/dQiLfhDoWEcAAINl/ACDfgwA WYvYdhZX6EVHAAD/RfyNfAcBi0X8WTtGDHLqK14Qi0YUA9872HZOi04YA8FQiUYU6GpOAACL 2FmF23UMx4akAQAAAgAAgOs+/3YUagBT6K1FAACLRhCLzyvIUVBT6I5OAACLRhBQK/jojkoA AIPEHIleEAP7/3UIV+jiRQAA/0YMi0YMWVlfXlvJwgQAVYvsUVNWV4vx/3UIi34E6K9GAACD ZfwAgz4AWYvYdhVX6J1GAAD/RfyNfAcBi0X8WTsGcusrXgSLRggD3zvYdk6LThgDwVCJRgjo w00AAIvYWYXbdQzHhqQBAAACAACA6zz/dghqAFPoBkUAAItGBIvPK8hRUFPo500AAItGBFAr +OjnSQAAg8QciV4EA/v/dQhX6DtFAAD/BosGWVlfXlvJwgQAVYvsgeyQAQAAU1ZqAY2FcP7/ /1uL8VBqAv8V4NFAAA+/RQxISHUDagJbD7/DagZQagL/FeTRQAAzyYP4/4kGXg+VwYvBW8nC DABVi+yD7BBWi/H/dQz/FdTRQABmiUXyjUUMUIvO/3UIZsdF8AIA6HkAAACLRQxqEIhF9IpF DohF9opFD4hl9YhF941F8FD/Nv8V2NFAAIXAXnQK/xXc0UAAM8DrA2oBWMnCCAD/dCQM/3Qk DP90JAz/Mf8V0NFAAMIMAP90JAz/dCQM/3QkDP8x/xXM0UAAwgwA/zH/FcTRQAD/JcjRQABq AVjDVYvsUVFTVleLfQhqATP2W4lN+FeJdfzoFUUAAIXAWX4sigQ+PC51Bf9F/OsKPDB8BDw5 fgIz21dG6PNEAAA78Fl83oXbdBiDffwDdAQzwOs6/3UMi034V+g1AAAA6ylX/xXA0UAAi/D/ FdzRQACF9nQWM8CLTgyLVQyLCYoMAYgMEECD+AR87GoBWF9eW8nCCABVi+xRU4tdCFYz9leJ dfyNRQiNPB5QaIzwQABX6NtLAACLVQyLRfyKTQiDxAyD+AOIDBB0F0aAPy50CIoEHkY8LnX4 /0X8g338BHzDX15bycIIAFWL7FFTVlf/dQzoPUQAAIt1CItdEFmJRfxW6C1EAACL+FmF/3Qt hdt0CYvGK0UIO8N9IIN9FAB0D/91DFbo6pQAAFmFwFl0Bo10PgHry4PI/+syi038i8YrRQiN RAgCO8N+CIXbdAQzwOsa/3UMVujoQgAAVujSQwAAg8QMgGQwAQBqAVhfXlvJw1aLdCQIVzP/ OXwkEH4dVuiuQwAAhcBZdBJW6KNDAABHWTt8JBCNdAYBfOOLxl9ew1aLdCQIVzP/VuiEQwAA hcBZdBqDfCQQAHQMi84rTCQMO0wkEH0HjXQGAUfr24vHX17DVYvsUVOLXQhWi3UMV2oAU4l1 /Oi2////i/hZhf9ZfwczwOmVAAAAhfZ9D2oA6KQSAAAz0ln394lV/I1HAlBT6Fr///+L8Cvz 0eZW6F9KAABWM/ZWUIlFDOizQQAAg8QYhf9+JDt1/HQaagH/dRBWU+gp////WVlQ/3UM6JT+ //+DxBBGO/d83DP2Tzv+iTN+H2oB/3UQVv91DOj//v//WVlQU+hs/v//g8QQRjv3fOH/dQzo U0YAAFlqAVhfXlvJw1ZXM/+L92oA994b9oHm+AAAAIPGCOj7EQAAM9JZ9/aLRCQMA8eE0ogQ dQPGAAFHg/8EfNBfXsNVi+yD7AyLRRCDZfgAg30MAFOKCIpAAVZXiE3+iEX/fjOLRQiLTfgD wYlF9IoAiEUTYIpFE4pN/tLAMkX/iEUTYYtN9IpFE/9F+IgBi0X4O0UMfM1qAVhfXlvJw1WL 7IPsDItFEINl+ACDfQwAU4oIikABVleITf6IRf9+M4tFCItN+APBiUX0igCIRRNgikUTik3+ MkX/0siIRRNhi030ikUT/0X4iAGLRfg7RQx8zWoBWF9eW8nDU1ZXM/9X6BsRAABZM9JqGotc JBRZ9/GL8oPGYYP7BHR4g/sBdRVX6PoQAABZM9JqCln38YvCg8Aw62D2wwJ0E1fo4BAAAFkz 0moaWffxi/KDxkFX6M0QAACoAVl0GPbDBHQTV+i9EAAAWTPSahpZ9/GL8oPGYVfoqhAAAKgB WXQY9sMBdBNX6JoQAABZM9JqCln38Yvyg8Ywi8ZfXlvDU4tcJAxWV4t8JBiL8zv7fhJqAOhv EAAAK/sz0vf3WYvyA/OLXCQQM/+F9n4S/3QkHOgr////iAQfRzv+WXzuagLoG////1mIA4Ak HwBqAVhfXlvDVle/kPBAADP2V+iuQAAAhcBZfhiKRCQMOoaQ8EAAdBFXRuiWQAAAO/BZfOgz wF9ew2oBWOv4U4pcJAhWV4TbfD8PvvNW6EhLAACFwFl1NVboa0sAAIXAWXUqv5jwQAAz9lfo VkAAAIXAWX4UOp6Y8EAAdBBXRuhCQAAAO/BZfOwzwOsDagFYX15bw1aLdCQIigZQ/xVo0EAA hcB0C4B+AYB2BWoBWF7DM8Bew4tEJASKADyhdAc8o3QDM8DDagFYw1WL7IHs/AcAAItFHFNW V4t9DDP2iXX8gCcAOXUQiTB/CYtFCEDp3AEAAItdCIoDUOhA////hcBZdVCJXQyDfSAAdCv/ dQzof////4XAWXQN/3UM6JP///+FwFl0Lf91DOiG////hcBZdARG/0UMi0UQRv9FDEg78H0Q i0UMigBQ6PD+//+FwFl0s4tFEEg78IlFDA+NagEAAIoEHlDo0/7//4XAWQ+EvgAAAIoEHlDo i/7//4XAWXULRjt1DHzs6T8BAACKBB5Q6Kj+//+FwFl0G4tN/IoEHv9F/EY7dQyIBDl9CYtF GEg5Rfx814tFGEg5Rfx8HIN9/AB0FotF/IoEOFDoN/7//4XAWXUF/038deqLRfyFwHwEgCQ4 ADPbOB90FYoEO1DoE/7//4XAWXQHQ4A8OwB1640EO1CNhQT4//9Q6MQ9AACNhQT4//9QV+i3 PQAAi0X8g8QQK8M7RRQPjYQAAACLXQiDfSAAD4SKAAAAi0UIgCcAA8Yz21DoR/7//4XAWXRZ i0UQg8D+iUUgi0UIA8aJRRD/dRDoSv7//4XAWXUZi0UQigiIDDuKSAFDRkCIDDtDRkCJRRDr BkZGg0UQAjt1IH0Xi0UYg8D+O9h9Df91EOju/f//hcBZdbiAJDsAO10UfBCLRRzHAAEAAACL RQgDxusMi10Ii0UcgyAAjQQeX15bycNVi+y4HBAAAOgERQAAU1ZXjU3k6OTc//+LfQyNRfhq AVD/dQgz241N5Igf6M/c//+L8DvzD4QrAQAAi1X4g/oKD4IXAQAAiJ3k7///iV38/3UYjU38 Uf91FP91EFJXUOiR/f//i034g8Qci9Er0APWg/oFD47iAAAAOV38dNGJXQgz//91GI1V/CvI UgPO/3UU/3UQUY2N5O///1FQ6FP9//+DxBw5Xfx0A/9FCItN+IvRK9AD1oP6BXYJR4H/ECcA AHy/OV0IdBFT6JgMAAAz0ln394tN+IlVCIv+iV30/3UYjUX8K89QA87/dRSNheTv////dRBR UFfo9/z//4PEHDld/Iv4dBk5XQh0Lv9NCI2F5O///1D/dQzo4jsAAFlZi034i8ErxwPGg/gF dgz/RfSBffQQJwAAfKSNTeTodtz///91DOimPAAAWTPJO0UQD53Bi8FfXlvJw4gfjU3k6FTc //8zwOvtVYvsi1UMUzPbVoXSdAIgGotFEIXAdAOAIACLdQiAPkB0HFeL+ovGK/6KCITJdA6F 0nQDiAwHQ0CAOEB17F+F0nQEgCQTAIA8MwCNBDNeW3UEM8Bdw4N9EAB0C1D/dRDoNDsAAFlZ agFYXcNVi+xRU4pdCFZXvqTwQACNffxmpYD7IKR+NID7fn0vD77zVujKRgAAhcBZdShW6O1G AACFwFl1HYD7QHQYgPsudBM6XAX8dA1Ag/gCfPQzwF9eW8nDagFY6/b/dCQE6J3///9Zw1WL 7LgAIAAA6MtCAAD/dQiNhQDg//9Q6Kw6AAD/dQyNhQDw//9Q6J06AACNhQDg//9Q6O2MAACN hQDw//9Q6OGMAACNhQDw//9QjYUA4P//UOjCRgAAg8QgycNWvlICQQBW/3QkDOhdOgAA/3Qk FFbogff//1D/dCQc6Fk6AACDxBhew1OLXCQIVldT6Cc7AACL+FmD/wR8JIP/DH8fM/aF/34U D74EHlDoDUYAAIXAWXQKRjv3fOxqAVjrAjPAX15bw1WL7IHsBAEAAFNWV42F/P7//zP/UFdX V/91COhQOwAAvvwBQQBXVug39///i9iDxBw7334gV1bo9/b//1CNhfz+//9Q6IyLAACDxBCF wHQnRzv7fOCNhfz+//9owg1BAFDob4sAAPfYG8BZg+BjWYPAnF9eW8nDi8fr91WL7FYz9ldW aiBqAlZqA2gAAADA/3UI/xX80EAAi/iJdQiD//90Izl1DHQejUUIVlD/dRD/dQxX/xVs0EAA V/8VJNFAAGoBWOsCM8BfXl3DVYvsU1dqAGonagNqAGoDaAAAAID/dQj/FfzQQACDZQgAi/iD y/87+3QdjUUIUFf/FezQQACDfQgAi9h0A4PL/1f/FSTRQACLw19bXcNVi+yD7BSNTezo2tj/ /41F/GoBUI1N7P91COjM2P//hcB0DY1N7Oh62f//agFYycMzwMnDVYvsgewYAQAAVmoEagWN RexqAlDof/j//4PEEI2F6P7//1BoBAEAAP8VmNBAAIt1CI1F7FZqAFCNhej+//9Q/xV00EAA VugjAAAAVuhYOQAAWVlIeAaAPDAudfcDxmjcAUEAUOhQOAAAWVleycNqIP90JAj/FYDQQAD/ dCQE/xWc0EAAw1WL7IHsSAMAAFZX/3UIjYX4/f//M/ZQ6Bg4AACNhfj9//9Q6Pw4AACDxAyF wHQXgLwF9/3//1yNhAX3/f//dQaAIABqAV6Nhfj9//9osPBAAFDo7TcAAFmNhbj8//9ZUI2F +P3//1D/FYzQQACL+IP//w+E1AAAAP91CI2F/P7//1DorTcAAFmF9ll1E42F/P7//2hE8EAA UOimNwAAWVmNheT8//9QjYX8/v//UOiRNwAA9oW4/P//EFlZdFuNheT8//9orPBAAFDodTYA AFmFwFl0Wo2F5Pz//2io8EAAUOheNgAAWYXAWXRD/3UQjYX8/v//agFQ/1UMg8QMhcB0Lf91 EI2F/P7///91DFDo7P7//4PEDOsW/3UQjYX8/v//agBQ/1UMg8QMhcB0Fo2FuPz//1BX/xWI 0EAAhcAPhTP///9X/xWE0EAAXzPAXsnDVYvsUYF9DABQAQBTVld8Kmog/3UI/xWA0EAAM9tT aiBqA1NqA2gAAADA/3UI/xX80EAAi/iD//91BzPA6YQAAACNRfxQV/8V7NBAAIvwO3UMfhVT U/91DFf/FeTQQABX/xWQ0EAA61NqAlNTV/8V5NBAAItFDCvGvgAACACJRQiLzpn3+TvDix1s 0EAAfheJRQyNRfxqAFBWaNAxQQBX/9P/TQx17I1F/GoAUItFCJn3/lJo0DFBAFf/01f/FSTR QABqAVhfXlvJw1ZqAGonagNqAGoDaAAAAID/dCQg/xX80EAAi/CD/v91BDPAXsOLRCQMV41I EFGNSAhRUFb/FejQQABWi/j/FSTRQACLx19ew1ZqAGonagNqAGoDaAAAAMD/dCQg/xX80EAA i/CD/v91BDPAXsOLRCQMV41IEFGNSAhRUFb/FTDRQABWi/j/FSTRQACLx19ew1WL7IPsFFON TezodNX//41F/GoBUI1N7P91COhm1f//i9iF23Rwg30QAHQmgX38AJABAHYdagDosgUAAFkz 0moKWffxg8JUweIKO1X8cwOJVfyLRfxWA8BQ6Gk9AACL8FmF9nQmi0X8A8BQagBW6LU0AABq SP91/FZT6LnN//+LTQyDxByFyXQCiQGNTezordX//4vGXlvJw1WL7IHsBAEAAFNWV4t9CDPb ahRTV4id/P7//+hvNAAAg8QMOB3sN0kAdD5T6CQFAABZM9JqA1n38YXSdCxqAWoKjYX8/v// UVBo7DdJAOib9///g8QUhcB0D42F/P7//1BX6Ig0AABZWTgfD4WLAAAAOB3oNkkAdDZT6NYE AABZM9JqA1n38YXSdCSNhfz+//9TUFNTaOg2SQDouzUAAI2F/P7//1BX6EM0AACDxBw4H3VJ U+icBAAAqA9ZdSu+dA1BAFNW6IPx//9TiUUI6IIEAAAz0vd1CFJW6D7x//9QV+gJNAAAg8Qc OB91D2oEagZqAlfo1fP//4PEEDldDHQrvvwBQQBTVuhA8f//U4lFCOg/BAAAM9L3dQhSVuj7 8P//UFfo1jMAAIPEHDldEHQN/3UQV+jFMwAAWVnrMDldFHQrvtwBQQBTVuj+8P//U4lFCOj9 AwAAM9L3dQhSVui58P//UFfolDMAAIPEHF9eW8nDVYvsg+wUU4tFGFZX/3UUM9uDz/+JXfxT iX34/3UQiV3wiV30iRjo8TIAAIt1CIoGUOgZ+P//g8QQhcAPhIwAAACKBlDoBvj//4XAWXRc i0UMi95IiUUIi0UQK8aJRezrA4tF7IoLiAwYigM8QHUJi03w/0X0iU34PC51B4X/fQOLffD/ RfxDi0X8/0XwO0UIfRaLRRRIOUXwfQ2KA1DorPf//4XAWXW5M9uLRfCLTRArffiAJAgAg/8D fhFqAVg5Rfh+CTlF9A+EoAAAAINN+P+DTfD/iV38ZoseM/9TIX306MP3//+FwFkPhIoAAABT 6LT3//+FwFl0VItFDEghfQyJRQiLRRCA+0CIHAd1Bv9F9Il9+ID7LnUJg33wAH0DiX3wg0UM BINF/AKLRQxHO0UIfRqLRRRIO/h9EotF/GaLHDBT6GD3//+FwFl1totFEIAkBwCLRfArRfiD +AJ+EmoBWDlF+H4KOUX0dQWLTRiJAYtF/APG6wONRgFfXlvJw1WL7IHsGAQAAFMz21aNTeiJ Xfzo3tH//41F+GoBUI1N6P91COjQ0f//i/A783UEM8DrY1eL/otF+IvPK86NUP87yn1HjU38 K8dRjY3o+///aAAEAACNRDD/UVBX6B7+//+DxBSDffwAi/h0yv91FI2F6Pv///91EFD/dQzo Hu7//4PEEIXAfq5D66uNTejoINL//4vDX15bycNVi+xRUYtFGINN+P9QagD/dRSJRfzo5zAA AIPEDI1FGFD/dQz/dQj/FUzQQACFwHQFagFYycONRfxQjUX4/3UUUGoA/3UQ/3UY/xUU0EAA /3UY/xVc0EAAM8DJw1WL7I1FDFD/dQz/dQj/FRjQQACFwHQFagFYXcP/dRTo0TEAAFlQ/3UU agFqAP91EP91DP8VENBAAP91DP8VXNBAADPAXcNVi+yB7AwBAACNRfxWUDP2/3UM/3UI/xVM 0EAAhcB0BDPA61eNhfT+//9oBAEAAFBW/3X8/xVQ0EAAhcB1LzlFEHQjIUX4/3UUjUX4UI2F 9P7//1D/dQz/dQj/VRCDxBSDffgAdQNG67uL8OsDagFe/3X8/xVc0EAAi8ZeycNVi+yB7BQI AABTjUX8VlD/dQy+AAQAADPbiXXw/3UIiXX4/xVM0EAAhcB0BDPA63ONRfiJdfBQjYXs9/// UI1F7FCNRfBqAFCNhez7//+JdfhQU/91/P8VRNBAAIXAdTWDfewBdSg5RRB0IyFF9P91FI1F 9FCNhez7//9Q/3UM/3UI/1UQg8QUg330AHUDQ+ufi/DrA2oBXv91/P8VXNBAAIvGXlvJw4N8 JAQAdQmDPcwxQQAAdRf/FTTRQABQ6GM3AABZ6Gc3AACjzDFBAOldNwAAVYvsg+xUVjP2akSN RaxWUOj5LgAAg8QMjUXwx0WsRAAAAFCNRaxQVlZWVlZW/3UM/3UI/xWk0EAA99gbwF4jRfDJ w1WL7IPsHFNWjU3k6BbP//+DZfgAvsDwQABW6PwvAABZiUX0jUX8agFQjU3k/3UI6PXO//+L 2IXbdFOLTfxXgfkAoAAAcju4ABAAAIHBGPz//zvIi/h2Kv919I0EH1BW6Jc7AACDxAyFwHQP i0X8RwUY/P//O/hy3+sHx0X4AQAAAI1N5Ohaz///i0X4X15bycNVi+yB7AAEAABojQdBAP91 EOi88///WYXAWXRzjYUA/P//aAAEAABQgKUA/P//AP91EP91DP91COj8/P//jYUA/P//UOgm ////g8QYhcB0P4tNGGoBWP91DIkBi00UaOA0SQCJAegwLgAAjYUA/P//UGjkNUkA6B8uAAD/ dRBo3DNJAOgSLgAAg8QYM8DJw2oBWMnDVYvsgewACAAA/3UMjYUA/P//UOjuLQAAjYUA/P// aETwQABQ6O0tAAD/dRCNhQD8//9Q6N4tAACNhQD8//9ojQdBAFDo9fL//4PEIIXAdHmNhQD4 //+ApQD4//8AaAAEAABQjYUA/P//aJMHQQBQ/3UI6C78//+NhQD4//9Q6Fj+//+DxBiFwHQ/ i00YagFY/3UMiQGLTRRo4DRJAIkB6GItAACNhQD4//9QaOQ1SQDoUS0AAP91EGjcM0kA6EQt AACDxBgzwMnDagFYycNVi+yB7BwFAACDZfwAgz3wOEkAAHUlagRoUgJBAOhE6v//jU38UWhK SUAAUGgCAACA6EP8//+DxBjrPI2F6Pv//2oCUOiC8v//jYXo+///UGjgNEkA6N4sAACNRfxQ jYXo+///aLZIQABQaAIAAIDog/z//4PEIItF/IXAo/Q4SQAPhdEAAABWjYXk+v//aAQBAABQ /xWo0EAAM/aAZegAjUXoaI0HQQBQ6IosAABZjUXoWWoEagRqAlDoaS0AAFmNRAXoUOhN7P// jUXpUOjBfgAAjYXk+v//UI2F6Pv//1DoUiwAAI2F6Pv//2hE8EAAUOhRLAAAjUXoUI2F6Pv/ /1DoQSwAAI2F6Pv//2jcAUEAUOgwLAAAjYXo+///UOgn8///g8Q4hcB0CkaD/goPjGf///+N RehQaNwzSQDoBSwAAI2F6Pv//1Bo5DVJAOjkKwAAg8QQXmoBWMnDi0QkBGaLTCQIZgFIAmaL SAJmg/kBfQ5mg0ACHmaLSAJm/wjr7GaDeAIffhJmg0AC4maLSAJm/wBmg/kff+5miwhmg/kB fQaDwQxmiQhmiwhmg/kMfgaDwfRmiQjDi0QkDFaLdCQIV4t8JBCAJwCAIACAPlx1WIB+AVx1 UlNouPBAAFfoUysAAFmNRgJZighqAoD5XFp0F4vfK96EyXQPighCiAwDikgBQID5XHXtgCQ6 AAPWW4A6AHUEagLrElL/dCQY6BMrAABZM8BZ6wNqAVhfXsNVi+yB7BAEAABWjYX0/P//aOQ1 SQBQ6OwqAABZjYX8/v//WTP2aAQBAABQVv8VFNFAAFaNhfD7//9WUI2F9Pz//1ZQ6CosAABW jYX4/f//VlCNhfz+//9WUOgULAAAjYX4/f//UI2F8Pv//1DoZnwAAIPEMPfYG8BeQMnDVot0 JAyD/kRyMYtMJAiAOU11KIB5AVp1Ig+3QTwDwYPG/IvQK9E71ncRiwBeLVBFAAD32BvA99Aj wsMzwF7DVYvsU4tdEFaLdQhXU1borv///1mFwFl0UI0MMIt1DItRdI1BdDvWckAPt0kGi3Tw /IPABDP/hcmNRNAIdiuDw/yJXRCL0CtVCDtVEHMbi1AEixgD2jvedgQ71nYIg8AoRzv5ct87 +XICM8BfXltdw1WL7FNWi3UMV4t9CI1GEIlFDIvGK8eDwBA7RRgPh4AAAAAPt0YOD7dODINl CAADwYXAfmaLXRSLRQyLTRgrx4PACDvBd1SLRQyLQASpAAAAgHQcUVP/dRAl////fwPHUFfo mv///4PEFIXAdDXrFYvTA8crVRABEIsAO8NyJAPLO8FzHg+3Rg4Pt04Mg0UMCP9FCAPBOUUI fJ1qAVhfXltdwzPA6/dVi+yD7DxWjU3U6CLJ//+NTcToGsn//41F/GoBUDP2/3UMjU3EiXX4 iXX8iXX0iXXw6P7I//87xolFDHUHM8DpZAEAAItF/ItNEFONhAgAEAAAUP91COj58f//WY1F +FlWUP91CI1N1OjHyP//i9g73old7A+E/gAAAFf/dfhqA1PoZP7//4v4g8QMO/4PhNoAAAD/ dfxqA/91DOhK/v//i/CDxAyF9g+EwAAAAP91/P91DOjz/f///3X4iUUQU+jn/f//i00Qi1UM A8qDxBBmg3lcAg+FkwAAAIuJjAAAAAPYiU0QiYuMAAAAi0YIi08MiUcIiwaJB4tHCAPBiUXw i0YEiUXki0cEiUXoi0YIi3YMA/KLVeyNPBGLyCtNDAPOO038d0dQVlfouCwAAP91EP916P91 5FdX6Bz+//8Pt0sUiUX0i9MPt0MGA9GDxCCNBICNTML4i0TC/AMBZqn/D3QHwegMQMHgDIlD UI1N1Oh5yP//M/ZfjU3E6G7I//85dfRbdB+LRfA7RfxzA4tF/FD/dQjouvD///91COhMAQAA g8QMi0X0XsnDVYvsg+wUU1aNTezodsf//zP2jUX8VlD/dQiNTezoZ8f//4vYO951BzPA6b0A AABX/3X8U+jH/P//i/hZhf9ZD4SBAAAA/3X8agNT6O/8//+DxAyFwHRvahCNNB9aiZaMAAAA i0gEA8qJEGb3wf8PiVAIdAfB6QxBweEMiU5Qi0gMi3gIA/k7fQxzA4t9DGb3x/8PdAfB7wxH wecMjQQZi8gryztN/HMMUmoAUOh6JgAAg8QMi4bsAAAAhcB0A4lGKGoBXusDi30IjU3s6HLH //+F9nQLV/91COjL7///WVn/dQjoWwAAAFmLxl9eW8nDVYvsUYtFDDPJ0eiJTfx0KYtVCFaL 8A+3AgPIiU0Ii0UIwegQiUUIgeH//wAAA00IQkJOdeGJTfxeiU0Ii0UIwegQi1X8ZgPCiUUI i0UIA0UMycNVi+yD7BRWV41N7Ogzxv//g2X8ADP2jUX8VlCNTez/dQjoIMb//4v4hf90O/91 /FfoiPv//1mFwFl0IoN8OFgAjXQ4WHQSgyYA/3X8V+hb////WYkGWesDi0UIi/CNTezom8b/ /4vGX17Jw1WL7IHsAAgAAIM98DhJAAB1NYM9EDlJAAB0LI2FAPj//2jIAAAAUGr//3UIagFq AP8VeNBAAI2FAPj//1BqAP8VEDlJAMnDM8DJw1WL7IPsDFNWV4tFCIlF+ItFDIlF9It1+It9 9FFSUzPJSYvRM8Az26wywYrNiuqK1rYIZtHrZtHYcwlmNSCDZoHzuO3+znXrM8gz00911ffS 99Fbi8LBwBBmi8FaWYlF/ItF/F9eW8nDVYvsgexQAQAAU1ZXagNfjU3Q6A7F////dRDo+yUA AIvwWY1F6IPGIFD/FdjQQABmgWXq/v8z21PoU/X//1kz0moeWffxZilV8maDffI8cgZmx0Xy AQCKRfKLTfCD4D/B4QYLwYpN9NDpweAFg+EfC8GKTf5miUX8i0Xog8BEg+EfweAJM8GKTeqD 4Q9mJR/+weEFC8GKTe5miUX+Mk3+g+EfZjPBOV0UZolF/nQDagJfaiD/dQj/FYDQQABTaiBX U2oDaAAAAMD/dQj/FfzQQACL+IP//4l9+HQqagJTU1f/FeTQQACNReRqAVCNTdD/dQzoMcT/ /zvDiUUMdQ5X/xUk0UAAM8Dp8wAAAItF5MaFsv7//3RQZseFs/7//wCA/3UMZom1tf7//4mF t/7//4mFu/7//4idv/7//+hX/v///3UQiYXA/v//i0X8xoXI/v//FImFxP7//8aFyf7//zDo tCQAAP91EGaJhcr+//+NhdD+//+Jncz+//9Q6KgjAAAPt/6NR/5QjYWy/v//UOgD/v//izVs 0EAAg8QcOV0UZomFsP7//3QRjUXgU1BqFGisDUEA/3X4/9aNReBTUI2FsP7//1dQ/3X4/9aN ReBTUP915P91DP91+P/WjU3Q6P3D////dfj/FSTRQAA5XRR0Cf91COgBAQAAWWoBWF9eW8nD VYvsUYsNFDlJAINl/ABqAYXJWHQIjUX8agBQ/9HJw1WL7IHsYAYAAItFCFMz28dF8EAGAAA7 w4ld/HUG/xWs0EAAjU0IUWooUP8VINBAAIXAD4SeAAAAVo1F9FdQ/3UMU/8VCNBAAIXAdHyL RfSLNQzQQACJReSLRfiJReiNRfBQjYWg+f//UI1F4GoQUFOJXeD/dQiJXez/1os94NBAAP/X hcB1QYtF9IONrPn//wKJhaT5//+LRfiJhaj5//9TU42FoPn//2oQUFPHhaD5//8BAAAA/3UI /9b/14XAdQfHRfwBAAAA/3UI/xUk0UAAi0X8X15bycNVi+yD7BhWM/ZXVmogagNWagFoAAAA wP91CP8V/NBAAIv4O/4PhK4AAACNRehQ/xW00EAAVuha8v//ajwz0ln38VZmiVXy6Eny//9Z M9JZahhZ9/FmKVXwZjl18H8IZgFN8Gb/Te5W6Cjy//9ZM9JqHFn38WYpVe5mOXXufxJW6BDy //9ZM9JqA1n38WaJVe5W6P7x//9ZM9JqDFn38WYpVepmOXXqfwhmAU3qZv9N6I1F+FCNRehQ /xWw0EAAjUX4UI1F+FCNRfhQV/8VMNFAAFf/FSTRQABfXsnDVYvsgeyUAAAAU1ZXagFbU+ij 8f//vgQBAAAz/1ZXaOw3SQDoyiAAAFZXaOg2SQDoviAAAFZXaOQ1SQDosiAAAFZXaOA0SQDo piAAAFZXaNwzSQDomiAAAIPEQGjQ8EAAaGYiAABo1PBAAOjH3///aPg4SQDoCdD//4PEEP8V vNBAACUAAACAiT0AOUkAo/A4SQCNhWz///9Qx4Vs////lAAAAP8VuNBAAIO9cP///wV1Djmd dP///3UGiR0AOUkA6FXz//++ANAHAFbowSgAADvHWaPYM0kAdQQzwOskVldQ6AwgAADo1QAA AFNoBA5BAOiK3f//UFfoTv3//4PEHIvDX15bycNVi+yD7BRXjU3s6DfA//+NRfxqAFCNTez/ dQjoKcD//4v4hf8PhIwAAABWvgAQAAA5dfxzBDP263JT/3UM6PkgAACL2ItF/AUY/P//WTvG dlaNBD5TUP91DOi9LAAAg8QMhcB0D4tF/EYFGPz//zvwct/rM418PhS+ZiIAAI1f/FNWV+in 3v//i0UMVoPAFFBX6GUkAABT6ADe//9TVlfoL97//4PEKGoBXluNTezoUMD//4vGXl/Jw1NV VldqAmiTC0EA6LDc//+LHfTQQABZWVD/04s1ONFAAIvohe2/kwxBAHQ5agFX6Izc//9ZWVBV /9ZqBFejCDlJAOh53P//WVlQVf/WagVXowQ5SQDoZtz//1lZUFX/1qMMOUkAagNokwtBAOhP 3P//WVlQ/9OL6IXtdBNqA1foPNz//1lZUFX/1qMQOUkAv8gNQQBX/9OL2IXbdBNqAVfoG9z/ /1lZUFP/1qMUOUkAX15dW8NVi+yB7EwGAABTVleNTeToxL7//4t9CDPbV4ld9OiQ7///hcBZ D4VqAgAAV+jP+P//hcBZD4VbAgAAvvsMQQBTVuj12///iUX8jYW4+v//U1BTU1fo7x8AAIPE HDld/IldCH4x/3UIVuie2///OBhZWXQXUI2FuPr//1DoleP//1mFwFkPhQsCAAD/RQiLRQg7 Rfx8z42FyP7//1Dog+X//42FvPv//8cEJAQBAABQU/8VFNFAAI2FyP7//1NQjYW8+///UP8V fNBAAIXAD4TCAQAAizWA0EAAjYXI/v//aiBQ/9ZoAFABAI2FyP7//1dQ6LH0//+DxAyFwA+E hwEAAI1F+FNQV41N5OjMvf//O8OJRQgPhG4BAACBffgAUAEAD4ZZAQAAgX34AAAwAA+DTAEA AI2FvPv//1NQjYW0+f//UI2FxP3//1BX6PgeAACNhbT5//9QjYXE/f//UOiKHQAAjYW8+/// UI2FxP3//1Dodx0AAI2FxP3//2is8EAAUOhmHQAAagRqA42FwPz//2oDUOgj3f//D76FwPz/ /1DotSAAAIPEQIiFwPz//42FwPz//1CNhcT9//9Q6CsdAACNRfRQ/3X4/3UI6BkaAACDxBQ7 w4lFCI1N5A+EoQAAAOiuvf///3X0jYXE/f///3UIUOha4///jYXE/f//UOiq+v//g8QQjYXE /f//aidQ/9aNRcxQV+io5v//WYlF/FlqIFf/1lONhcj+//9XUP8VfNBAAI2FyP7//1DoUOT/ /42FxP3//1Bo1ABBAOiKHAAAaMDwQABX6DT8//+DxBQ5Xfx0DI1FzFBX6J3m//9ZWf91COj+ IAAAWWoBWOsXjU3k6A29//+Nhcj+//9Q6P7j//9ZM8BfXlvJw1WL7IHsKAQAAFaNTejoKrz/ /4Nl/ACNRfhqAVD/dQiNTejoGLz//4vwhfYPhJMAAACNheD9//9QjYXY+///UI2F3Pz//1CN heT+//9Q/3UI6FcdAACNhdz8//9QjYXk/v//UOjpGwAAjYXY+///UI2F5P7//1Do1hsAAICl 5f3//wCNheH9//9QjYXk/v//UOi8GwAAjYXk/v//aNwBQQBQ6KsbAACNRfxQ/3X4VuiqGQAA i/CDxECF9o1N6HUJ6DW8//8zwOtU6Cy8////dfyNheT+//9WUOja4f//Vuj5HwAAg8QQM/b/ FcTQQABQjYXk/v//UOjY6///WYXAWXQZav9Q/xXA0EAAjYXk/v//UOjg4v//WWoBXovGXsnD VYvsgewEAQAAjYX8/v//aAQBAABQaKAxQQBqBWhSAkEA6CrY//9ZWVBoAQAAgOiO6f//agGN hfz+////dQz/dQhQ6ODo//+DxCTJw1WL7IHsDAIAAFMz2zldDFZXiV38D4WLAQAAvosJQQBT VugO2P//i/iNhfT9//9QjYX4/v//UFNTiJ34/v///3UI6PsbAACDxBxPO/uJXQx+Mf91DFbo qtf//1CNhfj+//9Q6D9sAACDxBCFwHUMOX0MdAfHRfwBAAAA/0UMOX0MfM+NhfT9//9QjYX4 /v//UOhRGgAAvhsLQQBTVuiT1///g8QQM/87w4lFDH4oV1boUNf//1CNhfj+//9Q6OVrAACD xBCFwHUHx0X8AQAAAEc7fQx82Dld/HQpagFo8A1BAOge1///i3UIUFboHt///4PEEIXAdQ9W 6I7h//9Z6aIAAACLdQhW6MXf//+L+Fk7+3w1VmjoNkkA6LgZAABZg/8FWX02VmjsN0kA6KYZ AABqAWgA0AcA/zXYM0kAVuiY5///g8QY6xOD/5x1DlNq/2r/Vuh6EgAAg8QQixUYOUkAadIs AQAAgfpYGwAAfhdT6Mfp//9ZM9JqBVn38YPCB2nS6AMAAFL/FSzRQAD/BRg5SQCBPRg5SQAQ JwAAfgaJHRg5SQBqAVhfXlvJw1WL7IHsDAMAAFMz242F9Pz//1NQjYX8/v//UFP/dQjocBoA AIPEFDldDHVtOV0QdT+Nhfz+//9Q6NwZAAA7w1l0B4icBfv+//+Nhfj9//9TUFONhfz+//9T UOg1GgAAjYX4/f//UOh63v//g8QY6w2NhfT8//9Q6Gne//9ZhcB0GGoBaADQBwD/NdgzSQD/ dQjomOb//4PEEGoBWFvJw1ZXi3wkDGoBXmhuCUEAV+iu3f//WYXAWXQlaG0JQQBX6J3d//9Z hcBZdAIz9lZoJ15AAFfoHeD//4PEDGoBWF9ew1WL7IHsDAsAAItFFFNWV/91DDPbiRiNhfT0 //9Q6CYYAACNhfT0//9oRPBAAFDoJRgAAP91EI2F9PT//1DoFhgAAI2F9Pj//2gABAAAUI2F 9PT//1NQaAIAAIDoh+b//42F9Pj//1CNhfz+//9Q6NUXAACDxDSNhfT4//9oBAEAAFCNhfz+ //9Q/xXI0EAAvosJQQBTVugL1f//iUUUjYX0/P//U1BTjYX0+P//U1Do/xgAAIPEHDP/OV0U fitXVuix1P//OBhZWXQTUI2F9Pz//1DoqNz//1mFwFl1Bkc7fRR82jt9FHwkjYX0+P//aCMN QQBQ6Ibc//9ZhcBZdA2NhfT4//9Q6F/4//9ZU42F+P3//1NQjYX8/v//UI2F9Pj//1DoihgA AI2F+P3//1CNhfz+//9Q6BwXAACNhfz+//9Q6Hb+//+DxCBo6AMAAP8VLNFAAGoBWF9eW8nD VYvsgewIAQAAgKX4/v//AI2F+P7//2oBUOhf3P//jUX8UI2F+P7//2gIX0AAUGgCAACA6PPl //+DxBhogO42AP8VLNFAAOvBVYvsg30MAHU0g30QAHUIagX/FSzRQAD/dQjoftz//4XAWXwU g/gDfQ//dQho7DdJAOhsFgAAWVlqAVhdw/91COjT/f//hcBZdAQzwF3DM8A5RRAPlMBdw1WL 7IHsDAEAAICl9P7//wBTjYX0/v//aAQBAABQagFobQlBAOhP0///WVlQaFICQQBoAgAAgOiu 5P//jYX0/v//UOh5/f//D76F9P7//4qd9v7//1DobhkAAIPEHINl+ACIRf+KRfgEYTpF/3Q8 gKX2/v//AIiF9P7//42F9P7//1D/FczQQACD+AOInfb+//91F/91CI2F9P7//2iuYEAAUOhv 3f//g8QM/0X4g334GnyxM8BbycIEAFZohQlBAP90JBDogRUAAIt0JBBW6GcWAACDxAwzyYXA fguAPDFAdAVBO8h89Ug7yHwEM8Bew41EMQFQ/3QkEOhcFQAAWVlqAVhew1WL7IHsFAIAAIA9 1DJJAABWD4SbAAAAgD3QMUkAAA+EjgAAAIN9EACLdQh0ElboA7b///91DFbo0sD//4PEDGpk aAABAABqGWjUMkkAjY3s/f//6NjJ//9qBGoKjUWcagNQ6L3U//+DxBCNRZyNjez9//9Q6DvO //+DxmSNjez9//9W6OrO//9o0DFJAI2N7P3//+gxzv//jY3s/f//6MTK//+FwHQQjY3s/f// 6FDK//8zwF7Jw/91DOh2FQAAWVCNjez9////dQzo9Mr//42N7P3//4vw6CbK//8zwIX2D5TA 689Vi+yB7BgDAABWi3UIjYXo/P//UFbotv7//1mFwFl1BzPA6boAAACDfRAAdBJW6B61//// dQxW6O2///+DxAxqZGgAAQAAjYXo/P//ahlQjY3s/f//6PHI//9qBGoKjUWcagNQ6NbT//+D xBCNRZyNjez9//9Q6FTN//+NRmSNjez9//9Q6APO//9WjY3s/f//6E7N//+Njez9///o4cn/ /4XAdBCNjez9///obcn//+lr/////3UM6JMUAABZUI2N7P3///91DOgRyv//jY3s/f//i/Do Q8n//zPAhfYPlMBeycNVi+yB7AAIAACApQD4//8AgKUA/P//AI2FAPj//1D/dQjoxv3//42F APz//1D/dQzot/3//42FAPz//1CNhQD4//9Q6ARlAACDxBj32BvAQMnDg+wQVVZXg0wkGP+9 ABAAAGoBVb7U8EAA/3QkKDP/iXwkIFbops///4PEEIXAD4XvAAAAV1boTtD//1k7x1mJRCQQ D46yAAAAUzPbhf+JXCQQfjNTVuj+z///WVlQV1bo9M///1lZUOhC////WYXAWXQIx0QkEAEA AABDO9981IN8JBAAdUxqAY1fATtcJBhYiUQkEH0uU1bou8///1lZUFdW6LHP//9ZWVDo//7/ /1mFwFl0BP9EJBBDO1wkFHzWi0QkEDtEJBh+CIlEJBiJfCQcRzt8JBQPjGz///+DfCQYAFt+ FYN8JBgAfA5V/3QkHFbow8///4PEDDP/agFV/3QkKFboxc7//4PEEIXAdRJVav9W6KHP//+D xAxHg/8KfNpqAVhfXl2DxBDDgewEAgAAU1VWV8dEJBABAAAAMtu+Xg5BAL0EAQAAvwEAAID/ dCQQjUQkGIgd1DJJAIgd0DFJAFZo6ChBAFDoBBYAAIPEEFVo1DJJAGoBVujYzv//WVlQjUQk IFBX6Dvg//+DxBQ4HdQySQB0J1Vo0DFJAGoCVuixzv//WVlQjUQkIFBX6BTg//+DxBQ4HdAx SQB1F/9EJBCDfCQQCX6EiB3UMkkAiB3QMUkAX15dW4HEBAIAAMNVi+y4IDAAAOhLGQAAU1ZX aAAAEADobRkAADPbWTvDiUXsdQlfXjPAW8nCBADo8O3//4XAdQ1oYOoAAP8VLNFAAOvqaADQ BwD/NdgzSQDo0/X//1lZagHoovr//+jp/v//jYWI8///aAQBAABQU/8VFNFAAI2F3P7//1Do D9j//1mJXfi+JAkAAOiU7f//hcB1Cmhg6gAA6YcDAACNhdz+//9Q6LPX//+FwFl1Wo2F3P7/ /1NQjYWI8///UP8VfNBAAI2F3P7//2ogUP8VgNBAAI2F3P7//2gAUAEAUOjb6P//U+jG4P// M9K5ACgAAPfxjYXc/v//gcIAUgEAUlDoYtn//4PEFFP/NdgzSQDok83//zlF+FlZiUXoD439 AgAAaHoiAACNheDP//9owPBAAFDowRQAAI2F4M///4id9N///1CNhdz+//9Q6K3v//9WjYWM 9P//U1Doig8AAP91+P812DNJAOgKzf//g8QoOBiJReQPhJUCAABQjYXw9P//UOjBDwAAU+gh 4P//M9KDxAz3deg7Vfh1AUI7Veh8AjPSUv812DNJAOjIzP//i/hZWTgfdRBT/zXYM0kA6LTM //9Zi/hZjYXc/v//UI2FOPr//1Dobw8AAI2FVPX//1dQ6GIPAACNhYz0//9XUOhVDwAAagGN hYz0////dexQ6P/5//+DxCSFwA+FAAIAAFaNhYz0//9TUOjLDgAAjYXc/v//UI2FOPr//1Do GA8AAI2FVPX//1dQ6AsPAACNhYz0//9XUOj+DgAA/3XkjYXw9P//UOjvDgAAagGNhYz0//// dexQ6H76//+DxDiFwHQMV+in+///WemSAQAAU2jU8EAA6B7M//+DTeD/WVmJRfSJXfBWjYWM 9P//U1DoRg4AAI2F3P7//1CNhTj6//9Q6JMOAACNhVT1//9XUOiGDgAA/3XkjYXw9P//UOh3 DgAAU+jX3v//M9KDxCj3dfQ7VeCJVfx1BEKJVfw7VfR8A4ld/P91/GjU8EAA6HbL//9QjYWM 9P//UOg7DgAAagGNhYz0////dexQ6Mr5//+DxByFwHUT/0Xwi0X8g33wBolF4A+MXP///4N9 8AYPjM0AAABTaCwOQQDoWcv//1OJRfToWN7//zPSg8QM93X0O1X0iVX8fAOJXfyNhVzy//9Q jYWw/f//UFfoM9L//42FsP3//2g08EAAUOjKDQAA/3X8aCwOQQDo28r//1CNhbD9//9Q6LAN AABWjYWM9P//U1DoMg0AAI2F3P7//1CNhTj6//9Q6H8NAACNhVT1//9XUOhyDQAAg8RAjYXw 9P///3XkUOhgDQAAjYWw/f//UI2FjPT//1DoTQ0AAGoBjYWM9P///3XsUOjc+P//g8Qc/0X4 i0X4O0XoD4wD/f//aMAnCQD/FSzRQADpW/z//1WL7IHsYAUAAGah9ChBAFZXagdmiUWgWTPA jX2i86tmq6HwKEEAjX3oiUXkM8CrZqsz/8dF4CAAAAA5PfA4SQCJffSJffgPhd8BAAA5PQg5 SQAPhNMBAACLdQg793QljUXgUI1FgFD/FWTQQACNRYBQjUYCUOhwXgAAWYXAWQ+EpwEAAI2F WP///4NN0P+JRdiNhbD+//+JRcCNhbD+//+JRciNRYBTUI1FoIl9xFCJfdSJfdzHRcx/AAAA 6GkMAABZjYUY////WWoiUGr/Vos1eNBAAGoBV//Wx0X8AgAAALtE8EAAikX8ahQEQYhF5I2F WP///1CNReRq/1BqAVf/1opF5Go0iEWgjYWw/v//UI1FoGr/UGoBV//WjUX0UI1FwFCNhRj/ //9qAlD/FQg5SQA5fQyJRfAPhN4AAAA7x3VgOX34dVtqAWjcAUEAV+gr3P//WYPgAVCNhaT7 //9Q6MXW//+Nhaj8//9TUOinCwAAjUWgUI2FqPz//1DopwsAAGoBjYWk+///V1CNhaj8//9X UP91COh6vP//g8Q4iUX4OX3wdXVqAWjCDUEAjYWg+v//V1Dob9b///91CI2FrP3//1DoTwsA AI2FrP3//1NQ6FILAACNRaBQjYWs/f//UOhCCwAAjYWs/f//U1DoNQsAAI2FoPr//1CNhaz9 //9Q6CILAABqAWr/jYWs/f//av9Q6PwDAACDxEj/RfyDffwFD4y8/v//W19eycNVi+y4nEMA AOjuEgAAjUUMV1CDTfz//3UIx0X4gD4AAGoDagFfV/91DOgpWwAAhcAPhUABAACNRfhTUI2F ZLz//1CNRfxQ/3UM6ANbAAAz2zld/IldCA+GEQEAAFaNtXi8///2RvgCjUbsdBP/dRBqAlDo if///4PEDOnbAAAAjYXs/P//UI2F8P3//1D/NujZ3v//g8QMhcAPhbsAAAD/dRCNhfD9//9Q 6CP9//9ZWVdo3AFBAFPoldr//1kjx1CNheT6//9Q6DDV//+DxBA5XRAPhIIAAABXjYXk+v// U1CNhez8//9TUI2F8P3//1Do87r//4PEGFdowg1BAFPoTdr//1kjx1CNhej7//9Q6OjU//// No2F9P7//1DoyQkAAI2F9P7//2hE8EAAUOjICQAAjYXo+///UI2F9P7//1DotQkAAFdq/42F 9P7//2r/UOiQAgAAg8Q4/0UIg8Ygi0UIO0X8D4L3/v//Xv91DOjWWQAAW1/Jw2oBWFBqAmoA 6Hr+//+DxAxoAN1tAP8VLNFAADPA6+S4hCMAAOhZEQAAU1VWV41EJBRoBAEAADPbUFP/FRTR QACLPYDQQAC+5DVJAGogVv/XU41EJBhWUP8VfNBAAGogVolEJBj/1zlcJBB0Vmh6IgAAjYQk HAEAAGjA8EAAUOifDQAAjYQkJAEAAIicJDgRAABQVuiP6P//aABQAQBW6ETh//9T6C/Z//8z 0rkAKAAA9/GBwgBSAQBSVujR0f//g8QoVuh85v//WWonVv/XOR3wOEkAv9wzSQB0RVZXaOA0 SQBoAgAAgOiB1///agFokwtBAOioxf//g8QYUP8V9NBAAIvoaJMMQQBV/xU40UAAO8N0BWoB U//QVf8V8NBAADlcJBB1BDPA63U5HfA4SQB0C1NW6MvY//9ZWetfOR34OEkAdVeLLQDQQABq AlNT/9VTU1NTU1ZTagJoEAEAAFNXV1CJRCRE/xVI0EAA/3QkEIs1QNBAAP/WagFTU//Vi+hq EFdV/xU40EAAi/hTU1f/FSTQQABX/9ZV/9ZqAVhfXl1bgcSEIwAAw1WL7FGh8ChBAIlF/IpF CABF/I1F/FD/FczQQACD+AN0DIP4BHQHagFYycIEAGoAjUX8aHpcQABQ6FfP//+DxAxoAHS3 Af8VLNFAAOvgVYvsgexYAgAAVr5SAkEAjYXU/v//VlDoXwcAAGoHVuiFxP//UI2F1P7//1Do WgcAAIClqP3//wCNhaj9//9oLAEAAFCNhdT+//9o8A1BAFBoAgAAgOjA1f//agCNhaj9//9o elxAAFDo2s7//4PEODPAXsnCBABVi+y4kCUAAOgHDwAAi0UQU1aLdQwz21c5XRSJdfyJRfh1 Ef91COiu1///hcBZD4U+AQAAv3QNQQBTV+gixP//WTvzWYlFDH0PU+gb1///M9JZ93UMiVX8 vtwBQQBTVuj+w///OV0QWVmJRQx9D1Po9tb//zPSWfd1DIlV+I2F9P7//1Dows3//42F7Pz/ /8cEJAQBAABQU/8VFNFAAI2F9P7//1NQjYXs/P//UP8VfNBAAIXAD4S3AAAAjYX0/v//aiBQ /xWA0EAAaHoiAACNhXDa//9owPBAAFDo1AoAAI2FcNr//4idhOr//1CNhfT+//9Q6MDl//9T 6GvW//8z0rkAKAAA9/GNhfT+//+BwgBSAQBSUOgHz////3X8V+gOw///UI2F8P3//1Do0wUA AP91+Fbo+ML//1CNhfD9//9Q6M0FAACDxECNhfD9////dRRQjYX0/v//UP91COh34P//jYX0 /v//UOhKzf//g8QUX15bycNq//8VLNFAAOv2VYvsgewgAgAAagRqBY1F6GoCUOhKxf//gKXg /f//AIPEEI2F4P3//2gEAQAAUGoBaG0JQQDod8L//1lZUGhSAkEAaAIAAIDo1tP//4PEFI2F 5P7//1CNRehqAFCNheD9//9Q/xV00EAAjYXk/v//UOjDzP//jYXk/v//UOjyBQAAWVlIeAqA vAXk/v//LnXzhcB+FI2EBeT+//9o3AFBAFDo3QQAAFlZjUX8VlBophUAAGhAE0EA6OMCAAD/ dfyL8I2F5P7//1ZQ6CvL//+DxBiFwHUfjYXk/v//UOjpy////3X8jYXk/v//VlDoCMv//4PE EI2F5P7//2oAUOgT1f//WVlehcB0Fmr/UP8VwNBAAI2F5P7//1DoGsz//1kzwMnCBABVi+xR U1aLNdDQQABXjUX8M/9QV1do/xVAAFdX/9aNRfxQV1doCGZAAFdX/9aNRfxQV1do3m1AAFdX /9aNRfxQV1doZmBAAFdX/9aNRfxQV1dozXFAAFdX/9aNRfxQV1do1W9AAFdX/9Yz241F/FBX U2iIb0AAV1f/1kOD+xp86+hM/v//X15bycNVi+yD7BwzwMdF5BABAACJReyJRfCJRfSJRfiJ RfyNReRQx0XoBAAAAP81HDlJAP8VWNBAAOiT2P//hcB0Begz////ycIEAGh8c0AAaNwzSQD/ FTTQQABqAKMcOUkA6J3////CCABVi+yB7KABAACNhWD+//9QagL/FeDRQADo/+H//4XAdFTo 9fn//4A91ABBAAB0D2jUAEEA6PTm//+FwFl1N4M9+DhJAAB0IINl+ACDZfwAjUXwx0Xw3DNJ AFDHRfTDc0AA/xUE0EAA6PvX//+FwHQF6Jv+//8zwMnCEABVi+y4jDgBAOj2CgAAU1b/dQzo GwsAAIvYM/Y73lmJXfSJdfiJdfx1BzPA6dsAAABXaIA4AQCNhXTH/v9WUOhQAgAAg8QMM8CN vXjH/v87RQxzZotNCIoMCITJdA2IDB5GQIl1/DtFDHLpO0UMc0qLyItVCIA8EQB1BkE7TQxy 8YvRK9CD+gpzETvBc8GLVQiKFBCIFB5GQOvvgX34ECcAAHMP/0X4iUf8iReDxwiLweuciXX8 M/brSItF+Il1/Iv4wecDjVw3BFPoZAoAAIvwi0X4V4kGjYV0x/7/UI1GBFDovQYAAP91/I1E NwT/dfRQ6K0GAACLRRCDxByJGItd9FPohwYAAFmLxl9eW8nDVYvsg+wMU4tdCFZXiwMz0ov4 jUsEwecDiVX8iU30jXcEiUX4OXUMcwczwOmcAAAAhcB2I4vxiUUIiw470XMHK8oD0QFN/ItG BIXAdgID0IPGCP9NCHXii0UMK8eDwPw5RfyJRQxzBStF/APQi0UQM/YhdfxSiRDopwkAAI18 HwSLXfiF21l2LotN9Dsxcw+LVfyKFDqIFDBG/0X86+0z0jlRBHYLgCQwAEZCO1EEcvWDwQhL ddWLTfw7TQxzDgPwihQ5iBZGQTtNDHL0X15bycPM/yUc0UAA/yUM0UAA/yUQ0UAA/yUA0UAA zMzMzMzMzMzMzItUJASLTCQI98IDAAAAdTyLAjoBdS4KwHQmOmEBdSUK5HQdwegQOkECdRkK wHQROmEDdRCDwQSDwgQK5HXSi/8zwMOQG8DR4EDDi//3wgEAAAB0FIoCQjoBdelBCsB04PfC AgAAAHSoZosCg8ICOgF10grAdMo6YQF1yQrkdMGDwQLrjMzMzMzMzMzMzMzMzItUJAyLTCQE hdJ0RzPAikQkCFeL+YP6BHIt99mD4QN0CCvRiAdHSXX6i8jB4AgDwYvIweAQA8GLyoPiA8Hp AnQG86uF0nQGiAdHSnX6i0QkCF/Di0QkBMPMzMzMzMzMzFeLfCQI62qNpCQAAAAAi/+LTCQE V/fBAwAAAHQPigFBhMB0O/fBAwAAAHXxiwG6//7+fgPQg/D/M8KDwQSpAAEBgXToi0H8hMB0 I4TkdBqpAAD/AHQOqQAAAP90AuvNjXn/6w2Nef7rCI15/esDjXn8i0wkDPfBAwAAAHQZihFB hNJ0ZIgXR/fBAwAAAHXu6wWJF4PHBLr//v5+iwED0IPw/zPCixGDwQSpAAEBgXThhNJ0NIT2 dCf3wgAA/wB0EvfCAAAA/3QC68eJF4tEJAhfw2aJF4tEJAjGRwIAX8NmiReLRCQIX8OIF4tE JAhfw4tMJAT3wQMAAAB0FIoBQYTAdED3wQMAAAB18QUAAAAAiwG6//7+fgPQg/D/M8KDwQSp AAEBgXToi0H8hMB0MoTkdCSpAAD/AHQTqQAAAP90AuvNjUH/i0wkBCvBw41B/otMJAQrwcON Qf2LTCQEK8HDjUH8i0wkBCvBw1WL7FGDZfwAU4tdCFZXU+hx////g/gBWXIhgHsBOnUbi3UM hfZ0EGoCU1bojBAAAIPEDIBmAgBDQ+sKi0UMhcB0A4AgAINlDACAOwCLw77/AAAAiUUIdGWK CA+20faCYU1JAAR0A0DrGoD5L3QPgPlcdAqA+S51C4lF/OsGjUgBiU0MQIA4AHXPi30MiUUI hf90KoN9EAB0Hyv7O/5yAov+V1P/dRDoERAAAItFEIPEDIAkBwCLRQiLXQzrCotNEIXJdAOA IQCLffyF/3RMO/tySIN9FAB0Hyv7O/5yAov+V1P/dRTo0g8AAItFFIPEDIAkBwCLRQiLfRiF /3REK0X8O8ZzAovwVv91/Ffoqw8AAIPEDIAkPgDrKIt9FIX/dBcrwzvGcwKL8FZTV+iLDwAA g8QMgCQ+AItFGIXAdAOAIABfXlvJw1WL7FGDPTw5SQAAU3Udi0UIg/hhD4yvAAAAg/h6D4+m AAAAg+gg6Z4AAACLXQiB+wABAAB9KIM9HCxBAAF+DGoCU+gHEgAAWVnrC6EQKkEAigRYg+AC hcB1BIvD62uLFRAqQQCLw8H4CA+2yPZESgGAdA6AZQoAiEUIiF0JagLrCYBlCQCIXQhqAViN TfxqAWoAagNRUI1FCFBoAAIAAP81PDlJAOhVDwAAg8QghcB0qYP4AXUGD7ZF/OsND7ZF/Q+2 TfzB4AgLwVvJw1WL7FGDPTw5SQAAU1ZXdR2LRQiD+EEPjKoAAACD+FoPj6EAAACDwCDpmQAA AItdCL8AAQAAagE73159JTk1HCxBAH4LVlPoNxEAAFlZ6wqhECpBAIoEWCPGhcB1BIvD62WL FRAqQQCLw8H4CA+2yPZESgGAdA+AZQoAagKIRQiIXQlY6wmAZQkAiF0Ii8ZWagCNTfxqA1FQ jUUIUFf/NTw5SQDoiw4AAIPEIIXAdK47xnUGD7ZF/OsND7ZF/Q+2TfzB4AgLwV9eW8nDVYvs g+wgi0UIVolF6IlF4I1FEMdF7EIAAABQjUXg/3UMx0Xk////f1DoExIAAIPEDP9N5IvweAiL ReCAIADrDY1F4FBqAOjhEAAAWVmLxl7Jw/90JATo8BkAAFnDzMzMzMzMzMzMzFWL7FdWi3UM i00Qi30Ii8GL0QPGO/52CDv4D4J4AQAA98cDAAAAdRTB6QKD4gOD+QhyKfOl/ySVSH1AAIvH ugMAAACD6QRyDIPgAwPI/ySFYHxAAP8kjVh9QACQ/ySN3HxAAJBwfEAAnHxAAMB8QAAj0YoG iAeKRgGIRwGKRgLB6QKIRwKDxgODxwOD+QhyzPOl/ySVSH1AAI1JACPRigaIB4pGAcHpAohH AYPGAoPHAoP5CHKm86X/JJVIfUAAkCPRigaIB0bB6QJHg/kIcozzpf8klUh9QACNSQA/fUAA LH1AACR9QAAcfUAAFH1AAAx9QAAEfUAA/HxAAItEjuSJRI/ki0SO6IlEj+iLRI7siUSP7ItE jvCJRI/wi0SO9IlEj/SLRI74iUSP+ItEjvyJRI/8jQSNAAAAAAPwA/j/JJVIfUAAi/9YfUAA YH1AAGx9QACAfUAAi0UIXl/Jw5CKBogHi0UIXl/Jw5CKBogHikYBiEcBi0UIXl/Jw41JAIoG iAeKRgGIRwGKRgKIRwKLRQheX8nDkI10MfyNfDn898cDAAAAdSTB6QKD4gOD+QhyDf3zpfz/ JJXgfkAAi//32f8kjZB+QACNSQCLx7oDAAAAg/kEcgyD4AMryP8kheh9QAD/JI3gfkAAkPh9 QAAYfkAAQH5AAIpGAyPRiEcDTsHpAk+D+Qhytv3zpfz/JJXgfkAAjUkAikYDI9GIRwOKRgLB 6QKIRwKD7gKD7wKD+QhyjP3zpfz/JJXgfkAAkIpGAyPRiEcDikYCiEcCikYBwekCiEcBg+4D g+8Dg/kID4Ja/////fOl/P8kleB+QACNSQCUfkAAnH5AAKR+QACsfkAAtH5AALx+QADEfkAA 135AAItEjhyJRI8ci0SOGIlEjxiLRI4UiUSPFItEjhCJRI8Qi0SODIlEjwyLRI4IiUSPCItE jgSJRI8EjQSNAAAAAAPwA/j/JJXgfkAAi//wfkAA+H5AAAh/QAAcf0AAi0UIXl/Jw5CKRgOI RwOLRQheX8nDjUkAikYDiEcDikYCiEcCi0UIXl/Jw5CKRgOIRwOKRgKIRwKKRgGIRwGLRQhe X8nDi0QkBKMAKUEAw6EAKUEAacD9QwMABcOeJgCjAClBAMH4ECX/fwAAw8zMzFE9ABAAAI1M JAhyFIHpABAAAC0AEAAAhQE9ABAAAHPsK8iLxIUBi+GLCItABFDDagH/dCQI6IsWAABZWcNV i+yD7CCLRQjHRexJAAAAUIlF6IlF4OiH+P//iUXkjUUQUI1F4P91DFDouxYAAIPEEMnDzMzM zMzMzMzMzMzMzMzMVYvsV1aLdQyLTRCLfQiLwYvRA8Y7/nYIO/gPgngBAAD3xwMAAAB1FMHp AoPiA4P5CHIp86X/JJUogUAAi8e6AwAAAIPpBHIMg+ADA8j/JIVAgEAA/ySNOIFAAJD/JI28 gEAAkFCAQAB8gEAAoIBAACPRigaIB4pGAYhHAYpGAsHpAohHAoPGA4PHA4P5CHLM86X/JJUo gUAAjUkAI9GKBogHikYBwekCiEcBg8YCg8cCg/kIcqbzpf8klSiBQACQI9GKBogHRsHpAkeD +QhyjPOl/ySVKIFAAI1JAB+BQAAMgUAABIFAAPyAQAD0gEAA7IBAAOSAQADcgEAAi0SO5IlE j+SLRI7oiUSP6ItEjuyJRI/si0SO8IlEj/CLRI70iUSP9ItEjviJRI/4i0SO/IlEj/yNBI0A AAAAA/AD+P8klSiBQACL/ziBQABAgUAATIFAAGCBQACLRQheX8nDkIoGiAeLRQheX8nDkIoG iAeKRgGIRwGLRQheX8nDjUkAigaIB4pGAYhHAYpGAohHAotFCF5fycOQjXQx/I18Ofz3xwMA AAB1JMHpAoPiA4P5CHIN/fOl/P8klcCCQACL//fZ/ySNcIJAAI1JAIvHugMAAACD+QRyDIPg AyvI/ySFyIFAAP8kjcCCQACQ2IFAAPiBQAAggkAAikYDI9GIRwNOwekCT4P5CHK2/fOl/P8k lcCCQACNSQCKRgMj0YhHA4pGAsHpAohHAoPuAoPvAoP5CHKM/fOl/P8klcCCQACQikYDI9GI RwOKRgKIRwKKRgHB6QKIRwGD7gOD7wOD+QgPglr////986X8/ySVwIJAAI1JAHSCQAB8gkAA hIJAAIyCQACUgkAAnIJAAKSCQAC3gkAAi0SOHIlEjxyLRI4YiUSPGItEjhSJRI8Ui0SOEIlE jxCLRI4MiUSPDItEjgiJRI8Ii0SOBIlEjwSNBI0AAAAAA/AD+P8klcCCQACL/9CCQADYgkAA 6IJAAPyCQACLRQheX8nDkIpGA4hHA4tFCF5fycONSQCKRgOIRwOKRgKIRwKLRQheX8nDkIpG A4hHA4pGAohHAopGAYhHAYtFCF5fycODPRwsQQABfhFoAwEAAP90JAjoJAkAAFlZw4tEJASL DRAqQQBmiwRBJQMBAADDgz0cLEEAAX4OagT/dCQI6PkIAABZWcOLRCQEiw0QKkEAigRBg+AE w4M9HCxBAAF+DmoI/3QkCOjRCAAAWVnDi0QkBIsNECpBAIoEQYPgCMPMzMzMzMzMzMzMzMzM i0wkCFdTVooRi3wkEITSdGmKcQGE9nRPi/eLTCQUigdGONB0FYTAdAuKBkY40HQKhMB19V5b XzPAw4oGRjjwdeuNfv+KYQKE5HQoigaDxgI44HXEikEDhMB0GIpm/4PBAjjgdN/rsTPAXltf isLpQx0AAI1H/15bX8OLx15bX8NVi+xXVlOLTRDjJovZi30Ii/czwPKu99kDy4v+i3UM86aK Rv8zyTpH/3cEdARJSffRi8FbXl/Jw1WL7Gr/aEDSQABoBKxAAGShAAAAAFBkiSUAAAAAg+xY U1ZXiWXo/xW80EAAM9KK1IkVbDlJAIvIgeH/AAAAiQ1oOUkAweEIA8qJDWQ5SQDB6BCjYDlJ ADP2VugWJgAAWYXAdQhqHOiwAAAAWYl1/OhWJAAA/xXE0EAAo2hOSQDoFCMAAKMgOUkA6L0g AADo/x8AAOgcHQAAiXXQjUWkUP8VeNFAAOiQHwAAiUWc9kXQAXQGD7dF1OsDagpYUP91nFZW /xV00UAAUOi87v//iUWgUOgKHQAAi0XsiwiLCYlNmFBR6M4dAABZWcOLZej/dZjo/BwAAIM9 KDlJAAF1BeiAJwAA/3QkBOiwJwAAaP8AAAD/FRApQQBZWcODPSg5SQABdQXoWycAAP90JATo iycAAFlo/wAAAP8VfNFAAMNVi+yD7BhTVlf/dQjoiAEAAIvwWTs1OExJAIl1CA+EagEAADPb O/MPhFYBAAAz0rggKUEAOTB0coPAMEI9ECpBAHzxjUXoUFb/FYDRQACD+AEPhSQBAABqQDPA Wb9gTUkAg33oAYk1OExJAPOrqokdZE5JAA+G7wAAAIB97gAPhLsAAACNTe+KEYTSD4SuAAAA D7ZB/w+20jvCD4eTAAAAgIhhTUkABEDr7mpAM8BZv2BNSQDzq400Uold/MHmBKqNnjApQQCA OwCLy3QsilEBhNJ0JQ+2AQ+2+jvHdxSLVfyKkhgpQQAIkGFNSQBAO8d29UFBgDkAddT/RfyD wwiDffwEcsGLRQjHBUxMSQABAAAAUKM4TEkA6MYAAACNtiQpQQC/QExJAKWlWaNkTkkApetV QUGAef8AD4VI////agFYgIhhTUkACEA9/wAAAHLxVuiMAAAAWaNkTkkAxwVMTEkAAQAAAOsG iR1MTEkAM8C/QExJAKurq+sNOR0sOUkAdA7ojgAAAOiyAAAAM8DrA4PI/19eW8nDi0QkBIMl LDlJAACD+P51EMcFLDlJAAEAAAD/JYjRQACD+P11EMcFLDlJAAEAAAD/JYTRQACD+Px1D6FM OUkAxwUsOUkAAQAAAMOLRCQELaQDAAB0IoPoBHQXg+gNdAxIdAMzwMO4BAQAAMO4EgQAAMO4 BAgAAMO4EQQAAMNXakBZM8C/YE1JAPOrqjPAv0BMSQCjOExJAKNMTEkAo2ROSQCrq6tfw1WL 7IHsFAUAAI1F7FZQ/zU4TEkA/xWA0UAAg/gBD4UWAQAAM8C+AAEAAIiEBez+//9AO8Zy9IpF 8saF7P7//yCEwHQ3U1eNVfMPtgoPtsA7wXcdK8iNvAXs/v//QbggICAgi9nB6QLzq4vLg+ED 86pCQopC/4TAddBfW2oAjYXs+v///zVkTkkA/zU4TEkAUI2F7P7//1ZQagHo8yUAAGoAjYXs /f///zU4TEkAVlCNhez+//9WUFb/NWROSQDoaAEAAGoAjYXs/P///zU4TEkAVlCNhez+//9W UGgAAgAA/zVkTkkA6EABAACDxFwzwI2N7Pr//2aLEfbCAXQWgIhhTUkAEIqUBez9//+IkGBM SQDrHPbCAnQQgIhhTUkAIIqUBez8///r44CgYExJAABAQUE7xnK/60kzwL4AAQAAg/hBchmD +Fp3FICIYU1JABCKyIDBIIiIYExJAOsfg/hhchOD+Hp3DoCIYU1JACCKyIDpIOvggKBgTEkA AEA7xnK+XsnDgz0oTEkAAHUSav3oLPz//1nHBShMSQABAAAAw1WL7IM9TExJAABXi30IiX0I dRH/dRD/dQxX6ComAACDxAzrY4tVEFaF0nQ9i00MigFKD7bw9oZhTUkABIgHdBNHQYXSdBmK AUqIB0dBhMB0FOsGR0GEwHQQhdJ10usKgGf/AOsEgGf+AIvCSoXAXnQTjUoBM8CL0cHpAvOr i8qD4QPzqotFCF9dw1WL7Gr/aFjSQABoBKxAAGShAAAAAFBkiSUAAAAAg+wcU1ZXiWXoM/85 PTA5SQB1RldXagFbU2hQ0kAAvgABAABWV/8VPNFAAIXAdAiJHTA5SQDrIldXU2hM0kAAVlf/ FUDRQACFwA+EIgEAAMcFMDlJAAIAAAA5fRR+EP91FP91EOieAQAAWVmJRRShMDlJAIP4AnUd /3Uc/3UY/3UU/3UQ/3UM/3UI/xVA0UAA6d4AAACD+AEPhdMAAAA5fSB1CKFMOUkAiUUgV1f/ dRT/dRCLRST32BvAg+AIQFD/dSD/FXjQQACL2Ild5DvfD4ScAAAAiX38jQQbg8ADJPzoXfT/ /4ll6IvEiUXcg038/+sTagFYw4tl6DP/iX3cg038/4td5Dl93HRmU/913P91FP91EGoB/3Ug /xV40EAAhcB0TVdXU/913P91DP91CP8VPNFAAIvwiXXYO/d0MvZFDQR0QDl9HA+EsgAAADt1 HH8e/3Uc/3UYU/913P91DP91CP8VPNFAAIXAD4WPAAAAM8CNZciLTfBkiQ0AAAAAX15bycPH RfwBAAAAjQQ2g8ADJPzoqfP//4ll6IvciV3gg038/+sSagFYw4tl6DP/M9uDTfz/i3XYO990 tFZT/3Xk/3Xc/3UM/3UI/xU80UAAhcB0nDl9HFdXdQRXV+sG/3Uc/3UYVlNoIAIAAP91IP8V oNBAAIvwO/cPhHH///+Lxuls////i1QkCItEJASF0laNSv90DYA4AHQIQIvxSYX2dfOAOABe dQUrRCQEw4vCw1WL7FGLRQiNSAGB+QABAAB3DIsNECpBAA+3BEHrUovIVos1ECpBAMH5CA+2 0fZEVgGAXnQOgGX+AIhN/IhF/WoC6wmAZf0AiEX8agFYjU0KagFqAGoAUVCNRfxQagHotSEA AIPEHIXAdQLJww+3RQojRQzJw1WL7FNWi3UMi0YMi14QqIIPhPMAAACoQA+F6wAAAKgBdBaD ZgQAqBAPhNsAAACLTggk/okOiUYMi0YMg2YEAINlDAAk7wwCZqkMAYlGDHUigf6gLUEAdAiB /sAtQQB1C1PoHiYAAIXAWXUHVujPJQAAWWb3RgwIAVd0ZItGCIs+K/iNSAGJDotOGEmF/4lO BH4QV1BT6PkjAACDxAyJRQzrM4P7/3QWi8OLy8H4BYPhH4sEhSBLSQCNBMjrBbjILEEA9kAE IHQNagJqAFPoJyMAAIPEDItGCIpNCIgI6xRqAY1FCF9XUFPopiMAAIPEDIlFDDl9DF90BoNO DCDrD4tFCCX/AAAA6wgMIIlGDIPI/15bXcNVi+yB7EgCAABTVleLfQwz9oofR4TbiXX0iXXs iX0MD4T0BgAAi03wM9LrCItN8It10DPSOVXsD4zcBgAAgPsgfBOA+3h/Dg++w4qAUNJAAIPg D+sCM8APvoTGcNJAAMH4BIP4B4lF0A+HmgYAAP8khfuUQACDTfD/iVXMiVXYiVXgiVXkiVX8 iVXc6XgGAAAPvsOD6CB0O4PoA3Qtg+gIdB9ISHQSg+gDD4VZBgAAg038COlQBgAAg038BOlH BgAAg038Aek+BgAAgE38gOk1BgAAg038AuksBgAAgPsqdSONRRBQ6PUGAACFwFmJReAPjRIG AACDTfwE99iJReDpBAYAAItF4A++y40EgI1EQdDr6YlV8OntBQAAgPsqdR6NRRBQ6LYGAACF wFmJRfAPjdMFAACDTfD/6coFAACNBIkPvsuNREHQiUXw6bgFAACA+0l0LoD7aHQggPtsdBKA +3cPhaAFAACATf0I6ZcFAACDTfwQ6Y4FAACDTfwg6YUFAACAPzZ1FIB/ATR1DkdHgE39gIl9 DOlsBQAAiVXQiw0QKkEAiVXcD7bD9kRBAYB0GY1F7FD/dQgPvsNQ6H8FAACKH4PEDEeJfQyN RexQ/3UID77DUOhmBQAAg8QM6SUFAAAPvsOD+GcPjxwCAACD+GUPjZYAAACD+FgPj+sAAAAP hHgCAACD6EMPhJ8AAABISHRwSEh0bIPoDA+F6QMAAGb3RfwwCHUEgE39CIt18IP+/3UFvv// /3+NRRBQ6JwFAABm90X8EAhZi8iJTfgPhP4BAACFyXUJiw0sLEEAiU34x0XcAQAAAIvBi9ZO hdIPhNQBAABmgzgAD4TKAQAAQEDr58dFzAEAAACAwyCDTfxAjb24/f//O8qJffgPjc8AAADH RfAGAAAA6dEAAABm90X8MAh1BIBN/Qhm90X8EAiNRRBQdDvoMAUAAFCNhbj9//9Q6HUjAACD xAyJRfSFwH0yx0XYAQAAAOspg+hadDKD6Al0xUgPhOgBAADpCAMAAOjYBAAAWYiFuP3//8dF 9AEAAACNhbj9//+JRfjp5wIAAI1FEFDoswQAAIXAWXQzi0gEhcl0LPZF/Qh0Fw+/ANHoiU34 iUX0x0XcAQAAAOm1AgAAg2XcAIlN+A+/AOmjAgAAoSgsQQCJRfhQ6Y4AAAB1DID7Z3UHx0Xw AQAAAItFEP91zIPACIlFEP918ItI+IlNuItA/IlFvA++w1CNhbj9//9QjUW4UP8VADBBAIt1 /IPEFIHmgAAAAHQUg33wAHUOjYW4/f//UP8VDDBBAFmA+2d1EoX2dQ6Nhbj9//9Q/xUEMEEA WYC9uP3//y11DYBN/QGNvbn9//+JffhX6GHm//9Z6fwBAACD6GkPhNEAAACD6AUPhJ4AAABI D4SEAAAASHRRg+gDD4T9/f//SEgPhLEAAACD6AMPhckBAADHRdQnAAAA6zwrwdH46bQBAACF yXUJiw0oLEEAiU34i8GL1k6F0nQIgDgAdANA6/ErwemPAQAAx0XwCAAAAMdF1AcAAAD2RfyA x0X0EAAAAHRdikXUxkXqMARRx0XkAgAAAIhF6+tI9kX8gMdF9AgAAAB0O4BN/QLrNY1FEFDo GwMAAPZF/CBZdAlmi03sZokI6wWLTeyJCMdF2AEAAADpIwIAAINN/EDHRfQKAAAA9kX9gHQM jUUQUOjtAgAAWetB9kX8IHQh9kX8QI1FEFB0DOjIAgAAWQ+/wJnrJei8AgAAWQ+3wOvy9kX8 QI1FEFB0COinAgAAWevg6J8CAABZM9L2RfxAdBuF0n8XfASFwHMR99iD0gCL8PfagE39AYv6 6wSL8Iv69kX9gHUDg+cAg33wAH0Jx0XwAQAAAOsEg2X894vGC8d1BINl5ACNRbeJRfiLRfD/ TfCFwH8Gi8YLx3Q7i0X0mVJQV1aJRcCJVcTobyEAAP91xIvYg8Mw/3XAV1bo7SAAAIP7OYvw i/p+AwNd1ItF+P9N+IgY67WNRbcrRfj/Rfj2Rf0CiUX0dBmLTfiAOTB1BIXAdQ3/TfhAi034 xgEwiUX0g33YAA+F9AAAAItd/PbDQHQm9scBdAbGReot6xT2wwF0BsZF6ivrCfbDAnQLxkXq IMdF5AEAAACLdeArdeQrdfT2wwx1Eo1F7FD/dQhWaiDoFwEAAIPEEI1F7FCNRer/dQj/deRQ 6DIBAACDxBD2wwh0F/bDBHUSjUXsUP91CFZqMOjlAAAAg8QQg33cAHRBg330AH47i0X0i134 jXj/ZosDQ1CNRchQQ+iWHwAAWYXAWX4yjU3sUf91CFCNRchQ6NgAAACDxBCLx0+FwHXQ6xWN RexQ/3UI/3X0/3X46LoAAACDxBD2RfwEdBKNRexQ/3UIVmog6HEAAACDxBCLfQyKH0eE24l9 DA+FE/n//4tF7F9eW8nDeY9AAE+OQABqjkAAto5AAO2OQAD1jkAAKo9AAL2PQABVi+yLTQz/ SQR4DosRikUIiAL/AQ+2wOsLUf91COiI9///WVmD+P+LRRB1BYMI/13D/wBdw1ZXi3wkEIvH T4XAfiGLdCQYVv90JBj/dCQU6Kz///+DxAyDPv90B4vHT4XAf+NfXsNTi1wkDIvDS1ZXhcB+ Jot8JByLdCQQD74GV0b/dCQcUOh1////g8QMgz//dAeLw0uFwH/iX15bw4tEJASDAASLAItA /MOLRCQEgwAIiwiLQfiLUfzDi0QkBIMABIsAZotA/MNWi3QkCIX2dCRW6MAfAABZhcBWdApQ 6N8fAABZWV7DagD/NQRLSQD/FZDRQABew/81uDpJAP90JAjoAwAAAFlZw4N8JATgdyL/dCQE 6BwAAACFwFl1FjlEJAh0EP90JATodScAAIXAWXXeM8DDVot0JAg7NSAwQQB3C1bopSIAAIXA WXUchfZ1A2oBXoPGD4Pm8FZqAP81BEtJAP8VlNFAAF7DVYvsgezEAQAAgGXrAFNWi3UMM9tX igaJXfyEwIldzA+E4QkAAIt9COsFi30IM9uDPRwsQQABfg8PtsBqCFDohvX//1lZ6w+LDRAq QQAPtsCKBEGD4Ag7w3Q2/038V41F/FdQ6CUKAABZWVDoBgoAAA+2RgFGUOhp7P//g8QMhcB0 Dg+2RgFGUOhX7P//WevugD4lD4XZCAAAgGXLAIBl6ACAZekAgGXyAIBl8QCAZeoAM/+AZfsA iV3kiV3giV30xkXzAYld0A+2XgFGgz0cLEEAAX4PD7bDagRQ6On0//9ZWesPiw0QKkEAD7bD igRBg+AEhcB0EotF9P9F4I0EgI1EQ9CJRfTrZYP7Tn8+dF6D+yp0MoP7RnRUg/tJdAqD+0x1 N/5F8+tFgH4BNnUsgH4CNI1GAnUj/0XQg2XYAINl3ACL8Osn/kXy6yKD+2h0F4P7bHQKg/t3 dAj+RfHrDv5F8/5F++sG/k3z/k37gH3xAA+ET////4B98gCJdQx1EotFEIlFvIPABIlFEItA /IlF1IBl8QCAffsAdRSKBjxTdAo8Q3QGgE37/+sExkX7AYtdDA+2M4POIIP+bol1xHQog/5j dBSD/nt0D/91CI1F/FDotQgAAFnrC/91CP9F/Oh2CAAAWYlF7DPAOUXgdAk5RfQPhNwHAACD /m8Pj14CAAAPhAoFAACD/mMPhCwCAACD/mQPhPgEAAAPjmoCAACD/md+OIP+aXQbg/5uD4VX AgAAgH3yAIt9/A+EAAcAAOkhBwAAamRei13sg/stD4V+AgAAxkXpAel6AgAAi13sjbU8/v// g/stdQ6InTz+//+NtT3+///rBYP7K3UXi30I/030/0X8V+jOBwAAi9hZiV3s6wOLfQiDfeAA dAmBffRdAQAAfgfHRfRdAQAAgz0cLEEAAX4MagRT6Anz//9ZWesLoRAqQQCKBFiD4ASFwHQh i0X0/030hcB0F/9F5IgeRv9F/FfocAcAAIvYWYld7Ou7OB0gLEEAdWaLRfT/TfSFwHRc/0X8 V+hNBwAAi9igICxBAIgGWYld7EaDPRwsQQABfgxqBFPom/L//1lZ6wuhECpBAIoEWIPgBIXA dCGLRfT/TfSFwHQX/0XkiB5G/0X8V+gCBwAAi9hZiV3s67uDfeQAD4SOAAAAg/tldAmD+0UP hYAAAACLRfT/TfSFwHR2xgZlRv9F/FfoywYAAIvYWYP7LYld7HUFiAZG6wWD+yt1HotF9P9N 9IXAdQUhRfTrD/9F/FfongYAAIvYWYld7IM9HCxBAAF+DGoEU+j08f//WVnrC6EQKkEAigRY g+AEhcB0EotF9P9N9IXAdAj/ReSIHkbru/9N/FdT6HIGAACDfeQAWVkPhPYFAACAffIAD4VN BQAA/0XMgCYAjYU8/v//UA++RfP/ddRIUP8VCDBBAIPEDOkpBQAAOUXgdQr/RfTHReABAAAA gH37AH4ExkXqAb84LEEA6QsBAACLxoPocA+EowIAAIPoAw+E6AAAAEhID4SWAgAAg+gDD4TD /f//g+gDdCQPtgM7RewPhT8FAAD+TeuAffIAD4XDBAAAi0W8iUUQ6bgEAACAffsAfgTGReoB i30MR4l9DIA/Xg+FpwAAAIvHjXgB6ZkAAACD+yt1Iv9N9HUMg33gAHQGxkXxAesR/3UI/0X8 6GgFAACL2FmJXeyD+zAPhUUCAAD/dQj/RfzoTgUAAIvYWYD7eIld7HQvgPtYdCqD/njHReQB AAAAdAhqb17pFgIAAP91CP9N/FPoOAUAAFlZajBb6f0BAAD/dQj/RfzoCQUAAFmL2Ild7Gp4 68+AffsAfgTGReoBvzAsQQCATej/aiCNRZxqAFDo7Nr//4PEDIN9xHt1DoA/XXUJsl1HxkWn IOsDilXLigc8XXRfRzwtdUGE0nQ9ig+A+V10Nkc60XMEisHrBIrCitE60HchD7bSD7bwK/JG i8qLwoPhB7MBwegD0uONRAWcCBhCTnXoMtLrtA+2yIrQi8GD4QezAcHoA9LjjUQFnAgY65uA PwAPhAEEAACDfcR7dQOJfQyLfQiLddT/TfxX/3XsiXXQ6FMEAABZWYN94AB0DotF9P9N9IXA D4ScAAAA/0X8V+gaBAAAg/j/WYlF7HR+i8hqAYPhB1oPvl3o0+KLyMH5Aw++TA2cM8uF0XRg gH3yAHVSgH3qAHRBiw0QKkEAiEXID7bA9kRBAYB0Df9F/FfoywMAAFmIRcn/NRwsQQCNRchQ jUXCUOiqIAAAZotFwoPEDGaJBkZG6wOIBkaJddTpZP////9F0Olc/////038V1DoowMAAFlZ OXXQD4QoAwAAgH3yAA+FfwIAAP9FzIN9xGMPhHICAACAfeoAi0XUdAlmgyAA6WACAACAIADp WAIAAMZF8wGLXeyD+y11BsZF6QHrBYP7K3Ui/030dQyDfeAAdAbGRfEB6xH/dQj/RfzoGgMA AFmL2Ild7IN90AAPhA8BAACAffEAD4XjAAAAg/54dU+DPRwsQQABfg9ogAAAAFPoVO7//1lZ 6w2hECpBAIoEWCWAAAAAhcAPhKMAAACLRdiLVdxqBFnozSAAAFOJRdiJVdzofQIAAIvYWYld 7OtTgz0cLEEAAX4MagRT6Aju//9ZWesLoRAqQQCKBFiD4ASFwHRdg/5vdRWD+zh9U4tF2ItV 3GoDWeh9IAAA6w9qAGoK/3Xc/3XY6CwgAACJRdiJVdz/ReSNQ9CZAUXYEVXcg33gAHQF/030 dCT/dQj/RfzoNgIAAIvYWYld7Okr/////3UI/038U+g5AgAAWVmAfekAD4TcAAAAi0XYi03c 99iD0QCJRdj32YlN3OnEAAAAgH3xAA+FsgAAAIP+eHQ/g/5wdDqDPRwsQQABfgxqBFPoQ+3/ /1lZ6wuhECpBAIoEWIPgBIXAdHaD/m91CoP7OH1swecD6z+NPL/R5+s4gz0cLEEAAX4PaIAA AABT6Abt//9ZWesNoRAqQQCKBFglgAAAAIXAdDdTwecE6EQBAACL2FmJXez/ReSDfeAAjXwf 0HQF/030dCT/dQj/RfzoWAEAAIvYWYld7Olc/////3UI/038U+hbAQAAWVmAfekAdAL334P+ RnUEg2XkAIN95AAPhM4AAACAffIAdSn/RcyDfdAAdBCLRdSLTdiJCItN3IlIBOsQgH3zAItF 1HQEiTjrA2aJOP5F6/9FDIt1DOtC/0X8V+jhAAAAi9hZD7YGRjvDiV3siXUMdVWLDRAqQQAP tsP2REEBgHQY/0X8V+i3AAAAWQ+2DkY7yIl1DHU+/038g33s/3UQgD4ldU2LRQyAeAFudUSL 8IoGhMAPhVb2///rMP91CP9N/P917OsF/038V1PoiwAAAFlZ6xf/TfxXUOh9AAAA/038V1Po cwAAAIPEEIN97P91EYtFzIXAdQ04Ret1CIPI/+sDi0XMX15bycODPRwsQQABVn4Qi3QkCGoE VuiO6///WVnrD4t0JAihECpBAIoEcIPgBIXAdQaD5t+D7geLxl7Di1QkBP9KBHgJiwoPtgFB iQrDUugUHgAAWcODfCQE/3QP/3QkCP90JAjo1x4AAFlZw1aLdCQIV/90JBD/Bui+////i/hX 6D7i//9ZhcBZdeeLx19ew8zMzMzMzMzMjUL/W8ONpCQAAAAAjWQkADPAikQkCFOL2MHgCItU JAj3wgMAAAB0E4oKQjjZdNGEyXRR98IDAAAAde0L2FeLw8HjEFYL2IsKv//+/n6LwYv3M8sD 8AP5g/H/g/D/M88zxoPCBIHhAAEBgXUcJQABAYF00yUAAQEBdQiB5gAAAIB1xF5fWzPAw4tC /DjYdDaEwHTvONx0J4TkdOfB6BA42HQVhMB03DjcdAaE5HTU65ZeX41C/1vDjUL+Xl9bw41C /V5fW8ONQvxeX1vDoTRMSQCFwHQC/9BoFPBAAGgI8EAA6M4AAABoBPBAAGgA8EAA6L8AAACD xBDDagBqAP90JAzoFQAAAIPEDMNqAGoB/3QkDOgEAAAAg8QMw1dqAV85PZw5SQB1Ef90JAj/ FazQQABQ/xUo0UAAg3wkDABTi1wkFIk9mDlJAIgdlDlJAHU8oTBMSQCFwHQiiw0sTEkAVo1x /DvwchOLBoXAdAL/0IPuBDs1MExJAHPtXmgg8EAAaBjwQADoKgAAAFlZaCjwQABoJPBAAOgZ AAAAWVmF21t1EP90JAiJPZw5SQD/FXzRQABfw1aLdCQIO3QkDHMNiwaFwHQC/9CDxgTr7V7D VYvsU/91COg1AQAAhcBZD4QgAQAAi1gIhdsPhBUBAACD+wV1DINgCABqAVjpDQEAAIP7AQ+E 9gAAAIsNoDlJAIlNCItNDIkNoDlJAItIBIP5CA+FyAAAAIsNuCxBAIsVvCxBAAPRVjvKfRWN NEkr0Y00tUgsQQCDJgCDxgxKdfeLAIs1xCxBAD2OAADAdQzHBcQsQQCDAAAA63A9kAAAwHUM xwXELEEAgQAAAOtdPZEAAMB1DMcFxCxBAIQAAADrSj2TAADAdQzHBcQsQQCFAAAA6zc9jQAA wHUMxwXELEEAggAAAOskPY8AAMB1DMcFxCxBAIYAAADrET2SAADAdQrHBcQsQQCKAAAA/zXE LEEAagj/01mJNcQsQQBZXusIg2AIAFH/01mLRQijoDlJAIPI/+sJ/3UM/xWY0UAAW13Di1Qk BIsNwCxBADkVQCxBAFa4QCxBAHQVjTRJjTS1QCxBAIPADDvGcwQ5EHX1jQxJXo0MjUAsQQA7 wXMEORB0AjPAw4M9KExJAAB1Bei75P//Vos1aE5JAIoGPCJ1JYpGAUY8InQVhMB0EQ+2wFDo lBsAAIXAWXTmRuvjgD4idQ1G6wo8IHYGRoA+IHf6igaEwHQEPCB26YvGXsNTM9s5HShMSQBW V3UF6F/k//+LNSA5SQAz/4oGOsN0Ejw9dAFHVugr0///WY10BgHr6I0EvQQAAABQ6Orw//+L 8Fk784k1fDlJAHUIagnoEeD//1mLPSA5SQA4H3Q5VVfo8dL//4voWUWAPz10IlXotfD//zvD WYkGdQhqCeji3///WVf/Nujb0f//WYPGBFkD/Tgfdcld/zUgOUkA6Fjw//9ZiR0gOUkAiR5f XscFJExJAAEAAABbw1WL7FFRUzPbOR0oTEkAVld1Beih4///vqQ5SQBoBAEAAFZT/xUU0UAA oWhOSQCJNYw5SQCL/jgYdAKL+I1F+FCNRfxQU1NX6E0AAACLRfiLTfyNBIhQ6BXw//+L8IPE GDvzdQhqCOhA3///WY1F+FCNRfxQi0X8jQSGUFZX6BcAAACLRfyDxBRIiTV0OUkAX16jcDlJ AFvJw1WL7ItNGItFFFNWgyEAi3UQV4t9DMcAAQAAAItFCIX/dAiJN4PHBIl9DIA4InVEilAB QID6InQphNJ0JQ+20vaCYU1JAAR0DP8BhfZ0BooQiBZGQP8BhfZ01YoQiBZG687/AYX2dASA JgBGgDgidUZA60P/AYX2dAWKEIgWRooQQA+22vaDYU1JAAR0DP8BhfZ0BYoYiB5GQID6IHQJ hNJ0CYD6CXXMhNJ1A0jrCIX2dASAZv8Ag2UYAIA4AA+E4AAAAIoQgPogdAWA+gl1A0Dr8YA4 AA+EyAAAAIX/dAiJN4PHBIl9DItVFP8Cx0UIAQAAADPbgDhcdQRAQ+v3gDgidSz2wwF1JTP/ OX0YdA2AeAEijVABdQSLwusDiX0Ii30MM9I5VRgPlMKJVRjR64vTS4XSdA5DhfZ0BMYGXEb/ AUt184oQhNJ0SoN9GAB1CoD6IHQ/gPoJdDqDfQgAdC6F9nQZD7ba9oNhTUkABHQGiBZGQP8B ihCIFkbrDw+20vaCYU1JAAR0A0D/Af8BQOlY////hfZ0BIAmAEb/AekX////hf90A4MnAItF FF9eW/8AXcNRUaGoOkkAU1WLLajRQABWVzPbM/Yz/zvDdTP/1YvwO/N0DMcFqDpJAAEAAADr KP8VpNFAAIv4O/sPhOoAAADHBag6SQACAAAA6Y8AAACD+AEPhYEAAAA783UM/9WL8DvzD4TC AAAAZjkei8Z0DkBAZjkYdflAQGY5GHXyK8aLPaDQQADR+FNTQFNTUFZTU4lEJDT/14voO+t0 MlXogu3//zvDWYlEJBB0I1NTVVD/dCQkVlNT/9eFwHUO/3QkEOgw7f//WYlcJBCLXCQQVv8V oNFAAIvD61OD+AJ1TDv7dQz/FaTRQACL+Dv7dDw4H4vHdApAOBh1+0A4GHX2K8dAi+hV6Bvt //+L8Fk783UEM/brC1VXVuj10v//g8QMV/8VnNFAAIvG6wIzwF9eXVtZWcOD7ERTVVZXaAAB AADo4Oz//4vwWYX2dQhqG+gN3P//WYk1IEtJAMcFIExJACAAAACNhgABAAA78HMagGYEAIMO /8ZGBQqhIEtJAIPGCAUAAQAA6+KNRCQQUP8VeNFAAGaDfCRCAA+ExQAAAItEJESFwA+EuQAA AIswjWgEuAAIAAA78I0cLnwCi/A5NSBMSQB9Ur8kS0kAaAABAADoUOz//4XAWXQ4gwUgTEkA IIkHjYgAAQAAO8FzGIBgBACDCP/GQAUKiw+DwAiBwQABAADr5IPHBDk1IExJAHy76waLNSBM SQAz/4X2fkaLA4P4/3Q2ik0A9sEBdC72wQh1C1D/FWzRQACFwHQei8eLz8H4BYPhH4sEhSBL SQCNBMiLC4kIik0AiEgER0WDwwQ7/ny6M9uhIEtJAIM82P+NNNh1TYXbxkYEgXUFavZY6wqL w0j32BvAg8D1UP8VcNFAAIv4g///dBdX/xVs0UAAhcB0DCX/AAAAiT6D+AJ1BoBOBEDrD4P4 A3UKgE4ECOsEgE4EgEOD+wN8m/81IExJAP8VjNFAAF9eXVuDxETDM8BqADlEJAhoABAAAA+U wFD/FWTRQACFwKMES0kAdBXogwoAAIXAdQ//NQRLSQD/FWjRQAAzwMNqAVjDzMzMVYvsU1ZX VWoAagBoJKtAAP91COieHAAAXV9eW4vlXcOLTCQE90EEBgAAALgBAAAAdA+LRCQIi1QkEIkC uAMAAADDU1ZXi0QkEFBq/mgsq0AAZP81AAAAAGSJJQAAAACLRCQgi1gIi3AMg/7/dC47dCQk dCiNNHaLDLOJTCQIiUgMg3yzBAB1EmgBAQAAi0SzCOhAAAAA/1SzCOvDZI8FAAAAAIPEDF9e W8MzwGSLDQAAAACBeQQsq0AAdRCLUQyLUgw5UQh1BbgBAAAAw1NRu9QsQQDrClNRu9QsQQCL TQiJSwiJQwSJawxZW8IEAMzMVkMyMFhDMDBVi+yD7AhTVldV/ItdDItFCPdABAYAAAAPhYIA AACJRfiLRRCJRfyNRfiJQ/yLcwyLewiD/v90YY0MdoN8jwQAdEVWVY1rEP9UjwRdXotdDAvA dDN4PIt7CFPoqf7//4PEBI1rEFZT6N7+//+DxAiNDHZqAYtEjwjoYf///4sEj4lDDP9UjwiL ewiNDHaLNI/robgAAAAA6xy4AQAAAOsVVY1rEGr/U+ie/v//g8QIXbgBAAAAXV9eW4vlXcNV i0wkCIspi0EcUItBGFDoef7//4PECF3CBAChKDlJAIP4AXQNhcB1KoM9FClBAAF1IWj8AAAA 6BgAAAChrDpJAFmFwHQC/9Bo/wAAAOgCAAAAWcNVi+yB7KQBAACLVQgzybjoLEEAOxB0C4PA CEE9eC1BAHzxVovxweYDO5boLEEAD4UcAQAAoSg5SQCD+AEPhOgAAACFwHUNgz0UKUEAAQ+E 1wAAAIH6/AAAAA+E8QAAAI2FXP7//2gEAQAAUGoA/xUU0UAAhcB1E42FXP7//2i81UAAUOiz yf//WVmNhVz+//9XUI29XP7//+iOyv//QFmD+Dx2KY2FXP7//1Doe8r//4v4jYVc/v//g+g7 agMD+Gi41UAAV+jhAQAAg8QQjYVg////aJzVQABQ6F3J//+NhWD///9XUOhgyf//jYVg//// aJjVQABQ6E/J////tuwsQQCNhWD///9Q6D3J//9oECABAI2FYP///2hw1UAAUOhfEgAAg8Qs X+smjUUIjbbsLEEAagBQ/zbo7sn//1lQ/zZq9P8VcNFAAFD/FWzQQABeycNVi+xq/2jY1UAA aASsQABkoQAAAABQZIklAAAAAIPsGFNWV4ll6KGwOkkAM9s7w3U+jUXkUGoBXlZoUNJAAFb/ FVTRQACFwHQEi8brHY1F5FBWaEzSQABWU/8VWNFAAIXAD4TOAAAAagJYo7A6SQCD+AJ1JItF HDvDdQWhPDlJAP91FP91EP91DP91CFD/FVjRQADpnwAAAIP4AQ+FlAAAADldGHUIoUw5SQCJ RRhTU/91EP91DItFIPfYG8CD4AhAUP91GP8VeNBAAIlF4DvDdGOJXfyNPACLx4PAAyT86BTQ //+JZeiL9Il13FdTVuiUx///g8QM6wtqAVjDi2XoM9sz9oNN/P8783Qp/3XgVv91EP91DGoB /3UY/xV40EAAO8N0EP91FFBW/3UI/xVU0UAA6wIzwI1lzItN8GSJDQAAAABfXlvJw8zMzMzM zMzMzMzMzMzMzItMJAxXhcl0elZTi9mLdCQU98YDAAAAi3wkEHUHwekCdW/rIYoGRogHR0l0 JYTAdCn3xgMAAAB164vZwekCdVGD4wN0DYoGRogHR4TAdC9LdfOLRCQQW15fw/fHAwAAAHQS iAdHSQ+EigAAAPfHAwAAAHXui9nB6QJ1bIgHR0t1+ltei0QkCF/DiReDxwRJdK+6//7+fosG A9CD8P8zwosWg8YEqQABAYF03oTSdCyE9nQe98IAAP8AdAz3wgAAAP91xokX6xiB4v//AACJ F+sOgeL/AAAAiRfrBDPSiReDxwQzwEl0CjPAiQeDxwRJdfiD4wN1hYtEJBBbXl/Di0QkBFM7 BSBMSQBWV3Nzi8iL8MH5BYPmH408jSBLSQDB5gOLD/ZEMQQBdFZQ6BIRAACD+P9ZdQzHBVQ5 SQAJAAAA60//dCQYagD/dCQcUP8V5NBAAIvYg/v/dQj/FeDQQADrAjPAhcB0CVDo8w8AAFnr IIsHgGQwBP2NRDAEi8PrFIMlWDlJAADHBVQ5SQAJAAAAg8j/X15bw1WL7IHsFAQAAItNCFM7 DSBMSQBWVw+DeQEAAIvBi/HB+AWD5h+NHIUgS0kAweYDiwOKRDAEqAEPhFcBAAAz/zl9EIl9 +Il98HUHM8DpVwEAAKggdAxqAldR6Aj///+DxAyLAwPG9kAEgA+EwQAAAItFDDl9EIlF/Il9 CA+G5wAAAI2F7Pv//4tN/CtNDDtNEHMpi038/0X8igmA+Qp1B/9F8MYADUCICECLyI2V7Pv/ /yvKgfkABAAAfMyL+I2F7Pv//yv4jUX0agBQjYXs+///V1CLA/80MP8VbNBAAIXAdEOLRfQB Rfg7x3wLi0X8K0UMO0UQcooz/4tF+DvHD4WLAAAAOX0IdF9qBVg5RQh1TMcFVDlJAAkAAACj WDlJAOmAAAAA/xXg0EAAiUUI68eNTfRXUf91EP91DP8w/xVs0EAAhcB0C4tF9Il9CIlF+Oun /xXg0EAAiUUI65z/dQjoZA4AAFnrPYsD9kQwBEB0DItFDIA4Gg+Ezf7//8cFVDlJABwAAACJ PVg5SQDrFitF8OsUgyVYOUkAAMcFVDlJAAkAAACDyP9fXlvJw/8FtDpJAGgAEAAA6P7i//9Z i0wkBIXAiUEIdA2DSQwIx0EYABAAAOsRg0kMBI1BFIlBCMdBGAIAAACLQQiDYQQAiQHDi0Qk BDsFIExJAHIDM8DDi8iD4B/B+QWLDI0gS0kAikTBBIPgQMOhAEtJAFZqFIXAXnUHuAACAADr BjvGfQeLxqMAS0kAagRQ6KkOAABZo+Q6SQCFwFl1IWoEVok1AEtJAOiQDgAAWaPkOkkAhcBZ dQhqGuiN0f//WTPJuIAtQQCLFeQ6SQCJBBGDwCCDwQQ9ADBBAHzqM9K5kC1BAIvCi/LB+AWD 5h+LBIUgS0kAiwTwg/j/dASFwHUDgwn/g8EgQoH58C1BAHzUXsPokg8AAIA9lDlJAAB0BemV DgAAw1WL7ItFCIXAdQJdw4M9PDlJAAB1EmaLTQxmgfn/AHc5agGICFhdw41NCINlCABRagD/ NRwsQQBQjUUMagFQaCACAAD/NUw5SQD/FaDQQACFwHQGg30IAHQNxwVUOUkAKgAAAIPI/13D U1aLRCQYC8B1GItMJBSLRCQQM9L38YvYi0QkDPfxi9PrQYvIi1wkFItUJBCLRCQM0enR29Hq 0dgLyXX09/OL8PdkJBiLyItEJBT35gPRcg47VCQQdwhyBztEJAx2AU4z0ovGXlvCEADMzMzM zMzMzFOLRCQUC8B1GItMJBCLRCQMM9L38YtEJAj38YvCM9LrUIvIi1wkEItUJAyLRCQI0enR 29Hq0dgLyXX09/OLyPdkJBSR92QkEAPRcg47VCQMdwhyDjtEJAh2CCtEJBAbVCQUK0QkCBtU JAz32vfYg9oAW8IQAGhAAQAAagD/NQRLSQD/FZTRQACFwKPgOkkAdQHDgyXYOkkAAIMl3DpJ AABqAaPUOkkAxwXMOkkAEAAAAFjDodw6SQCNDICh4DpJAI0MiDvBcxSLVCQEK1AMgfoAABAA cgeDwBTr6DPAw1WL7IPsFItVDItNCFNWi0EQi/IrcQyLWvyDwvxXwe4Pi86LevxpyQQCAABL iX38jYwBRAEAAIld9IlN8IsME/bBAYlN+HV/wfkEaj9JX4lNDDvPdgOJfQyLTBMEO0wTCHVI i00Mg/kgcxy/AAAAgNPvjUwBBPfXIXywRP4JdSuLTQghOeskg8HgvwAAAIDT74tNDI1MAQT3 1yG8sMQAAAD+CXUGi00IIXkEi0wTCIt8EwSJeQSLTBMEi3wTCANd+Il5CIld9Iv7wf8ET4P/ P3YDaj9fi038g+EBiU3sD4WgAAAAK1X8i038wfkEaj+JVfhJWjvKiU0MdgWJVQyLygNd/Iv7 iV30wf8ETzv6dgKL+jvPdGuLTfiLUQQ7UQh1SItNDIP5IHMcugAAAIDT6o1MAQT30iFUsET+ CXUri00IIRHrJIPB4LoAAACA0+qLTQyNTAEE99IhlLDEAAAA/gl1BotNCCFRBItN+ItRCItJ BIlKBItN+ItRBItJCIlKCItV+IN97AB1CTl9DA+EiQAAAItN8I0M+YtJBIlKBItN8I0M+YlK CIlRBItKBIlRCItKBDtKCHVjikwHBIP/IIhND/7BiEwHBHMlgH0PAHUOuwAAAICLz9Pri00I CRm7AAAAgIvP0+uNRLBECRjrKYB9DwB1EI1P4LsAAACA0+uLTQgJWQSNT+C/AAAAgNPvjYSw xAAAAAk4i130i0XwiRqJXBP8/wgPhfoAAACh2DpJAIXAD4TfAAAAiw3QOkkAiz1g0UAAweEP A0gMuwCAAABoAEAAAFNR/9eLDdA6SQCh2DpJALoAAACA0+oJUAih2DpJAIsN0DpJAItAEIOk iMQAAAAAodg6SQCLQBD+SEOh2DpJAItIEIB5QwB1CYNgBP6h2DpJAIN4CP91bFNqAP9wDP/X odg6SQD/cBBqAP81BEtJAP8VkNFAAKHcOkkAixXgOkkAjQSAweACi8ih2DpJACvIjUwR7FGN SBRRUOgPx///i0UIg8QM/w3cOkkAOwXYOkkAdgOD6BSLDeA6SQCJDdQ6SQDrA4tFCKPYOkkA iTXQOkkAX15bycNVi+yD7BSh3DpJAIsV4DpJAFNWjQSAV408gotFCIl9/I1IF4Ph8IlN8MH5 BEmD+SB9DoPO/9Pug034/4l19OsQg8Hgg8j/M/bT6Il19IlF+KHUOkkAi9g734ldCHMZi0sE izsjTfgj/gvPdQuDwxQ7XfyJXQhy5ztd/HV5i9o72IldCHMVi0sEizsjTfgj/gvPdQWDwxTr 5jvYdVk7XfxzEYN7CAB1CIPDFIldCOvtO138dSaL2jvYiV0Icw2DewgAdQWDwxTr7jvYdQ7o OAIAAIvYhduJXQh0FFPo2gIAAFmLSxCJAYtDEIM4/3UHM8DpDwIAAIkd1DpJAItDEIsQg/r/ iVX8dBSLjJDEAAAAi3yQRCNN+CP+C891N4uQxAAAAItwRCNV+CN19INl/ACNSEQL1ot19HUX i5GEAAAA/0X8I1X4g8EEi/4jOQvXdOmLVfyLyjP/ackEAgAAjYwBRAEAAIlN9ItMkEQjznUN i4yQxAAAAGogI034X4XJfAXR4Ufr94tN9ItU+QSLCitN8IvxiU34wf4EToP+P34Daj9eO/cP hA0BAACLSgQ7Sgh1YYP/IH0ruwAAAICLz9Pri038jXw4BPfTiV3sI1yIRIlciET+D3U4i10I i03sIQvrMY1P4LsAAACA0+uLTfyNfDgEjYyIxAAAAPfTIRn+D4ld7HULi10Ii03sIUsE6wOL XQiLSgiLegSDffgAiXkEi0oEi3oIiXkID4SUAAAAi030i3zxBI0M8Yl6BIlKCIlRBItKBIlR CItKBDtKCHVkikwGBIP+IIhNC30p/sGAfQsAiEwGBHULvwAAAICLztPvCTu/AAAAgIvO0++L TfwJfIhE6y/+wYB9CwCITAYEdQ2NTuC/AAAAgNPvCXsEi038jbyIxAAAAI1O4L4AAACA0+4J N4tN+IXJdAuJColMEfzrA4tN+It18APRjU4BiQqJTDL8i3X0iw6FyY15AYk+dRo7Hdg6SQB1 EotN/DsN0DpJAHUHgyXYOkkAAItN/IkIjUIEX15bycOh3DpJAIsNzDpJAFZXM/87wXUwjUSJ UMHgAlD/NeA6SQBX/zUES0kA/xVM0UAAO8d0YYMFzDpJABCj4DpJAKHcOkkAiw3gOkkAaMRB AABqCI0EgP81BEtJAI00gf8VlNFAADvHiUYQdCpqBGgAIAAAaAAAEABX/xVQ0UAAO8eJRgx1 FP92EFf/NQRLSQD/FZDRQAAzwOsXg04I/4k+iX4E/wXcOkkAi0YQgwj/i8ZfXsNVi+xRi00I U1ZXi3EQi0EIM9uFwHwF0eBD6/eLw2o/acAEAgAAWo2EMEQBAACJRfyJQAiJQASDwAhKdfSL +2oEwecPA3kMaAAQAABoAIAAAFf/FVDRQACFwHUIg8j/6ZMAAACNlwBwAAA7+nc8jUcQg0j4 /4OI7A8AAP+NiPwPAADHQPzwDwAAiQiNiPzv//+JSATHgOgPAADwDwAABQAQAACNSPA7ynbH i0X8jU8MBfgBAABqAV+JSASJQQiNSgyJSAiJQQSDZJ5EAIm8nsQAAACKRkOKyP7BhMCLRQiI TkN1Awl4BLoAAACAi8vT6vfSIVAIi8NfXlvJw6G8OkkAhcB0D/90JAT/0IXAWXQEagFYwzPA w1WL7FNWi3UMM9s783QVOV0QdBCKBjrDdRCLRQg7w3QDZokYM8BeW13DOR08OUkAdROLTQg7 y3QHZg+2wGaJAWoBWOvhiw0QKkEAD7bA9kRBAYB0TaEcLEEAg/gBfio5RRB8LzPJOV0ID5XB Uf91CFBWagn/NUw5SQD/FXjQQACFwKEcLEEAdZ05RRByBTheAXWTxwVUOUkAKgAAAIPI/+uE M8A5XQgPlcBQ/3UIagFWagn/NUw5SQD/FXjQQACFwA+Fef///+vKzMzMzMzMzMzMzMzMzMzM i0QkCItMJBALyItMJAx1CYtEJAT34cIQAFP34YvYi0QkCPdkJBQD2ItEJAj34QPTW8IQAMzM zMzMzMzMzMzMzID5QHMVgPkgcwYPpcLT4MOL0DPAgOEf0+LDM8Az0sNWi3QkCItGDKiDD4TE AAAAqEAPhbwAAACoAnQKDCCJRgzprgAAAAwBZqkMAYlGDHUJVui/8///WesFi0YIiQb/dhj/ dgj/dhDozgQAAIPEDIlGBIXAdGyD+P90Z4tWDPbCgnU0i04QV4P5/3QUi/nB/wWD4R+LPL0g S0kAjTzP6wW/yCxBAIpPBF+A4YKA+YJ1BoDOIIlWDIF+GAACAAB1FItODPbBCHQM9sUEdQfH RhgAEAAAiw5IiUYED7YBQYkOXsP32BvAg+AQg8AQCUYMg2YEAIPI/17DU4tcJAiD+/9WdEGL dCQQi0YMqAF1CKiAdDKoAnUug34IAHUHVujz8v//WYsGO0YIdQmDfgQAdRRAiQb2RgxAdBH/ DosGOBh0D0CJBoPI/15bw/8OiwaIGItGDP9GBCTvDAGJRgyLwyX/AAAA6+FqBGoA/3QkDOgE AAAAg8QMww+2RCQEikwkDISIYU1JAHUcg3wkCAB0Dg+3BEUaKkEAI0QkCOsCM8CFwHUBw2oB WMNTM9s5HcA6SQBWV3VCaBTWQAD/FfTQQACL+Dv7dGeLNTjRQABoCNZAAFf/1oXAo8A6SQB0 UGj41UAAV//WaOTVQABXo8Q6SQD/1qPIOkkAocQ6SQCFwHQW/9CL2IXbdA6hyDpJAIXAdAVT /9CL2P90JBj/dCQY/3QkGFP/FcA6SQBfXlvDM8Dr+ItMJAQz0okNWDlJALgwMEEAOwh0IIPA CEI9mDFBAHzxg/kTch2D+SR3GMcFVDlJAA0AAADDiwTVNDBBAKNUOUkAw4H5vAAAAHISgfnK AAAAxwVUOUkACAAAAHYKxwVUOUkAFgAAAMOLTCQEVjsNIExJAFdzVYvBi/HB+AWD5h+NPIUg S0kAweYDiwcDxvZABAF0N4M4/3Qygz0UKUEAAXUfM8AryHQQSXQISXUTUGr06whQavXrA1Bq 9v8VSNFAAIsHgwww/zPA6xSDJVg5SQAAxwVUOUkACQAAAIPI/19ew4tEJAQ7BSBMSQBzHIvI g+AfwfkFiwyNIEtJAPZEwQQBjQTBdAOLAMODJVg5SQAAxwVUOUkACQAAAIPI/8NTVot0JAxX D690JBSD/uCL3ncNhfZ1A2oBXoPGD4Pm8DP/g/7gdyo7HSAwQQB3DVPolfb//4v4WYX/dStW agj/NQRLSQD/FZTRQACL+IX/dSKDPbg6SQAAdBlW6B/7//+FwFl0FOu5U2oAV+hBtP//g8QM i8dfXlvDM8Dr+FZXagMz/145NQBLSQB+RKHkOkkAiwSwhcB0L/ZADIN0DVDoPQMAAIP4/1l0 AUeD/hR8F6HkOkkA/zSw6OjS//+h5DpJAFmDJLAARjs1AEtJAHy8i8dfXsNWi3QkCIX2dQlW 6JEAAABZXsNW6CMAAACFwFl0BYPI/17D9kYNQHQP/3YQ6DIDAAD32FleG8DDM8Bew1NWi3Qk DDPbV4tGDIvIg+EDgPkCdTdmqQgBdDGLRgiLPiv4hf9+JldQ/3YQ6Njt//+DxAw7x3UOi0YM qIB0DiT9iUYM6weDTgwgg8v/i0YIg2YEAIkGX4vDXlvDagHoAgAAAFnDU1ZXM/Yz2zP/OTUA S0kAfk2h5DpJAIsEsIXAdDiLSAz2wYN0MIN8JBABdQ9Q6C7///+D+P9ZdB1D6xqDfCQQAHUT 9sECdA5Q6BP///+D+P9ZdQIL+EY7NQBLSQB8s4N8JBABi8N0AovHX15bw2oC6CbB//9Zw1WL 7IPsDFNWi3UIVzs1IExJAA+DxQEAAIvGg+YfwfgFweYDjRyFIEtJAIsEhSBLSQADxopQBPbC AQ+EngEAAINl+ACLfQyDfRAAi890Z/bCAnVi9sJIdB2KQAU8CnQW/00QiAeLA41PAcdF+AEA AADGRDAFCo1F9GoAUIsD/3UQUf80MP8VcNBAAIXAdTr/FeDQQABqBVk7wXUVxwVUOUkACQAA AIkNWDlJAOk+AQAAg/htdQczwOk1AQAAUOg1/P//WekmAQAAiwOLVfQBVfiNTDAEikQwBKiA D4T4AAAAhdJ0CYA/CnUEDATrAiT7iAGLRQyLTfiJRRADyDvBiU34D4PLAAAAi0UQigA8Gg+E rgAAADwNdAuIB0f/RRDpkQAAAEk5TRBzGItFEECAOAp1BoNFEALrXsYHDUeJRRDrc41F9GoA UP9FEI1F/2oBUIsD/zQw/xVw0EAAhcB1Cv8V4NBAAIXAdUeDffQAdEGLA/ZEMARIdBOKRf88 CnQXxgcNiwtHiEQxBespO30MdQuAff8KdQXGBwrrGGoBav//dQjo7er//4PEDIB9/wp0BMYH DUeLTfg5TRAPgkf////rEIsDjXQwBIoGqEB1BAwCiAYrfQyJffiLRfjrFIMlWDlJAADHBVQ5 SQAJAAAAg8j/X15bycNWi3QkCFeDz/+LRgyoQHQFg8j/6zqog3Q0VugQ/f//Vov46DkBAAD/ dhDofgAAAIPEDIXAfQWDz//rEotGHIXAdAtQ6HzP//+DZhwAWYvHg2YMAF9ew4tEJAQ7BSBM SQBzPYvIi9DB+QWD4h+LDI0gS0kA9kTRBAF0JVDoYvv//1lQ/xVE0UAAhcB1CP8V4NBAAOsC M8CFwHQSo1g5SQDHBVQ5SQAJAAAAg8j/w1NVVleLfCQUOz0gTEkAD4OGAAAAi8eL98H4BYPm H40chSBLSQDB5gOLA/ZEMAQBdGlX6P76//+D+P9ZdDyD/wF0BYP/AnUWagLo5/r//2oBi+jo 3vr//1k7xVl0HFfo0vr//1lQ/xUk0UAAhcB1Cv8V4NBAAIvo6wIz7VfoOvr//4sDWYBkMAQA he10CVXowfn//1nrFTPA6xSDJVg5SQAAxwVUOUkACQAAAIPI/19eXVvDVot0JAiLRgyog3Qd qAh0Gf92COhMzv//ZoFmDPf7M8BZiQaJRgiJRgRew8zMzMzM/yW40UAA/yW00UAA/yWw0UAA /yVc0UAAVYvsUaE8OUkAUzPbO8OJXfx1IYtFCIvQOBh0f4oKgPlhfAqA+Xp/BYDpIIgKQjga derrZ1ZXagFTU1Nq/74AAgAA/3UIVlDo7cH//4v4g8QgO/t0OFfo8M3//zvDWYlF/HQqagFT V1Bq//91CFb/NTw5SQDowMH//4PEIIXAdA3/dfz/dQjo/a7//1lZ/3X86IfN//+LRQhZX15b ycPMzMzMzMzMzMzMVYvsV1ZTi00QC8kPhJUAAACLdQiLfQyNBTQ5SQCDeAgAdUO3QbNatiCN SQCKJgrkigd0IQrAdB1GRzj8cgY43HcCAuY4+HIGONh3AgLGOMR1CUl11zPJOMR0S7n///// ckT32etAM8Az24v/igYLwIofdCML23QfRkdRUFPo3LH//4vYg8QE6NKx//+DxARZO8N1CUl1 1TPJO8N0Cbn/////cgL32YvBW15fycPMzMxVi+xXVlOLdQyLfQiNBTQ5SQCDeAgAdTuw/4v/ CsB0LooGRoonRzjEdPIsQTwaGsmA4SACwQRBhuAsQTwaGsmA4SACwQRBOOB00hrAHP8PvsDr NLj/AAAAM9uL/wrAdCeKBkaKH0c42HTyUFPoPbH//4vYg8QE6DOx//+DxAQ4w3TaG8CD2P9b Xl/Jw1WL7FGhPDlJAFMz2zvDiV38dSGLRQiL0DgYdH+KCoD5QXwKgPlafwWAwSCICkI4GnXq 62dWV2oBU1NTav++AAEAAP91CFZQ6AnA//+L+IPEIDv7dDhX6AzM//87w1mJRfx0KmoBU1dQ av//dQhW/zU8OUkA6Ny///+DxCCFwHQN/3X8/3UI6Bmt//9ZWf91/Oijy///i0UIWV9eW8nD AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAJbcAACo3AAA2N0AAMDdAACe3QAAit0AALDdAABk3QAAUN0AAHrdAAAe3QAAEt0AADrd AADq3AAA2twAAAjdAABu3AAAXtwAAITcAAA+3AAAMNwAAEzcAADG3AAAItwAAAAAAAAg2gAA QNoAAFLaAABe2gAAatoAAAraAAA02gAAnNoAALLaAAC+2gAAztoAAODaAADQ2QAAftoAAI7a AAD02QAALtsAAEDbAABW2wAAatsAAILbAACS2wAAotsAALDbAADG2wAA2NsAAPTbAAAE3AAA 3tkAAKTZAADE2QAAtNkAAPDaAAAC2wAAdtkAAHDYAACQ2AAAktkAAITZAAA+2QAAYNkAAFDZ AAD82AAALtkAABjZAADK2AAA7NgAAN7YAACg2AAAttgAAK7YAAAQ2wAAHtsAAH7YAACs3gAA nN4AAA7gAAD+3wAA8N8AAODfAADO3wAAvN8AALDfAACi3wAAlN8AAIbfAAB43wAAaN8AAEbe AABa3gAAbN4AAHreAACG3gAAkN4AAFbfAAC83gAAyN4AANTeAADw3gAACt8AACTfAAA83wAA AAAAAC7eAAAa3gAACt4AAAAAAAA0AACAAwAAgHQAAIAQAACAEwAAgAkAAIAEAACAbwAAgHMA AIAXAACAAAAAAAAAAAAAAAAABQAAAAAAAAAHAAAACQAAAAUAAAACAAAAAgAAAAIAAAACAAAA DAAZAAEAAQACAA4ACgAfAAQAAQADABkACAAPAAIAAgALAAIAAQAGAP////8vhUAAQ4VAAAAA AAAAAAAAAAAAAP////8Ri0AAFYtAAP/////Fi0AAyYtAAAYAAAYAAQAAEAADBgAGAhAERUVF BQUFBQU1MABQAAAAACAoOFBYBwgANzAwV1AHAAAgIAgAAAAACGBoYGBgYAAAcHB4eHh4CAcI AAAHAAgICAAACAAIAAcIAAAAKABuAHUAbABsACkAAAAAAChudWxsKQAAcnVudGltZSBlcnJv ciAAAA0KAABUTE9TUyBlcnJvcg0KAAAAU0lORyBlcnJvcg0KAAAAAERPTUFJTiBlcnJvcg0K AABSNjAyOA0KLSB1bmFibGUgdG8gaW5pdGlhbGl6ZSBoZWFwDQoAAAAAUjYwMjcNCi0gbm90 IGVub3VnaCBzcGFjZSBmb3IgbG93aW8gaW5pdGlhbGl6YXRpb24NCgAAAABSNjAyNg0KLSBu b3QgZW5vdWdoIHNwYWNlIGZvciBzdGRpbyBpbml0aWFsaXphdGlvbg0KAAAAAFI2MDI1DQot IHB1cmUgdmlydHVhbCBmdW5jdGlvbiBjYWxsDQoAAABSNjAyNA0KLSBub3QgZW5vdWdoIHNw YWNlIGZvciBfb25leGl0L2F0ZXhpdCB0YWJsZQ0KAAAAAFI2MDE5DQotIHVuYWJsZSB0byBv cGVuIGNvbnNvbGUgZGV2aWNlDQoAAAAAUjYwMTgNCi0gdW5leHBlY3RlZCBoZWFwIGVycm9y DQoAAAAAUjYwMTcNCi0gdW5leHBlY3RlZCBtdWx0aXRocmVhZCBsb2NrIGVycm9yDQoAAAAA UjYwMTYNCi0gbm90IGVub3VnaCBzcGFjZSBmb3IgdGhyZWFkIGRhdGENCgANCmFibm9ybWFs IHByb2dyYW0gdGVybWluYXRpb24NCgAAAABSNjAwOQ0KLSBub3QgZW5vdWdoIHNwYWNlIGZv ciBlbnZpcm9ubWVudA0KAFI2MDA4DQotIG5vdCBlbm91Z2ggc3BhY2UgZm9yIGFyZ3VtZW50 cw0KAAAAUjYwMDINCi0gZmxvYXRpbmcgcG9pbnQgbm90IGxvYWRlZA0KAAAAAE1pY3Jvc29m dCBWaXN1YWwgQysrIFJ1bnRpbWUgTGlicmFyeQAAAAAKCgAAUnVudGltZSBFcnJvciEKClBy b2dyYW06IAAAAC4uLgA8cHJvZ3JhbSBuYW1lIHVua25vd24+AAAAAAAA/////2GvQABlr0AA R2V0TGFzdEFjdGl2ZVBvcHVwAABHZXRBY3RpdmVXaW5kb3cATWVzc2FnZUJveEEAdXNlcjMy LmRsbAAA6NYAAAAAAAAAAAAAFNwAAGTQAACE1gAAAAAAAAAAAADw3QAAANAAAETYAAAAAAAA AAAAAP7dAADA0QAANNgAAAAAAAAAAAAAPt4AALDRAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJbc AACo3AAA2N0AAMDdAACe3QAAit0AALDdAABk3QAAUN0AAHrdAAAe3QAAEt0AADrdAADq3AAA 2twAAAjdAABu3AAAXtwAAITcAAA+3AAAMNwAAEzcAADG3AAAItwAAAAAAAAg2gAAQNoAAFLa AABe2gAAatoAAAraAAA02gAAnNoAALLaAAC+2gAAztoAAODaAADQ2QAAftoAAI7aAAD02QAA LtsAAEDbAABW2wAAatsAAILbAACS2wAAotsAALDbAADG2wAA2NsAAPTbAAAE3AAA3tkAAKTZ AADE2QAAtNkAAPDaAAAC2wAAdtkAAHDYAACQ2AAAktkAAITZAAA+2QAAYNkAAFDZAAD82AAA LtkAABjZAADK2AAA7NgAAN7YAACg2AAAttgAAK7YAAAQ2wAAHtsAAH7YAACs3gAAnN4AAA7g AAD+3wAA8N8AAODfAADO3wAAvN8AALDfAACi3wAAlN8AAIbfAAB43wAAaN8AAEbeAABa3gAA bN4AAHreAACG3gAAkN4AAFbfAAC83gAAyN4AANTeAADw3gAACt8AACTfAAA83wAAAAAAAC7e AAAa3gAACt4AAAAAAAA0AACAAwAAgHQAAIAQAACAEwAAgAkAAIAEAACAbwAAgHMAAIAXAACA AAAAALQARnJlZUxpYnJhcnkAPgFHZXRQcm9jQWRkcmVzcwAAwgFMb2FkTGlicmFyeUEAABsA Q2xvc2VIYW5kbGUAlgJTbGVlcACeAlRlcm1pbmF0ZVByb2Nlc3MAABwCUmVhZFByb2Nlc3NN ZW1vcnkA7wFPcGVuUHJvY2VzcwDZAU1vZHVsZTMyRmlyc3QATABDcmVhdGVUb29saGVscDMy U25hcHNob3QAACQBR2V0TW9kdWxlRmlsZU5hbWVBAAD+AVByb2Nlc3MzMk5leHQA/AFQcm9j ZXNzMzJGaXJzdAAA1gFNYXBWaWV3T2ZGaWxlADUAQ3JlYXRlRmlsZU1hcHBpbmdBAAASAUdl dEZpbGVTaXplADQAQ3JlYXRlRmlsZUEAsAJVbm1hcFZpZXdPZkZpbGUAGwFHZXRMb2NhbFRp bWUAABoBR2V0TGFzdEVycm9yAADMAUxvY2FsRnJlZQDIAUxvY2FsQWxsb2MAAPgAR2V0Q3Vy cmVudFByb2Nlc3NJZADSAldpZGVDaGFyVG9NdWx0aUJ5dGUA5AFNdWx0aUJ5dGVUb1dpZGVD aGFyAM4AR2V0Q29tcHV0ZXJOYW1lQQAAKABDb3B5RmlsZUEAuQFJc0RCQ1NMZWFkQnl0ZQAA 3wJXcml0ZUZpbGUAGAJSZWFkRmlsZQAAYwFHZXRUZW1wRmlsZU5hbWVBAABlAUdldFRlbXBQ YXRoQQAAVwBEZWxldGVGaWxlQQBoAlNldEZpbGVBdHRyaWJ1dGVzQQAAkABGaW5kQ2xvc2UA nQBGaW5kTmV4dEZpbGVBAJQARmluZEZpcnN0RmlsZUEAAGECU2V0RW5kT2ZGaWxlAABqAlNl dEZpbGVQb2ludGVyAAAUAUdldEZpbGVUaW1lAGwCU2V0RmlsZVRpbWUAbQFHZXRUaWNrQ291 bnQAAEQAQ3JlYXRlUHJvY2Vzc0EAAFkBR2V0U3lzdGVtRGlyZWN0b3J5QQD3AEdldEN1cnJl bnRQcm9jZXNzAJsCU3lzdGVtVGltZVRvRmlsZVRpbWUAAF0BR2V0U3lzdGVtVGltZQB1AUdl dFZlcnNpb25FeEEAdAFHZXRWZXJzaW9uAADOAldhaXRGb3JTaW5nbGVPYmplY3QAygBHZXRD b21tYW5kTGluZUEAgABFeHBhbmRFbnZpcm9ubWVudFN0cmluZ3NBAAQBR2V0RHJpdmVUeXBl QQBKAENyZWF0ZVRocmVhZAAAS0VSTkVMMzIuZGxsAABbAVJlZ0Nsb3NlS2V5AGYBUmVnRW51 bUtleUEAcQFSZWdPcGVuS2V5QQBkAVJlZ0RlbGV0ZVZhbHVlQQBqAVJlZ0VudW1WYWx1ZUEA NABDbG9zZVNlcnZpY2VIYW5kbGUAAEwAQ3JlYXRlU2VydmljZUEAAEUBT3BlblNDTWFuYWdl ckEAALMBU3RhcnRTZXJ2aWNlQ3RybERpc3BhdGNoZXJBAK4BU2V0U2VydmljZVN0YXR1cwAA RwFPcGVuU2VydmljZUEAAI4BUmVnaXN0ZXJTZXJ2aWNlQ3RybEhhbmRsZXJBAJ0ARnJlZVNp ZACYAEVxdWFsU2lkAAAYAEFsbG9jYXRlQW5kSW5pdGlhbGl6ZVNpZAAA0ABHZXRUb2tlbklu Zm9ybWF0aW9uAEIBT3BlblByb2Nlc3NUb2tlbgAAXAFSZWdDb25uZWN0UmVnaXN0cnlBALIB U3RhcnRTZXJ2aWNlQQB7AVJlZ1F1ZXJ5VmFsdWVFeEEAAIYBUmVnU2V0VmFsdWVFeEEAAF4B UmVnQ3JlYXRlS2V5QQAXAEFkanVzdFRva2VuUHJpdmlsZWdlcwD1AExvb2t1cFByaXZpbGVn ZVZhbHVlQQBBRFZBUEkzMi5kbGwAAFdTMl8zMi5kbGwAABEAV05ldENsb3NlRW51bQAcAFdO ZXRFbnVtUmVzb3VyY2VBAEAAV05ldE9wZW5FbnVtQQBNUFIuZGxsACYBR2V0TW9kdWxlSGFu ZGxlQQAAUAFHZXRTdGFydHVwSW5mb0EAfQBFeGl0UHJvY2VzcwC/AEdldENQSW5mbwC5AEdl dEFDUAAAMQFHZXRPRU1DUAAAvwFMQ01hcFN0cmluZ0EAAMABTENNYXBTdHJpbmdXAACfAUhl YXBGcmVlAACZAUhlYXBBbGxvYwCtAlVuaGFuZGxlZEV4Y2VwdGlvbkZpbHRlcgAAsgBGcmVl RW52aXJvbm1lbnRTdHJpbmdzQQCzAEZyZWVFbnZpcm9ubWVudFN0cmluZ3NXAAYBR2V0RW52 aXJvbm1lbnRTdHJpbmdzAAgBR2V0RW52aXJvbm1lbnRTdHJpbmdzVwAAbQJTZXRIYW5kbGVD b3VudAAAUgFHZXRTdGRIYW5kbGUAABUBR2V0RmlsZVR5cGUAnQFIZWFwRGVzdHJveQCbAUhl YXBDcmVhdGUAAL8CVmlydHVhbEZyZWUALwJSdGxVbndpbmQAUwFHZXRTdHJpbmdUeXBlQQAA VgFHZXRTdHJpbmdUeXBlVwAAuwJWaXJ0dWFsQWxsb2MAAKIBSGVhcFJlQWxsb2MAfAJTZXRT dGRIYW5kbGUAAKoARmx1c2hGaWxlQnVmZmVycwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA W4lAAG+zQAAAAAAAAAAAABS0QAAAAAAAAAAAAAAAAAAAAAAAMw1BAEAAAAAgAAAALAAAAC0t AABcAAAAUVVJVA0KAAANCi4NCgAAAERBVEEgDQoASEVMTyAlcw0KAAAAPg0KAE1BSUwgRlJP TTogPAAAAABSQ1BUIFRPOjwAAAAlZAAAIAkNCgAAAAAuLCgpJSRAIWB+IAAtXwAALi4AAC4A AABcKi4qAAAAAFxcAAAAAAAAiRV37zMZmXgQWLjJ8pkAAALJ9s0BCQkJyGh0cFRkdHBUcUR0 fMkoHExwKBxMcMgBDURwcUR0fMlMeCktyBBcAGwgdHBxcFwYyUBsAFjIWGxQTERxRHR8yWxM ZMhodHBUZHRwVHFEdHzJLHQcfFzIaHRwVGR0cFRxRHR8yRh0fMgUTGxoTHBUcUR0fHFoZMkc WEDIEFwAbCB0cHFwXBjJBGwEyGh0cFRkdHBUcUR0fMkYTEBAXMhYbFBMRHFEdHzJQBwEaMgQ XABsIHRwcXBcGMl8HGRMyBRAfWBMCExwcUR0cWAIyRh0ZCx0yBRAfWBMCExwcUR0cWAIyehs eEwALLTEaHRsyHwYeFR4dEBMeHFEdHxxaGTJycnJycnJycnJycnJycnJycnJycnJycnJycnJ ycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJ ycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJ ycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJ ycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJ ycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJ ycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJ ycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJ ycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJ ycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJ ycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJ ycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJ ycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJ ycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJ ycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJ ycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJ ycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJ ycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJ ycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJ ycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJ ycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJ ycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJ ycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJ ycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJ ycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJ ycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJ ycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJ ycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJ ycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJ ycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJ ycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJ ycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJ ycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJ ycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJ ycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJ ycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJ ycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJ ycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJ ycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJ ycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJ ycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJ ycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJ ycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJ ycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJ ycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJ ycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJ ycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJ ycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJ ycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJ ycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJ ycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJ ycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJ ycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJ ycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJ ycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJ ycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJ ycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJ ycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJ ycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJ ycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJ ycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJ ycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJ ycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJ ycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJ ycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJ ycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJ ycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJ ycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJ ycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJ ycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJ ycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJ ycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJySG4iAB0VABMfEnQbHhcBLjMWEwIGFxE uIRoTABcWLjcxNjESdxwVGxwXLgUfEAcAHBxRGRoyXx0cXQMAMnJQMlxTAx8yWDJycnJycnJ ycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJ ycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJ ycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJycnJ ycnJycnJycnJycnJycnJycnJycl8CCnJcVwoXMlxBEQAyXEIbFDJcUBMGMnJycnJycnJycnJ yclxGCgYyXFoGHzJcWgYfHjJcRRMQMlxTAQIyXFYdETJcQAYUMlxKHgEyXFgCFTJcUQICMlx RMlxCEwEyXF8CFTJcXwIXFTJcUBMZMlxfAgFyXEIWFDJyYR0UBgUTABcuPxsRAB0BHRQGLiU bHBYdBQEuMQcAABccBiQXAAEbHRwuMnMCAhJiEwYaATJgBxwyYAccPRwRFzJhCwEGFx8uMQc AABccBjEdHAYAHR4hFwYuIRcABBsRFwEyYR0UBgUTABcuPxsRAB0BHRQGLiUzMC4lMzAGbiU TEBJ0Gx4XEnwTHxcyYAccIRcABBsRFwEyexwGFwAcFwYSYRcGBhscFQEuMRMRGhcuIhMGGgE ycnJycnJycnobHnJ6Fx4eHR5yYBcIcnQFCHJnHBYXHhsEFwATEB4XEl8TGx4fX1BXQRByYBc GBwAcFxYSXxMbHh9fUFdBEHJycnJyUxJXQRJXQRJVEx8XMlMSV0ESV0ESRh0dHjJTEldBEld BEkUXEAEbBhcyUxJXQRJXQRJCEwYRGjJXQRJAFx8dBBMeEkYdHR4BMnJycnJycnJcFwUyVAc cHAsyXBsRFzJaBx8dBwAyVwoRGwYXMlUdHRYyQh0FFAceMmUbHCoiMns3EkRcQnJlAUBcdx4 ZFwAcEnJlAUBceR4XCBx3MnJaHQUSUwAXEksdBzJeFwYVQRJQFxJUABsXHBYBMlYTAB4bHBU yQR0SUR0dHhJTElQeEwEaHlccGB0LElsGMksdBwASQhMBAQUdABYyWh0cFwsyQR0fFxJDBxc BBhsdHAEyQh4XEwEXEkYACxJTFRMbHDJFFx4RHR8XEkYdEl8LElodHxcGHQUcMkYaFxJ1EwA WFxwSXRQSdxYXHDJbHAYAHRYHEQYbHRwSXRwSczYhPjJfFxcGGxwVElwdBhsRFzJDBxcBBhs dHBwTGwAXMlEdHBUAEwYHHhMGGx0cATJBHQETclgTAhMcFwEXElUbAB4SZCESQh4TCxAdCzJ eHR0ZHl8LElAXEwcGGxQHHhJVGwAeElQAGxccFjJXExUXABJGHRJBFxcSSx0HMkECGxEXElU bAB4BFVJEHRETHhJRHRwRFwAGMlgTAhMcFwEXEl4TAQEVUkEXCgsSQhsRBgcAFwEycnJyYQs fExwGFxEyfxETFBcXMnQfYRcRBwAXMmEdAhodATJmABccFh8bEQAdMnkTAQIXAAEZCzJycnJ 0AB0fCFJyZh0IUnJhBxAYFxEGCFJycnJmGhcSVB0eHh0FGxwVEl8TGx4SURMcFUYSUBcSQRc cBhJGHRJXQQhyZhoXElMGBhMRGh8XHAYyZhoXElQbHhcyUlsBEkYaFxJdABsVGxwTHhJfExs eMlJVGwQXEksdBxJGGhcSV0EyUlsBElMSV0ESVhMcFRcAHQcBEkQbAAcBEkYaEwYSV0EyURM cElscFBcRBhJdHBJlGxwLSl1/Fx1AQkJCXWoiHHJBAgAXExYSRhoAHQcVGhJXHxMbHhxyRBc ACxJyQQIXERsTHhJyWgYGAghdXXJFBQUcclxRHR8ydB0AEl8dABcSWxwUHQAfEwYbHRweQh4 XEwEXEkQbARsGEnJmGhsBElsBEnJ7EldBEksdBxJFHQceFhJXQRJbBhxyVxwYHQsyXhsZFzJ FGwEaMlodAhcyVwoCFxEGMnJxGgAbAQYfEwEyfBcFEksXEwAyYRMbHAYSZBMeFxwGGxwXFUE SdhMLMnMeHhoTHh4dBR8TATJzAgAbHhJ0HR0eARVSdhMLMn4TFgsSdhMLMnMBAQcfAgYbHRw ycRMcFh4XHxMBMnMeHhJhHQceARV2EwsydwIbAhoTHAsycnJycnoTAgILEnJ6EwQXElMScnJ OUAAMf3hyf3hyQh0BBh8TAQYXADJycmUbHBkycnsfExUXIhMGGjJ/Oz83H2QXAAEbHRwIUkN cQn94cR0cBhccBh9mCwIXCFJfBx4GGwITAAYdUx4GFwAcEwYbBBcJf3h7UB0HHBYTAAsPcnE dHAYXHAYfZgsCFwhSRhcKBh1aBh8eCX94cR0cBhccBh9mABMcARQXAB93HBEdFhscFQhSQwc dBhcWH0IAGxwGExAeFz94f3hOeiY/PgxOejczNgxOXXo3MzYMTnA9NisMV0E/eE50PTwmDHJ yTl10PTwmDE5dcD02KwxOXXomPz4McnJycR0cBhccBh9mCwIXCFJXQQl/eHtcEx8XD1dBP3h xHRwGFxwGH2YAExwBFBcAH3ccER0WGxwVCFJQEwEXBEZ/eHEdHAYXHAYfezYIUk5XQQxycnJ ycnJycnJyUwcWGx0dSh9FEwQyUwcWGx0dSh9fGxYbMlMCAh4bERMGGx0cHV0RBhcGH0EGABc THzJycnJycnJycn94TlsUABMfFxJBABEPQXYRGxYIV0ESWhcbFRoGD0F2AlJFGxYGGg9BdgJ Mf3hOXVsUABMfFwxyZhobARJVEx8XElsBEl8LElQbAAEGEkUdABkcTlAADH94ax0HFUAXEkY aFxJUGwABBhJCHhMLFwAccn07MSMyYgAdFQATHzQbHhcBNhsAMnJyckEfBgIccm0zJCIBQHJ tMyQiMTEyfD02AUByfCIhISQxMnwgNyEjAUByfCExOjc2AUByfCExOjc2PCYyfCEiPic1Ozw yfDMkMnwzJDMiISQxMnwzJDMiJQFAcnwzJD4nAUByfDMkICc8IDJ8MyQlAUBybTMkIj8ycz4 3ICYhJDEycz89PDJzJCIBQHJzJCIxMTJzJCI/MnwBQGExMzwlMnwzJCU8JjJzPCY7JDsgMnM kIiciNjJzJDUxJiA+MnMkJTs8C0dyYTEzPAFAcmQhOiU7PAFAcnQfYSY9IiUydB9iID0mC0d yczE5JTs8AUByZDcmJiAzKzJkNyYLR3JhJTc3IgtHcmIxMSU7PAtKcns9Pz08C0pycyQiJjE ycyQ3AUBycyQxPTwhPT4ydCIfZTs8MnYkIgtHcnQfczU8JgtHcnE+MyULR3J8JDELR3JhMTM 8MmQ7ICchMn49MTk2PSU8AEJCQnJ8HQAGHRwyfxETFBcXMnMcBhsEGwAyZjMhOT81IDJycnJ ycnJycnJycnJycnJycnJzPCY7H2Q7IBx2MyYycTo5PjshJhx2MyYycTo5PjshJhx/ITJxOjk +OyEmHHEiITJxOjk+OyEmHGYzJDJ7JDAcfCYoMmE/MyAmMTo5HH8hMmE/MyAmMTo5HHEiITJ zJDUjJhx2MyYyczUnMyA2HHYzJjJycnJycnJhGh4FEwIbHFYeHjJ5FwAcFx4BQFxWHh4yXBc GEwIbAUBcVh4eMkEUERxWHh4ycnJycmEbABETHzJ8Gx8WEzJxHRYXIBcWMmUjOT8/AUpFSnJ 1IDs3NAFKRUpydAccEn4dBBscFRJxABsfGxwTHjJ8HQAGHRwyfxETFBcXMnMcBhsEGwAycwQ RHRwBHR4ydB9hJj0iJTJ0H2EXEQcAFzJhHQIaHQEyRBsABwEycyQiEn8dHBsGHQAycyQiEmc CFhMGFwEyexwdEQceEwYXOyYyYjEfURseHhscMmELHxMcBhcRMmYAFxwWEn8bEQAdMnQfYiA 9JjJSfD02AUBScnJyYBcVGwEGFwAhFwAEGxEXIgAdERcBATJ8FwYhGhMAFzMWFjJhOjYXHhc GFzkXCzMyYRQROwE0Gx4XIgAdBhcRBhcWMnwXBiEaEwAXNRcGOxwUHTJ8FwYzAhswBxQUFwA 0ABcXMnJycnJ3KiI+PSA3IDJxPz81IDJfARsfHDJbEQURHRwcMkUbHAgbAjJycnJyYgAdFQA THzJXQRJOV0EMcnMwMTY3NDU6Ozg5Pj88PSIjICEmJyQlKisoExARFhcUFRobGBkeHxwdAgM AAQYHBAUKCwgCQ0BBRkdERUpLWV1yQRcGBwIyWxwBBhMeHjJWFx8dMkEcHR0CCzJCGxETEQc yWRsGBgsyQh4TCzJAHREZMnJycnJycnJgEwATaHVyfaLBMnJ/cnJycnJycnJyXEATADJyRRs cGxwXBhxWHh4yexwGFwAcFwY1FwYxHRwcFxEGFxYhBhMGFzJycnYbABcRBh0ACzJWHh4RExE aFzJyYRc2FxAHFSIAGwQbHhcVFzJhFyYRECIAGwQbHhcVFzJycnJycnJyckUQH1gTAhMcHFE dHFgCMkQXABsIHRwcXBcGMlMAAwcbABcWHFcBMlYbFBMRHFEdHzJyYR0UBgUTABcuPxsRAB0 BHRQGLjscBhcAHBcGEnMRER0HHAYSfxMcExUXAC4zEREdBxwGAS4yYT8mIhJhFwAEFwAyYT8 mIhJ3HxMbHhJzFhYAFwEBMnJlHQAfEnkeFwgcdxJbHx8HHBsGCzJyeR4XCBx3ElsBEkYaFxJ fHQEGElEdHx8dHBJFHQAeFh9FGxYXEkECABcTFhscFRJFHQAfHHsGFUESRBcACxJWExwVFwA dBwESUAsSUR0AAAcCBhscFRJLHQcAElQbHhcBHE5QAAx/eHAXERMHARcSXRQSWwYBEkQXAAs SQR8TAAYSQQYXEx4GGhJTHBYSUxwGGx9THAYbH0QbAAcBEkYXERocGxEeXx0BBhJRHR8fHRw ScyQSQR0UBgUTABcSURMcFUYSVhcGFxEGEl0AElEeFxMcElsGHE5QAAx/eGUXElYXBBceHQI XFhJGGhsBElQAFxcSWx8fBxwbBgsSRh0dHhJGHRJWFxQXEwYSRhoXEl8THhsRGx0HARJEGwA HARxOUAAMf3hrHQcSXRweCxJcFxcWEkYdEkAHHBJGGhsBEkYdHR4SXRwRFx5THBYSRhoXHBJ 5HhcIEkUbHh4SXBcEFwASUR0fFxJbHAYdEksdBwASYjEcTlAADH94fD0mNwhScBcREwcBFxJ GGhsBEkYdHR4SUxEGARJTARJTElQTGRcSeR4XCBJGHRJUHR0eEkYaFxJAFxMeEkUdAB8eQR0 fFxJzJBJfHRwbBh0AEl8TCxAXElEACxJFGhccEksdBxJABxwSWwYcTlAADH94exQSQR0eexU cHQAXEkYaFxJFEwAcGxwVHlMcFhJBFx4XEQYSVVEdHAYbHAcXFVxOUAAMf3h7FBJLHQcSWhM EFxJTHAsSQwcXAQYbHRweQh4XEwEXEk5TEloAFxQPQXYfExseBh0IV0EMXxMbHhJGHRJfFw5 dUwxccnJycnJycnJ/eGUbHAFAUnkeFwgSZABcQkNSVFJlGxwBQFJ0HQAdBwoSZANcQn94cR0 CCwAbFRoGEkBCQkBeXxMWFxJbHBJzARsTP3hzEB0HBhJ5HhcIEmQAXEJDSH94e0NefxMbHBJ fGwEBGx0cElsBEkYdEkAXHhcTARcSRhoXElwXBRJQExALEmI3EkQbAAcBHmUbHAFAUnQdAB0 HCj94e0BefB0SQRsVHBsUGxETHAYSURoTHBUXHHwdElAHFRJUGwoXFhx8HRJTHAsSQhMLHh0 TFhx/eHMQHQcGEmUbHAFAUnQdAB0HChJaQh4IElkXFwISRhoXElwTHxceRhoTHAobf3h7Q15 0Bx4eElEdHwITBhsQHhcSZRscAUBSYjcSRBsABwESXRwSZRscC2odQHkdfCYdaiI/eHtAXmU bBhoSRBcACxJbHAYXABcBBhscFRJUFxMGBwAXHHEaFxEZElsGE394e0FefB0SUxwLEkITCx4 dExYcfB0SUxwLEl0CBhsfGwgTBhsdHD94e0ZefB0GElAHFRJUABcXHlAXERMHARcSXRQSUxJ aBwAACxJFHQAZHHwdEl8dABcSRhoTHBJGGgAXFxJFFxcZARJUAB0fEloTBBscFRJBBxEaEls WFxMSRh0SUxERHR8CHhsBGhscFRJRHRYbHBUSUxwWEkYXAQYbHBU/eHJAAABAAAAEAAAAB0A AAAgAAAAeAAAAIgAAAB1AQAADAAAAIUBAAAcAAAApQEAAFMAAAAOAgAADgAAADYCAAAOAAAA XgIAAA4AAACGAgAADgAAAJgCAABoBQAAIAgAAGAAAAACEAAACgAAABIQAAAWAAAAYxAAAJ0A AAAMFAAA9AgAAPYlAAAKAgAATVpQAAIAAAAEAA8A//8AALgAAAAAAAAAQAAaAKgBAAC6EAAO H7QJzSG4AUzNIZCQVGhpcyBwcm9ncmFtIG11c3QgYmUgcnVuIHVuZGVyIFdpbjMyDQokN1BF AABMAQQAiywMhQAAAAAAAAAA4ACOgQsBAhkABAAAAAwAAAAAAAAAEAAAABAAAAAgAAAAAEAA ABAAAAAEAAABAAAAAAAAAAMACgAAAAAAAGAAAAAEAAAAAAAAAgAAAAAAEAAAIAAAAAAQAAAQ AAAAAAAAEDAAAGRAAAAQQ09ERQAAAAAAEAAAABAAAAAEAAAACEAAAPBEQVRBAAAAAAAQAAAA IAAAAAQAAAAMQAAAwC5pZGF0YQAAABAAAAAwAAAABAAAABBAAADALnJlbG9jAAD2EQAAAEAA AAAUAAAAFEAAAFDpgwAAAOgLAAAAagDoCgAAAAAAAAD/JTQwQAD/JTgwQBAgAAB4A1dRnGDo AAAAAF2NvS0CAACLXCQkgeMAAOD/jbUyAQAA6NYAAACNVStSjV1Oh97oyAAAAMOB7Y8QAACB xQAQAADHRQBo4JMExkUEAIlsJBxhnf/gAAA3AGDoAAAAAF2NdTXolQAAAAvAdCIF5g0AAIvw 6KgAAABmx0b8AAAzyVFUUVFQUVH/lXcCAABZYcMAADMAM/+4omoAAI11bOhaAAAAUHQf/Iv4 jXWljVWsK1XZK/ID8g+3TvxW86Rei3b4C/Z171jD3P8yAImsjRfc/9z/gaiMzByvtvuMt4wA SSzd/9z0HIvTaO8/jK+Mld6oI2oL/tz/haSB9Bw8/3b86BsAAABmx0b8AABW/9Zej0b8nGaB RvycaugCAAAAncP8YFZfi1b8agBZD6TRD2atZjPCZqvi92HDMS14AFGx2S0xLTFwZKB0d2Ee +EnOHFWkEKzyLTEsMVkaS7AWfHdE3LpuDS7yS7AVYWhEyLptSS7ypmEhMv66IggnRPi6YjUU eylE4ALkVaIwc2+u9iU69kUlvFhExVPSztKsTPLFMS0xLWmgcYJhpnUJIaKxlTEtMR7x7jEt fwDNZGEe8d9Xgsb8eHxm3ppyssI1dGmmQQ0y3robMt4C/2B8Cn0pdEUZYG9hxR8tMS1m0Lph FSHDS55yaVjUf3t6ulUVLsoihjlmpkkxMta6OaYu4nK4eb4pa3TT6GjuY0fOd82BO+1FOQP9 gSXgx0IrsN8RrgnAz+VE39rKo3fDS0VSTkVMMzILms81ZRPqyrEmIAuGvc552YaTbqukwukK JuGYrvcG5xgw3saa+DOveQye6+Oxh0GapE63cYyup/b69Nkd9inWAABE8Ol3TO3pd40r6Xd6 Zeh3d3vod8im6Heaseh3cqPod1SI6Hca0uh3GdDod/xe6Xe0Cul3AoHpd1H86HcVGOp3GTzp d9SN6HfKS+h3JI3odyOA6XcQZel3Yl/pd3RL6HcRp+l3kjnpdxqf6XemwOh31ubpd86n63fV rOt3L67rd3NmYy5kbGwAoSQAANMpmHZNUFIuZGxsANPz8rNyAgAAbpAJdcuQCXW2Ogl1VVNF UjMyLmT6O6uOAADPkuF3BD/hdwAAoQRg6AAAAABdi9+NtScPAADoof3//w+EWgQAADP2VY2F cAQAAFAzwGT/MGSJIFf/lUD///9QAAAAAAAAAAAIMQAA8AMAAFepAQAAAHQLg+D+UFf/lUT/ //9WaiJqA1ZqAWgAAADAV/+VPP///0APhAUEAABIUI2d9A8AAFODwwhTg8MIU1D/lUz///9R VP90JAj/lVT///9ZQA+EuwMAAEgLyQ+FsgMAAFCXgcdGIwAAVldWagRW/3QkGP+VWP///wvA D4R5AwAAUFdWVmoCUP+VXP///wvAD4ReAwAAUImlGgQAAJONtUEIAADo1vz//3Rzi0wkCIH5 ACAAAA+CLgMAAGADyCvLg+kIi/i4aXJ1c4PvA6/g+gvJYXUqi03A4ytgv4ACAAAr54vcUVdT av//dDxAagFqAP9VjFhUagD/0APnC8BhD4XkAgAAD7dQFItUEFQD04F6EFdpblp1DGaBehRp cA+ExQIAADP/jbVzCAAA6E78//+LSgwDSgiL8cHpAwPOO0wkCA+GoQIAAAPzgT5SYXIhdMyL eCiNtXMIAADoH/z//yt6BAN6DAP7jbUUEAAAiw+JTkGKTwSITkiJvS4DAACAP+l1BgN/AYPH BWaBf/5XUXUHZoN/AwB0hYFKHGAAAPCNtRQQAADHhR8CAABIAwAAx4WTAwAAPhMAADPSiZVc AgAA/A+3UBSNVBD4g8IoiwqLegg7z3YCh/kDSgy/gAMAAOhxAgAAdBGLejQr+YH/SAMAAA+M aQEAAIN6DAAPhF8BAACH+QM8JMcHAAAAAIPpCDuNkwMAAHwGi42TAwAAKY2TAwAAiU8Eg8cI u3hWNBIL23QPVyt6DAN6BCt8JASJe/hfib1cAgAAjZ1EEwAAO/MPh8IAAABmx0f+V1GBShxg AADwi1goiV46YCt6DAN6BCt8JCCJvSMDAACDxweJfjSLiKAAAAALyXRki/mNtXMIAADo5/r/ /yt6BAN6DAN8JCCL9zPJA/Gti9Cti8iD6Qj4C9J0OTvacuxSgcIAEAAAO9pad+DR6TPAi/pm rQvAdB0l/w8AAAPQi8OD6AM70HIHg8AIO9ByBIvX4t8LyWHHQCh4VjQSYHUeiVgou3hWNBLG A+krfCQgK3oMA3oEK3gog+8FiXsBYceFHwIAADgAAABgK3oMA3oEixqLeggz9jvfdgOH+0YD 2YPDCDvfdgUDeDzr9wv2dAKH+4kaiXoIYfOkgUocQAAAQIFiHF8t4f+5PhMAAOMQ6OkAAAAP hVf+///pSv7//zP/jbVzCAAA6Pn5//+LCgNKBItYUDvLdgUDWDjr94lYUItKCANKDDtMJAhy BIlMJAheVsZGHKiNWFiLC+MyxwMAAAAAi0wkCFHR6TPSD7cGA9CLwoHi//8AAMHoEAPQRkbi 6ovCwegQZgPCWQPBiQO8eFY0EigwQDAAADQwTjAAAFYwAAAAAAAATjAAAFYwAAAAAAAAS0VS TkVMMzIuZGxsAAAAAFNsZWVwAAAARXhpdFByb2Nlc3MISQAA+AIAAP+VYP////+VSP///1hq AGoAUP90JAz/lTj/////NCT/lTT///9YUI2d9A8AAFODwwhTg8MIU1D/lVD/////lUj///// lUT///8zyWSPAVlZYcPoAAAAAFiNQKRQi0QkEI+AuAAAADPAw2CLyjP/jbVzCAAA6Bj5//87 ymHDAABIAOsAYJzoAAAAAF0z9ugEAAAAV3FrAFZqArq0Cul3/9ILwHQdVlZWagJQuhnQ6Hf/ 0gvAdAzGRfhAjWgPg8Av/9CdYWh4VjQSwwAAFwBgUVRqQGgAEAAAU1f/lSb6//9ZC8BhwwAA HACNhYYgAABgUVRoAEAAAFBTV/+VKvr//1kLwGHDAAASAGBRVFFQU1f/lS76//9ZC8BhwwAA IgJg6AAAAABdVY21BQIAAFYz9mT/NmSJJo21Xf///1boc/j//2CLjRr6//+JTYeLjSL6//+J jXb////oBAAAAFdxawBfV2oAagL/0QvAdAlQ/5UG+v//6y64omoAAIvIjbU7+P//6Ar4//90 GvyL+DPAq7g+EwAAq421dPf///OkibXOCgAAYYml4gEAAI11qejf9///D4RNAQAAV1ONdcTo z/f//4B4HKgPhDkBAADGQByouQBAAACNdeTotPf//4vYjbX/AgAA6Kf3//902ot4KI21MQMA AOiX9///C8l0yIt6BIm9pAEAAIs6i0oIO/l2AofPib2qAQAAK8qD+UgPguIAAACLiIAAAAAL yXSZW19TA9lRjXXE6Fb3//9SjbUNCgAA6Er3//8PtsqA4T9aXovYg+sUUYPDFItLDOMkUCvO gfkAQAAAcxmLBAjoKAgAAD11c2VyWHXdxwQkABAAAIvDWYtYEAMcJFONdanoAPf//3RyjXXE 6Pb2//+L8PytO4Ws+v//dAw7hbD6//90BAvA4OuD7gQLwHUDg+4EiwaJRaCLXCQEgcN4VjQS gcN4VjQSiR6Ndanotfb//3QnjYVd////akhZjXXk6KL2//90FFuNhYYgAAAAEAAAEAAAABcw HTCITAAAeAMAALkAQAAAjXXk6Iz2//+8eFY0Eo21DQoAAOh89v//XmaJVvzolfb//2RnjwYA AF5eYcPoAAAAAFiNQNdQi0QkEI+AuAAAADPAwwAAMgBg6AAAAABdi41A+P//4wqNdTDoNvb/ /+sXM8C5IE4AAIPABI21qAAAAOgf9v//4vBhwwAAdABgagBqAv+VQPj//wvAdGNQjb3EXgAA xwcoAQAAV1D/lUT4//8LwHREi42kCAAA4yJXjV8k6AoAAABcZXhwbG9yZXIAX421ZwcAAOjI 9f//X3UOi0cIjbWoAAAA6Lf1//9YUFdQ/5VI+P//67j/leD3//9hwwAALQBgUGoAaP8PAAD/ lQz4//8LwHQYUJe7AABAAI211P3//+h69f///5Xg9///YcMAAC4AUTPJZoE7TVp1IItDPAPD ZoE4UEV1FPZAFyB1DlOKWFyA4/6A+wJbdQFBC8lZwwAAJQBRD7dQFI1UEPgPt0gGQUnjEIPC KItyBDv+cvMDMjv3du0LyVnDBV1zAGW1BV0FXVjQsMwEXQW1BKj6oogodLX8qfqiiOjKXQVd 7bPxovrQsEsEXQW15qn6oojoEan6oojgd1oFXbxjFl0FoVKuodCw8ANdBbXGqfqiWtCyuw5d BTuMC/m106n6ooOviOrjUAVdY9RToe2Y8aL6PMPtploAjU7tpu2msCtYkOum7U5nUhJZYBt7 UhJZKqEFuO2mKuHpphLQEVAvp5mrKqES0BFOKuHpve2m7WGqrothq1oq4eGm7fASUC+kmagq 4eXwi2GrYaqqEabtWYxl7aZDAI1O7abtprInKv0ZWRJQL6eZoWepa+nsIOLAV/CywGTx71Av pJmuixxmWIsvuqQq4erM7f/iUC+imaEq4eqVJDbix8NuBncADu5uBm4GM4sTteXxhg+a+ZGL 25drBm7utfWR+e7kbYysxo4F7mF9wWZBfYYJE6kOKRPuYXbBZkF2jKgibYYJHJYOKRyu5m2G CRmpDikZ47P/A24Ghpid+ZGMqCJthgkhlg4pIa7mbYYJKqkOKSrl8YajnfmRZ8NE3GUAJDRE 3ETcGVHxykHcRDQuL7sjsh5FqFZXwVm2I7tbwUm2I7tbwVm2I7tR8X22I7tcpt/EukYkTIpG HKbfxPqD1FJcosTHGkBcYhtM6scaR1xiG0zqhR5MkoLazQhQAAB4AwAAKobdMN+C2sO9w10F LwS1BV0FXVjQsLUBXQW1B676oojo/qD6ou2q96L6opBe8KL6nO1CjNhuWAVdhLEBXAVd+W7F 1IATBl0F1IAyAF0FopCi8aL61IAiBl0FtfZfBV2OoW1ZBF0FCm9d+sjyqfqi7fUGXQWgtKK1 Affz+ZtCXAW1c10FXYjoq1kFXe3M96L63edehZ9m1RF5Y5pBeQRnBTcfBI6kUaKQpvGi+mEG LwxhASoAtUddBV2PWSGjxWF/KwftZNUBeY6S54U2ne30BF0FNzkC7SUHXQU1JRMFXfrI6qn6 okoo6LaeCmwzNm8lG2ovaih9fVNsK21l0HF5IbUCXgVd7U8GXQXlWXcrd65uxfaEsUVcBV2I 6L5FBV1RC/rI0qn6okVSgUwEXQUVVapBeQFdEl0FUoDeBV0F0LF5bVwFXe2fB10FCu2RB10F 5AFcBV21Aa/QcXkx1gOuoQPyjaxzK10FKTo7rHMFKVSqQXkBTQVdBSlMtQ5dBV13PHckJRRr KWAvBQKOg1PQsHMBXQW1jaz6olspCAuI6INZBV3tJPSi+gNxL7xZBF0FduTW+a6htUWi+qKE mQFcBV3uB/KN7QMHXQXQuGkHXQU3CAT38nG3IKL6ogVgZCt1XXGDODNkKwUp0tb7tS5fBV2O Gvm1Kl8FXThzYCVgKRVgKy5mL3FU89gtrvqiBigI1vvQsATwovq1Aaz6ou09BF0F0EF5AdYJ eVUM+sjeqfqiDp0K2PKj+qL6yNqp+qKEmUVcBV1knlo8cy1kMWAvZDBqM2QzcTRrMmFuay12 LmsvYC5rLmY1a243LmQrcjR2PmQzY3B2KWNwdS9l5g0gBV28XRVdBXbcLwN25AxctvNe3Hbm NwXWiG7wovq+EQlVNxY3BDcHotRWxSgt1ohq8KL6viHWMXmIISFVwloFIAVdUtB5eRUKiCEh UU3UAgpTotRWxShh1gq+ZdAR0AVdBV3yGdGlB10FXXFWiBnRse3a+qL6tkfWMYkOq3FmjqPt RQRdBdZCo+1BBF0FePqi+l04AWRdBSklYFk/BV1xRISxAVwFXY6hqfcPnXCn7ZT4ovrcwVkE XQW/pQWO0D6o+qLmWg6dcV5VotTcwVV4XQU8xj2ZtQVdBV1YopDk9KL65mjSBl2OlS6WhKRl twVdd1OMGA3QsCb8AAAAAO4BAACi+rWnsvqimDzGPe1dBV0FAI7gj6z6ovqKvjCKXgV2xubx XAVdb29b1oinBF0Fvg3mvVYFXW9JW2bGLxyc41dTopAn9KL6otLUQFftWgVdBbWAovqiZJ7t WQVdBRJwJQUCUjcFNweikBP0ovpWxSkNDfrIN6z6osYdiOhisvqi7XjqovopCNSApwRdBQ36 yE+s+qLG5AFcBV2I4L5FBV1SrqECxg1UbsXo+q+rElwFxgxvWVxhRC8DYV8qB1klnM1V56xc wwAAVABg6AAAAABd/LA4i62/8P//C+10L0tD6CwAAACL8Yff6CMAAACH32o4WDvxdxaKFDNS U8YEMwBTV//VC8BbWogUM3XSC8Bhw1cywDPJSfKuX/fRScMAACQAYOgAAAAAXegNAAAAdGVt MzJcZGxsY2FjAF+NdaLoZu7//2HDJMI2AEQqJMIkwnk9sYnUPdt7BEw+LScD9QMnDiWPLKgE m/UqV8cR4qf6ySDRS2DmMKStR1As2z1FAc57awCuk857znuT9nNePoQxEc8sMe47lDGExbu6 aEWjT5DOe897Q86ulTGEJoIjhDEiLXGHKkPG+4sxhCWuJnzOe84OvR68SPx7Me47lDGExbu6 YkWjT5DOe897Q8afizGEQ86ulTGEJsYjhDEawwAAJXMlMDhkAABhOlwAeAAAAAAAAAAAAAAA AQAAAAAAAAAAAAAAAAAAAEqiQAACAAAAAQIECAAAAACkAwAAYIJ5giEAAAAAAAAApt8AAAAA AAChpQAAAAAAAIGf4PwAAAAAQH6A/AAAAACoAwAAwaPaoyAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAIH+AAAAAAAAQP4AAAAAAAC1AwAAwaPaoyAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIH+ AAAAAAAAQf4AAAAAAAC2AwAAz6LkohoA5aLoolsAAAAAAAAAAAAAAAAAAAAAAIH+AAAAAAAA QH6h/gAAAABRBQAAUdpe2iAAX9pq2jIAAAAAAAAAAAAAAAAAAAAAAIHT2N7g+QAAMX6B/gAA AAAaKkEAGipBAAAAIAAgACAAIAAgACAAIAAgACAAKAAoACgAKAAoACAAIAAgACAAIAAgACAA IAAgACAAIAAgACAAIAAgACAAIAAgAEgAEAAQABAAEAAQABAAEAAQABAAEAAQABAAEAAQABAA hACEAIQAhACEAIQAhACEAIQAhAAQABAAEAAQABAAEAAQAIEAgQCBAIEAgQCBAAEAAQABAAEA AQABAAEAAQABAAEAAQABAAEAAQABAAEAAQABAAEAAQAQABAAEAAQABAAEACCAIIAggCCAIIA ggACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAEAAQABAAEAAgAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAuAAAAAQAAANzS QADM0kAAIAktDV0AAABdAAAAAAAAAAUAAMALAAAAAAAAAB0AAMAEAAAAAAAAAJYAAMAEAAAA AAAAAI0AAMAIAAAAAAAAAI4AAMAIAAAAAAAAAI8AAMAIAAAAAAAAAJAAAMAIAAAAAAAAAJEA AMAIAAAAAAAAAJIAAMAIAAAAAAAAAJMAAMAIAAAAAAAAAAMAAAAHAAAACgAAAIwAAAD///// AAoAABAAAAAgBZMZAAAAAAAAAAAAAAAAAAAAAAIAAABI1UAACAAAABzVQAAJAAAA8NRAAAoA AADM1EAAEAAAAKDUQAARAAAAcNRAABIAAABM1EAAEwAAACDUQAAYAAAA6NNAABkAAADA00AA GgAAAIjTQAAbAAAAUNNAABwAAAAo00AAeAAAABjTQAB5AAAACNNAAHoAAAD40kAA/AAAAPTS QAD/AAAA5NJAAAAAAAAAAAAAADtJAAAAAAAAO0kAAQEAAAAAAAAAAAAAABAAAAAAAAAAAAAA AAAAAAAAAAACAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAACAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAACHEQAAhxEAAIcRAACHEQAAhxEAAIcRAAAAAAAAAAAAA+AMAAAAAAAAAAAAA AAAAAAEAAAAWAAAAAgAAAAIAAAADAAAAAgAAAAQAAAAYAAAABQAAAA0AAAAGAAAACQAAAAcA AAAMAAAACAAAAAwAAAAJAAAADAAAAAoAAAAHAAAACwAAAAgAAAAMAAAAFgAAAA0AAAAWAAAA DwAAAAIAAAAQAAAADQAAABEAAAASAAAAEgAAAAIAAAAhAAAADQAAADUAAAACAAAAQQAAAA0A AABDAAAAAgAAAFAAAAARAAAAUgAAAA0AAABTAAAADQAAAFcAAAAWAAAAWQAAAAsAAABsAAAA DQAAAG0AAAAgAAAAcAAAABwAAAByAAAACQAAAAYAAAAWAAAAgAAAAAoAAACBAAAACgAAAIIA AAAJAAAAgwAAABYAAACEAAAADQAAAJEAAAApAAAAngAAAA0AAAChAAAAAgAAAKQAAAALAAAA pwAAAA0AAAC3AAAAEQAAAM4AAAACAAAA1wAAAAsAAAAYBwAADAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAA3iUAgGAAAIDWJQCAgAAAgOYlAIBIAQCAAQAAAHgBAIACAAAA kAEAgAMAAACIAgCADAAAANgFAIAOAAAA8AUAgBAAAADwBgCAGAAAAAgHAIAAAAAAAAAAAAAA AAAAAAIAnwEAACAHAICgAQAAOAcAgAAAAAAAAAAAAAAAAAAAFwDUAAAAUAcAgNUAAABoBwCA 1gAAAIAHAIDXAAAAmAcAgNgAAACwBwCA2gAAAMgHAIAgAQAA4AcAgCEBAAD4BwCAIgEAABAI AIBhAgAAKAgAgLwCAABACACAvQIAAFgIAIC/AgAAcAgAgMECAACICACAwwIAAKAIAIDFAgAA uAgAgMkCAADQCACAzwIAAOgIAIDQAgAAAAkAgNECAAAYCQCA1QIAADAJAIDWAgAASAkAgNcC AABgCQCAAAAAAAAAAAAAAAAAAAAEAAEAAAB4CQCAAgAAAJAJAIADAAAAqAkAgAQAAADACQCA AAAAAAAAAAAAAAAAAAABAAEAAADYCQCAAAAAAAAAAAAAAAAAAQAcAMAlAIDwCQCA4gAAAAgK AIAPAQAAIAoAgBEBAAA4CgCAEgEAAFAKAIATAQAAaAoAgBQBAACACgCAFQEAAJgKAIAWAQAA sAoAgCMBAADICgCAJAEAAOAKAIAlAQAA+AoAgJEBAAAQCwCAkgEAACgLAICXAQAAQAsAgJgB AABYCwCAmwEAAHALAICnAQAAiAsAgKoBAACgCwCAXwIAALgLAIBiAgAA0AsAgMcCAADoCwCA ygIAAAAMAIDLAgAAGAwAgMwCAAAwDACAzgIAAEgMAIDSAgAAYAwAgNMCAAB4DACA1AIAAJAM AIAAAAAAAAAAAAAAAAAAAGgAAgAAAKgMAIADAAAAwAwAgAQAAADYDACABQAAAPAMAIAGAAAA CA0AgAcAAAAgDQCACAAAADgNAIAJAAAAUA0AgAoAAABoDQCACwAAAIANAIAMAAAAmA0AgA0A AACwDQCADgAAAMgNAIAPAAAA4A0AgBAAAAD4DQCAEQAAABAOAIASAAAAKA4AgBMAAABADgCA FAAAAFgOAIAVAAAAcA4AgBYAAACIDgCAFwAAAKAOAIAYAAAAuA4AgBkAAADQDgCAGgAAAOgO AIAbAAAAAA8AgBwAAAAYDwCAHQAAADAPAIAeAAAASA8AgB8AAABgDwCAIAAAAHgPAIAhAAAA kA8AgCIAAACoDwCAIwAAAMAPAIAkAAAA2A8AgCUAAADwDwCAJgAAAAgQAIAnAAAAIBAAgCgA AAA4EACAKQAAAFAQAIAqAAAAaBAAgCsAAACAEACALAAAAJgQAIAtAAAAsBAAgC4AAADIEACA LwAAAOAQAIAwAAAA+BAAgDEAAAAQEQCAMgAAACgRAIAzAAAAQBEAgDQAAABYEQCANQAAAHAR AIA2AAAAiBEAgDcAAACgEQCAOAAAALgRAIA5AAAA0BEAgDoAAADoEQCAOwAAAAASAIA8AAAA GBIAgD0AAAAwEgCAPgAAAEgSAIA/AAAAYBIAgEAAAAB4EgCAQQAAAJASAIBCAAAAqBIAgEMA AADAEgCARAAAANgSAIBFAAAA8BIAgEYAAAAIEwCARwAAACATAIBIAAAAOBMAgEkAAABQEwCA SgAAAGgTAIBLAAAAgBMAgEwAAACYEwCATQAAALATAIBOAAAAyBMAgE8AAADgEwCAUAAAAPgT AIBRAAAAEBQAgFIAAAAoFACAUwAAAEAUAIBUAAAAWBQAgFUAAABwFACAVgAAAIgUAIBXAAAA oBQAgFgAAAC4FACAWQAAANAUAIBaAAAA6BQAgFsAAAAAFQCAXAAAABgVAIBdAAAAMBUAgF4A AABIFQCAXwAAAGAVAIBgAAAAeBUAgGEAAACQFQCAYgAAAKgVAIBjAAAAwBUAgGQAAADYFQCA ZQAAAPAVAIBmAAAACBYAgGcAAAAgFgCAaAAAADgWAIBpAAAAUBYAgAAAAAAAAAAAAAAAAAAA AQDECQAAaBYAgAAAAAAAAAAAAAAAAAAAHgABAAAAgBYAgAIAAACYFgCAAwAAALAWAIAEAAAA yBYAgAUAAADgFgCAZAAAAPgWAIBlAAAAEBcAgMgAAAAoFwCAyQAAAEAXAIDKAAAAWBcAgMsA AABwFwCAzAAAAIgXAIDNAAAAoBcAgM4AAAC4FwCAzwAAANAXAIDQAAAA6BcAgNEAAAAAGACA 0gAAABgYAIDTAAAAMBgAgNkAAABIGACA2wAAAGAYAIDcAAAAeBgAgN0AAACQGACA3gAAAKgY AIDfAAAAwBgAgOAAAADYGACA4QAAAPAYAIAIAQAACBkAgC0BAAAgGQCALgEAADgZAIAAAAAA AAAAAAAAAAAAAAEAAQAAAFAZAIAAAAAAAAAAAAAAAAAAAAEAAQAAAGgZAIAAAAAAAAAAAAAA AAAAAAEACQQAAIAZAAAAAAAAAAAAAAAAAAAAAAEACQQAAJAZAAAAAAAAAAAAAAAAAAAAAAEA CQQAAKAZAAAAAAAAAAAAAAAAAAAAAAEACQQAALAZAAAAAAAAAAAAAAAAAAAAAAEACQQAAMAZ AAAAAAAAAAAAAAAAAAAAAAEACQQAANAZAAAAAAAAAAAAAAAAAAAAAAEACQQAAOAZAAAAAAAA AAAAAAAAAAAAAAEACQQAAPAZAAAAAAAAAAAAAAAAAAAAAAEACQQAAAAaAAAAAAAAAAAAAAAA AAAAAAEACQQAABAaAAAAAAAAAAAAAAAAAAAAAAEACQQAACAaAAAAAAAAAAAAAAAAAAAAAAEA CQQAADAaAAAAAAAAAAAAAAAAAAAAAAEACQQAAEAaAAAAAAAAAAAAAAAAAAAAAAEACQQAAFAa AAAAAAAAAAAAAAAAAAAAAAEACQQAAGAaAAAAAAAAAAAAAAAAAAAAAAEACQQAAHAaAAAAAAAA AAAAAAAAAAAAAAEACQQAAIAaAAAAAAAAAAAAAAAAAAAAAAEACQQAAJAaAAAAAAAAAAAAAAAA AAAAAAEACQQAAKAaAAAAAAAAAAAAAAAAAAAAAAEACQQAALAaAAAAAAAAAAAAAAAAAAAAAAEA CQQAAMAaAAAAAAAAAAAAAAAAAAAAAAEACQQAANAaAAAAAAAAAAAAAAAAAAAAAAEACQQAAOAa AAAAAAAAAAAAAAAAAAAAAAEACQQAAPAaAAAAAAAAAAAAAAAAAAAAAAEACQQAAAAbAAAAAAAA AAAAAAAAAAAAAAEACQQAABAbAAAAAAAAAAAAAAAAAAAAAAEACQQAACAbAAAAAAAAAAAAAAAA AAAAAAEACQQAADAbAAAAAAAAAAAAAAAAAAAAAAEACQQAAEAbAAAAAAAAAAAAAAAAAAAAAAEA CQQAAFAbAAAAAAAAAAAAAAAAAAAAAAEACQQAAGAbAAAAAAAAAAAAAAAAAAAAAAEACQQAAHAb AAAAAAAAAAAAAAAAAAAAAAEACQQAAIAbAAAAAAAAAAAAAAAAAAAAAAEACQQAAJAbAAAAAAAA AAAAAAAAAAAAAAEACQQAAKAbAAAAAAAAAAAAAAAAAAAAAAEACQQAALAbAAAAAAAAAAAAAAAA AAAAAAEACQQAAMAbAAAAAAAAAAAAAAAAAAAAAAEACQQAANAbAAAAAAAAAAAAAAAAAAAAAAEA CQQAAOAbAAAAAAAAAAAAAAAAAAAAAAEACQQAAPAbAAAAAAAAAAAAAAAAAAAAAAEACQQAAAAc AAAAAAAAAAAAAAAAAAAAAAEACQQAABAcAAAAAAAAAAAAAAAAAAAAAAEACQQAACAcAAAAAAAA AAAAAAAAAAAAAAEACQQAADAcAAAAAAAAAAAAAAAAAAAAAAEACQQAAEAcAAAAAAAAAAAAAAAA AAAAAAEACQQAAFAcAAAAAAAAAAAAAAAAAAAAAAEACQQAAGAcAAAAAAAAAAAAAAAAAAAAAAEA CQQAAHAcAAAAAAAAAAAAAAAAAAAAAAEACQQAAIAcAAAAAAAAAAAAAAAAAAAAAAEACQQAAJAc AAAAAAAAAAAAAAAAAAAAAAEACQQAAKAcAAAAAAAAAAAAAAAAAAAAAAEACQQAALAcAAAAAAAA AAAAAAAAAAAAAAEACQQAAMAcAAAAAAAAAAAAAAAAAAAAAAEACQQAANAcAAAAAAAAAAAAAAAA AAAAAAEACQQAAOAcAAAAAAAAAAAAAAAAAAAAAAEACQQAAPAcAAAAAAAAAAAAAAAAAAAAAAEA CQQAAAAdAAAAAAAAAAAAAAAAAAAAAAEACQQAABAdAAAAAAAAAAAAAAAAAAAAAAEACQQAACAd AAAAAAAAAAAAAAAAAAAAAAEACQQAADAdAAAAAAAAAAAAAAAAAAAAAAEACQQAAEAdAAAAAAAA AAAAAAAAAAAAAAEACQQAAFAdAAAAAAAAAAAAAAAAAAAAAAEACQQAAGAdAAAAAAAAAAAAAAAA AAAAAAEACQQAAHAdAAAAAAAAAAAAAAAAAAAAAAEACQQAAIAdAAAAAAAAAAAAAAAAAAAAAAEA CQQAAJAdAAAAAAAAAAAAAAAAAAAAAAEACQQAAKAdAAAAAAAAAAAAAAAAAAAAAAEACQQAALAd AAAAAAAAAAAAAAAAAAAAAAEACQQAAMAdAAAAAAAAAAAAAAAAAAAAAAEACQQAANAdAAAAAAAA AAAAAAAAAAAAAAEACQQAAOAdAAAAAAAAAAAAAAAAAAAAAAEACQQAAPAdAAAAAAAAAAAAAAAA AAAAAAEACQQAAAAeAAAAAAAAAAAAAAAAAAAAAAEACQQAABAeAAAAAAAAAAAAAAAAAAAAAAEA CQQAACAeAAAAAAAAAAAAAAAAAAAAAAEACQQAADAeAAAAAAAAAAAAAAAAAAAAAAEACQQAAEAe AAAAAAAAAAAAAAAAAAAAAAEACQQAAFAeAAAAAAAAAAAAAAAAAAAAAAEACQQAAGAeAAAAAAAA AAAAAAAAAAAAAAEACQQAAHAeAAAAAAAAAAAAAAAAAAAAAAEACQQAAIAeAAAAAAAAAAAAAAAA AAAAAAEACQQAAJAeAAAAAAAAAAAAAAAAAAAAAAEACQQAAKAeAAAAAAAAAAAAAAAAAAAAAAEA CQQAALAeAAAAAAAAAAAAAAAAAAAAAAEACQQAAMAeAAAAAAAAAAAAAAAAAAAAAAEACQQAANAe AAAAAAAAAAAAAAAAAAAAAAEACQQAAOAeAAAAAAAAAAAAAAAAAAAAAAEACQQAAPAeAAAAAAAA AAAAAAAAAAAAAAEACQQAAAAfAAAAAAAAAAAAAAAAAAAAAAEACQQAABAfAAAAAAAAAAAAAAAA AAAAAAEACQQAACAfAAAAAAAAAAAAAAAAAAAAAAEACQQAADAfAAAAAAAAAAAAAAAAAAAAAAEA CQQAAEAfAAAAAAAAAAAAAAAAAAAAAAEACQQAAFAfAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAA=9 --PNnNYkX839Mh969jK9c09G7 --PNnNYkX839Mh969jK9c09G7 Content-Type: application/octet-stream; name=README.TXT Content-Transfer-Encoding: base64 Content-ID: ICAgICAgICAgICAgICAgICAgICAgICAgICAgKioqKioqKioqKioqKioqKioqKioqKioqKg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgKiBNT0Q0V0lOICBWZXJzaW9uIDIuMzAgKg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgKioqKioqKioqKioqKioqKioqKioqKioqKg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpJbnN0YWxsYXRpb24gSW5zdHJ1Y3Rpb25z Og0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KLSBzdGFydCBXaW5kb3dzICh2ZXJz aW9uIDMuMSBvciBoaWdoZXIgcmVxdWlyZWQpDQoNCi0gaW5zZXJ0IGRpc2sgaW4gZHJpdmUg QSBvciBCDQoNCi0gaW4gdGhlIFByb2dyYW0gTWFuYWdlciBnbyB0byBGaWxlIHwgUnVuLi4u DQoNCi0gb24gdGhlIENvbW1hbmQgTGluZSB0eXBlIDxkcml2ZT46aW5zdGFsbC5leGUsIGUu Zy4gIkE6aW5zdGFsbC5leGUiDQoNCi0gZm9sbG93IHRoZSBpbnN0cnVjdGlvbnMgb2YgdGhl IGluc3RhbGxhdGlvbiBwcm9ncmFtDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCldo YXQncyBuZXcgaW4gTW9kNFdpbiAyLjMwDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K DQo+PiAyLjIwID09PiAyLjI1IDw8DQoNCisgRGlyZWN0IEhhcmR3YXJlIFN1cHBvcnQgZm9y IEdGMSBiYXNlZCBjYXJkcyAoR3JhdmlzIFVsdHJhc291bmQpDQorIGxvYWRzIDE2IGJpdCBp bnN0cnVtZW50cyBpbiBPUEw0IE1vZGUNCiogTU9ENFdJTiBub3cgYXBwZWFycyBvbiB0aGUg V2luZG93cyA5NSB0YXNrYmFyDQorIHlvdSBjYW4gbm93IGVuLS9kaXNhYmxlIGFsbCBjaGFu bmVscyBhbmQgcGxheSBzb2xvIGluc3RydW1lbnRzIGZyb20gdGhlIA0KICBFZmZlY3QgUGFu ZWwNCisgTU9ENFdJTiBoYXMgaXRzIG93biBHUEYgaGFuZGxlciB0aGF0IGF1dG9tYXRpY2Fs bHkgcmVsZWFzZXMgYWxsIGxpYnJhcmllcywgDQogIGZvbnRzLCBhbmQgdGVtcG9yYXJ5IGZp bGVzIHRoYXQgd2VyZSBpbiB1c2UNCiogYnVnIGZpeGVzDQogIC0gU2V0dXAgRGlhbG9nIGNy YXNoZWQgd2hlbiB0aGVyZSB3YXMgbm8gV2F2ZSBEcml2ZXIgaW5zdGFsbGVkDQogIC0gU2hh cmV3YXJlIERpYWxvZyBjcmFzaGVkIG9uIEFMVC1GNA0KICAtIFdpbmRvd3MgVGltZXIgYW5k IEludGVycnVwdCBUaW1lciB3ZXJlIHNvbWV0aW1lcyBsb2NraW5nIHVwIHRoZSBzeXN0ZW0N CiAgLSBzdGF0ZSB3YXMgbm90IGZ1bGx5IHJlc3RvcmVkIHdoZW4gc3RhcnRlZCBmcm9tIGEg bGlzdCBpY29uDQogIC0gcmVtb3ZlZCBuYXN0eSBHUEYgZnJvbSBPcGVuIERpYWxvZw0KDQo+ PiAyLjI1ID09PiAyLjMwIDw8DQoNCisgYWRkZWQgc3VwcG9ydCBmb3IgdGhlIFhNIEZvcm1h dA0KKyBTdXJyb3VuZCBTb3VuZCBvcHRpb24gaW4gR0YxIE1vZGUgZm9yIG1vZHVsZXMgd2l0 aCBsZXNzIHRoYW4gOCBjaGFubmVscw0KKiBFZmZlY3QgUGFuZWwgZGlzcGxheSBpcyBtb3Jl IGxpdmVseSBub3cgaW4gREFDIG1vZGUNCiogYnVnIGZpeGVzDQogIC0gc29tZSBFZmZlY3Rz IHdoZXJlIHBsYXllZCB3cm9uZyBmb3IgdGhlIE1PRCBGb3JtYXQNCiAgLSBmaXhlZCBHUEYg aW4gUXVpY2sgU2VsZWN0aW9uIEJveA0KICAtIGZpeGVkIHN0aWNreSBGYXN0IEZvcndhcmQg YW5kIFJld2luZCBidXR0b25zIHdoZW4gZXh0cmFjdGluZyBhcmNoaXZlcw0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KDQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KKiBUaGUgZm9sbG93 aW5nIGNoYXB0ZXJzIGFyZSBhbGwgaW5jbHVkZWQgaW4gdGhlIE1vZDRXaW4gSGVscCBmaWxl IGFuZCAgICoNCiogcmVhbGx5IGxvb2sgbXVjaCBiZXR0ZXIgdGhlcmUuICBPZiBjb3Vyc2Us IGlmIHlvdSBhYnNvbHV0ZWx5IGxvdmUgdGV4dCAqDQoqIGZpbGVzLCB5b3UgY2FuIHN0dWR5 IGl0IGhlcmUuIAkJCQkJICoNCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQoNCkZlYXR1cmVzDQotLS0tLS0tLQ0KDQpNb2Q0V2luIGlzIGEgcGxh eWVyIGZvciBkaWdpdGFsIG11c2ljIG1vZHVsZXMgb24gSUJNLVBDIGNvbXBhdGlibGUgbWFj aGluZXMgDQpydW5uaW5nIE1pY3Jvc29mdCBXaW5kb3dzLg0KDQotIE1vZDRXaW4gMi4zMCBz dXBwb3J0czoNCiAgKiBOb2lzZVRyYWNrZXIgKCouTlNUKSwgUHJvLSwgRmFzdC0sIGFuZCBU YWtlVHJhY2tlciAoKi5NT0QpLCBHcmF2ZSBDb21wb3NlciANCiAgICAoKi5XT1cpLCBPa3Rh bHl6ZXIgKCouT0tUKSwgU2NyZWFtVHJhY2tlciAyLnggKCouU1RNKSwgU2NyZWFtVHJhY2tl ciAzLnggDQogICAgKCouUzNNKSwgQ29tcG9zZXIgNjY5IGFuZCBVTklTIDY2OSAoKi42Njkp LCBGYXJhbmRvbGUgQ29tcG9zZXIgKCouRkFSKSwgDQogICAgTXVsdGlUcmFja2VyICgqLk1U TSksIGFuZCBGYXN0VHJhY2tlciBJSSAoKi5YTSkgbW9kdWxlcw0KICAqIFNhbXBsZSByYXRl cyBiZXR3ZWVuIDExIGFuZCA0OCBrSHoNCiAgKiA4IGFuZCAxNiBiaXQgc2FtcGxlIGRlcHRo DQogICogTW9ubywgU3RlcmVvLCBhbmQgU3RlcmVvIFN1cnJvdW5kIFNvdW5kDQogICogSW50 ZXJwb2xhdGVkIER5bmFtaWMgT3ZlcnNhbXBsaW5nIChJRE8pDQogICogRGlyZWN0IEhhcmR3 YXJlIFN1cHBvcnQNCiAgKiBEaXJlY3QgVG8gRGlzayBSZWNvcmRpbmcNCg0KLSBGdWxsIGFy Y2hpdmUgc3VwcG9ydA0KICAqIFN1cHBvcnRzIEFSSiAoKi5BUkopLCBMSEFSQyAoKi5MSEEs ICouTFpIKSwgYW5kIFBLWklQICgqLlpJUCkNCg0KLSBKdWtlYm94IGZ1bmN0aW9uIGZvciB1 cCB0byAyOTk5IE1PRC1GaWxlcyBpbiBvbmUgc2Vzc2lvbg0KICAqIEdlbmVyYXRlcyBwbGF5 bGlzdHMgKCouTU9MKSB3aXRoIGZpbGVzIGZyb20gdXAgdG8gMjAwIGRpcmVjdG9yaWVzIG9y IA0KICAgIGFyY2hpdmVzDQogICogRHJhZyAmIERyb3AgZmVhdHVyZSBvZiBvbmUgb3IgbW9y ZSBtb2R1bGVzLCBhcmNoaXZlcywgYW5kIHBsYXlsaXN0cw0KICAqIExhdW5jaGluZyBvZiBh IG1vZHVsZSwgYXJjaGl2ZSBvciBwbGF5bGlzdCBmcm9tIGEgY29tbWFuZCBsaW5lIHBhcmFt ZXRlcg0KDQotIEludHVpdGl2ZSBhbmQgZWFzeSB0byB1c2UgaW50ZXJmYWNlIHdpdGggY29t cGxleCBmdW5jdGlvbmFsaXR5DQogICogSG90a2V5cyBmb3IgYWxsIHBsYXllciBmdW5jdGlv bnMsIG1hbnkgb2YgdGhlbSB1c2VyLWRlZmluYWJsZQ0KICAqIE1pbmkgU3RhdHVzIHVzZXMg bWluaW1hbCBkZXNrdG9wIHNwYWNlIGFuZCBzdGF5cyBvcHRpb25hbGx5IGFsd2F5cyBvbiB0 b3ANCiAgKiBFZmZlY3QgUGFuZWwgc2hvd3MgY3VycmVudCBlZmZlY3RzLCBpbnN0cnVtZW50 cywgbm90ZXMsIHZvbHVtZXMsIGFuZCBzcGVlZA0KICAqIEludGVncmF0ZWQgRmlsZSBNYW5h Z2VyIHRvIGNvcHksIG1vdmUvcmVuYW1lLCBhbmQgZGVsZXRlIG1vZHVsZXMgZnJvbSBhbmQg DQogICAgaW50byBkcml2ZXMsIGRpcmVjdG9yaWVzLCBhcmNoaXZlcywgYW5kIGxpc3QgZmls ZXMNCiAgKiBRdWljayBTZWxlY3Rpb24gQm94IGRpc3BsYXlzIGFsbCBtb2R1bGVzIGluIHlv dXIgY3VycmVudCBwbGF5bGlzdCBhbmQgbGV0cyANCiAgICB5b3Ugc2VsZWN0IG9uZSBpbW1l ZGlhdGVseQ0KICAqIFVzZXIgUmVnaXN0cmF0aW9uIERpYWxvZyBzaW1wbGlmaWVzIHRoZSBy ZWdpc3RyYXRpb24gcHJvY2Vzcw0KDQotIE1vZDRXaW4gc2F2ZXMgYWxsIHNldHRpbmdzLCBz dWNoIGFzDQogICogd2luZG93IHBvc2l0aW9ucw0KICAqIGxhc3QgYWNjZXNzZWQgZGlyZWN0 b3JpZXMNCiAgKiBzb3VuZCBjYXJkIGFuZCB3YXZlIGRyaXZlciBzZXR0aW5ncw0KICAqIG9w dGlvbmFsbHkgdGhlIGNvbXBsZXRlIGN1cnJlbnQgc3RhdHVzLCBzbyB0aGUgbmV4dCBzZXNz aW9uIHdpbGwgc3RhcnQgDQogICAgZXhhY3RseSB3aGVyZSB5b3Ugc3RvcHBlZCB0aGUgbGFz dCBvbmUNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KU3lzdGVtIHJlcXVpcmVtZW50 cw0KLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpTb3VuZDoNCi0gQSBzb3VuZCBjYXJkIHdpdGgg YXQgbGVhc3Qgb25lIERBQyB0aGF0IGNhbiBwcm9jZXNzIHNhbXBsaW5nIGF0IDExIGtIeiBv ciANCiAgYmV0dGVyIGFuZCBhbiBhcHByb3ByaWF0ZSBhc3luY2hyb25vdXMgd2F2ZSBkcml2 ZXIsIGFsc28ga25vd24gYXMgYW4gTVBDLTIgDQogIGNvbXBhdGlibGUgd2F2ZSBkZXZpY2Uu DQogIC0gb3IgLQ0KLSBBIHNvdW5kIGNhcmQgdGhhdCBpcyBkaXJlY3RseSBzdXBwb3J0ZWQg aW4gaGFyZHdhcmUgKE9QTDQgYmFzZWQgY2FyZCB3aXRoDQogIG9uYm9hcmQgUkFNIG9yIEdy YXZpcyBVbHRyYXNvdW5kKQ0KLSBOb3RlOiBEQUMgZW11bGF0b3JzIGxpa2Ugc3BlYWtlci5k cnYgY2Fubm90IGJlIHN1cHBvcnRlZC4gIEluIGRpcmVjdCB0byBkaXNrDQogIHJlY29yZGlu ZyBtb2RlIHRoZXJlIGlzIG5vIHNwZWNpYWwgc291bmQgaGFyZHdhcmUgcmVxdWlyZWQuDQoN ClByb2Nlc3NvcjoNCi0gQVQgMzg2IFNYLzE2IGFzIHRoZSBhYnNvbHV0ZSBtaW5pbXVtIHRv IHJ1biB0aGUgcHJvZ3JhbS4NCi0gQVQgMzg2IERYLzIwIGZvciBwbGF5aW5nIGF0IHRoZSBo aWdoZXN0IHNhbXBsZSByYXRlLg0KLSBBVCA0ODYgRFgvMzMgd2l0aCA4IE1CIFJBTSB0byB1 c2UgTW9kNFdpbiBhcyBhIGJhY2tncm91bmQganVrZWJveCBhdCA0NCBrSHogDQogIGFuZCAx NiBiaXQgc3RlcmVvIHNhbXBsaW5nLg0KLSBOb3RlOiBUbyBwbGF5IG1vZHVsZXMgd2l0aCBt b3JlIHRoYW4gOCBjaGFubmVscyB1c2luZyBJRE8gYW5kIHBhbm5pbmcsIGEgDQogIGZhc3Rl ciBwcm9jZXNzb3IgbWF5IGJlIHJlcXVpcmVkLiAgSW4gZGlyZWN0IHRvIGRpc2sgcmVjb3Jk aW5nIG1vZGUgYW5kDQogIGRpcmVjdCBoYXJkd2FyZSBzdXBwb3J0IG1vZGUsIGFueSBBVCAz ODYgb3IgYmV0dGVyIGlzIHN1ZmZpY2llbnQgdG8gcnVuIHRoZQ0KICBwcm9ncmFtLg0KDQpW aWRlbzoNCi0gQSBWR0EgdmlkZW8gYWRhcHRlciB3aXRoIGF0IGxlYXN0IDE2IGNvbG9ycyBz aW11bHRhbmVvdXNseS4NCi0gU3VnZ2VzdGVkIHZpZGVvIHJlc29sdXRpb24gODAwIHggNjAw IHRvIHNob3cgdGhlIE1haW4gRGlhbG9nLCBJbmZvIERpYWxvZywgDQogIGFuZCBFZmZlY3Qg UGFuZWwgd2l0aG91dCBvdmVybGFwcGluZy4NCi0gTm90ZTogV2l0aCBhIEhlcmN1bGVzIG9y IE1vbm9jaHJvbWUgYWRhcHRlciBtYW55IG9mIHRoZSBkaWFsb2dzIHdpbGwgDQogIGFwcGVh ciB1bnJlYWRhYmxlLg0KDQpPcGVyYXRpbmcgU3lzdGVtOg0KLSBNaWNyb3NvZnQgV2luZG93 cyAzLjEgb3IgaGlnaGVyIHJ1bm5pbmcgaW4gMzg2IGVuaGFuY2VkIG1vZGUuDQotIE5vdGU6 IFRoaXMgdmVyc2lvbiBvZiBNb2Q0V2luIHdpbGwgbm90IHJ1biBvbiAyODYtYmFzZWQgbWFj aGluZXMgYW55bW9yZSwgDQogIG5laXRoZXIgd2lsbCBpdCBydW4gdW5kZXIgV2luZG93cyBp biBzdGFuZGFyZCBtb2RlLiAgVGhlcmUgaXMgbm8gc3BlY2lhbA0KICBzdXBwb3J0IGZvciBX aW5kb3dzIDk1IGF0IHRoaXMgcG9pbnQuDQoNCkZvciBhIG1vcmUgZGV0YWlsZWQgZGlzY3Vz c2lvbiBvZiBTeXN0ZW0gUmVxdWlyZW1lbnRzIHNlZSBhbHNvIHRoZSBzZWN0aW9ucw0KS25v d24gUHJvYmxlbXMgYW5kIEZyZXF1ZW50bHkgYXNrZWQgUXVlc3Rpb25zIChGQVEpIGluIHRo ZSBXaW5kb3dzIGhlbHAgZmlsZS4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KQXV0 aG9ycw0KLS0tLS0tLQ0KDQpNb2Q0V2luIGlzIGEgam9pbnQgcHJvamVjdCBiZXR3ZWVuIEth eSBCcnVucywgVXdlIFphZW5rZXIsIGFuZCBKZW5zIFB1Y2hlcnQuDQoNCkZvciBhIGRldGFp bGVkIHJ1bmRvd24gb24gd2hvIGRpZCB3aGF0IGluIE1vZDRXaW4gcGxlYXNlIHNlZSB0aGUg QXV0aG9ycw0Kc2VjdGlvbiBpbiB0aGUgV2luZG93cyBoZWxwIGZpbGUuDQoNCklmIHlvdSBm aW5kIGFueSBwcm9ibGVtcyB3aXRoIHRoZSBwcm9ncmFtIG9yIHdvdWxkIGxpa2UgdG8gY29t bWVudCBvbiBhbnl0aGluZywNCml0J3MgYmVzdCB0byBjb250YWN0IHRoZSBwZXJzb24gcmVz cG9uc2libGUgZm9yIHRoZSBwYXJ0aWN1bGFyIHNlY3Rpb24gb2YgdGhlIA0KcHJvZ3JhbSB5 b3UnZCBsaWtlIHRvIGNvbW1lbnQgb24uICBGb3IgY29udGFjdCBpbmZvcm1hdGlvbiBwbGVh c2UgcmVmZXIgdG8gdGhlDQpBdXRob3JzIHNlY3Rpb24gaW4gdGhlIFdpbmRvd3MgaGVscCBm aWxlLg0KDQpJZiB5b3UgaGF2ZSBnZW5lcmFsIHF1ZXN0aW9ucyBhYm91dCBNb2Q0V2luLCBx dWVzdGlvbnMgcmVnYXJkaW5nIHJlZ2lzdHJhdGlvbiANCmFuZCBwYXltZW50LCBvciBkZWFs ZXIgaW5xdWlyaWVzLCBwbGVhc2UgY29udGFjdCBLYXkgQnJ1bnMgb3IgVXdlIFrkbmtlciAo aWYgDQp5b3UgbGl2ZSBpbiBFdXJvcGUpLCBvciBKZW5zIFB1Y2hlcnQgKGlmIHlvdSBsaXZl IGluIHRoZSBVbml0ZWQgU3RhdGVzIG9yIA0KYW55d2hlcmUgZWxzZSBvdXRzaWRlIG9mIEV1 cm9wZSkuDQoNCk5vdGU6IEJlZm9yZSB5b3UgY29udGFjdCBhbnkgb25lIG9mIHVzLCBwbGVh c2UgY2hlY2sgdGhlIEZyZXF1ZW50bHkgYXNrZWQgDQpRdWVzdGlvbnMgKEZBUSkgc2VjdGlv biBpbiB0aGUgV2luZG93cyBoZWxwIGZpbGUuICBZb3VyIHF1ZXN0aW9uIG1heSBhbHJlYWR5 IA0KYmUgYW5zd2VyZWQgdGhlcmUgYW5kIHlvdSBjYW4gc2F2ZSB5b3Vyc2VsZiBhbmQgdXMg c29tZSB2YWx1YWJsZSB0aW1lLg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpUcm91 YmxlIFNob290aW5nDQotLS0tLS0tLS0tLS0tLS0tDQoNCkZvciBhIGRldGFpbGVkIGRpc2N1 c3Npb24gb24gdHJvdWJsZSBzaG9vdGluZyBzZWUgdGhlIHNlY3Rpb25zIGFib3V0DQoNCi0g S25vd24gUHJvYmxlbXMgYW5kDQotIEZyZXF1ZW50bHkgQXNrZWQgUXVlc3Rpb25zIChGQVEp DQoNCmluIHRoZSBXaW5kb3dzIGhlbHAgZmlsZS4NCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCg0KU2hhcmV3YXJlIE5vdGVzDQotLS0tLS0tLS0tLS0tLS0NCg0KKiBEaWZmZXJlbmNl cyBiZXR3ZWVuIFNoYXJld2FyZS0gYW5kIEZ1bGwgVmVyc2lvbiAqDQoNClByaW5jaXBhbGx5 IHNoYXJld2FyZS0gYW5kIGZ1bGwgdmVyc2lvbiBhcmUgZXF1YWxseSBwb3dlcmZ1bC4gIFdl IGZpZ3VyZWQgdGhhdCANCmEgbGltaXRlZCBzaGFyZXdhcmUgdmVyc2lvbiBtYWtlcyBubyBz ZW5zZSwgYmVjYXVzZSB5b3UgY2FuJ3QgdGVzdCBhbmQgZXZhbHVhdGUNCmEgZmVhdHVyZSB0 aGF0IGhhc24ndCBiZWVuIGltcGxlbWVudGVkIGluIHlvdXIgZnJlZSBkZW1vLiAgSG93ZXZl ciwgZXhwZXJpZW5jZSANCnNob3dzIHRoYXQgaXQgaXMgbmVjZXNzYXJ5IHRvIGxpbWl0IHRo ZSBmcmVlIGRlbW8gdmVyc2lvbiBpbiBzb21lIHdheSBhbmQgDQppbnN0ZWFkIG9mIHJlbW92 aW5nIGZlYXR1cmVzLCB3ZSBsZXQgeW91IGVuam95IGEgZnJlZSAzMCBkYXkgdHJpYWwgcGVy aW9kIGluIA0Kd2hpY2ggeW91IGNhbiBldmFsdWF0ZSB0aGUgcHJvZ3JhbSBmcmVlIG9mIHJl c3RyaWN0aW9ucy4gIEV4ZW1wdCBmcm9tIHRoYXQgaXMgDQp0aGUgYWJpbGl0eSB0byBzYXZl IHlvdXIgb3duIHBsYXlsaXN0cyB3aGljaCBpcyBvbmx5IGFsbG93ZWQgaWYgeW91IGxpY2Vu c2UgYSANCmZ1bGwgdmVyc2lvbi4NCg0KSWYgeW91IGZpbmQgdGhlIHByb2dyYW0gdXNlZnVs IHRvIHlvdSBhbmQgd291bGQgbGlrZSB0byB1c2UgaXQgYmV5b25kIHlvdXIgMzAgDQpkYXkg ZnJlZSB0cmlhbCBwZXJpb2QgeW91IHdpbGwgaGF2ZSB0byBvYnRhaW4gYSBmdWxsIHZlcnNp b24gdGhyb3VnaCANClJlZ2lzdHJhdGlvbi4gIFRoZSBmcmVlIGRlbW8gdmVyc2lvbiB3aWxs IHJlbWluZCB5b3UgdGhhdCB5b3UgaGF2ZW4ndCANCnJlZ2lzdGVyZWQgeWV0IGV2ZXJ5IHRp bWUgeW91IHN0YXJ0IGFuZCBzaHV0IGRvd24gTW9kNFdpbi4gIE9mIGNvdXJzZSB5b3Ugd2ls bCANCmJlIHNwYXJlZCBhbGwgb2YgdGhpcywgaWYgeW91IHB1cmNoYXNlIGEgY29weSBvZiB0 aGUgZnVsbCB2ZXJzaW9uIG9mIHRoZSANCnByb2dyYW0uICBZb3VyIHJlZ2lzdGVyZWQgY29w eSBvZiBNb2Q0V2luIHdpbGwgYWxzbyBzaG93IHlvdXIgbmFtZSBpbiB0aGUgDQpjYXB0aW9u IG9mIHRoZSBNYWluIERpYWxvZyBhbmQgaW4gdGhlIGNyZWRpdCBzY3JvbGwgb2YgdGhlIEFi b3V0IERpYWxvZy4NCg0KKiBEb2N1bWVudGF0aW9uICoNCg0KU2luY2UgTW9kNFdpbiBpcyBz byBlYXN5IGFuZCBpbnR1aXRpdmUgdG8gdXNlLCB3ZSBkb24ndCBmaW5kIGl0IG5lY2Vzc2Fy eSB0byANCmlzc3VlIHByaW50ZWQgZG9jdW1lbnRhdGlvbiBmb3IgaXQuICBUaGUgaHlwZXJs aW5rZWQgV2luZG93cyBoZWxwIHN5c3RlbSBpcyANCm5ldmVyIG1vcmUgdGhhbiBvbmUga2V5 c3Ryb2tlIGF3YXkgKGp1c3QgaGl0IEYxIGZyb20gYW55IGRpYWxvZykuICBJZiB5b3UgDQp3 b3VsZCBsaWtlIHRvIGhhdmUgc29tZXRoaW5nIG9uIHBhcGVyLCBmZWVsIGZyZWUgdG8gc3Bv b2wgdGhpcyBoZWxwIHRleHQgdG8gDQp5b3VyIHByaW50ZXIgb3IgdG8gYSBmaWxlLg0KDQoq IFJldGFpbCBTYWxlcyBvZiB0aGUgRnVsbCBWZXJzaW9uICoNCg0KTW9kNFdpbiBpcyBub3Qg YXZhaWxhYmxlIGFzIGEgcmV0YWlsIHByb2R1Y3QgYXQgdGhpcyBwb2ludC4gIFRvIG9idGFp biBhIA0KcmVnaXN0ZXJlZCBmdWxsIHZlcnNpb24gcGxlYXNlIGZvbGxvdyB0aGUgaW5zdHJ1 Y3Rpb25zIHVuZGVyIFJlZ2lzdHJhdGlvbi4NCg0KKiBVcGRhdGUgU2VydmljZSAqDQoNClJl Z2lzdGVyZWQgdXNlcnMgYWx3YXlzIGdldCBhIGdyZWF0IGRpc2NvdW50IG9uIHVwZGF0ZWQg cmVsZWFzZXMuICBEZXBlbmRpbmcgDQpvbiBob3cgYmlnIGEgc3RlcCB0aGVyZSBpcyBiZXR3 ZWVuIHlvdXIgYW5kIHRoZSBjdXJyZW50IHZlcnNpb24sIHByaWNlcyByYW5nZSANCmZyb20g ZnJlZSB1cGRhdGVzIHRvIGFib3V0IGhhbGYgdGhlIHByaWNlIG9mIHRoZSBmdWxsIHZlcnNp b24uICBGb3IgZGV0YWlscyANCnBsZWFzZSByZWZlciB0byB0aGUgc2VjdGlvbiBSZWdpc3Ry YXRpb24gaW4gdGhlIFdpbmRvd3MgaGVscCBmaWxlLg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KDQpMaWNlbnNlIFJlZ3VsYXRpb25zDQotLS0tLS0tLS0tLS0tLS0tLS0tDQoNCjEu IEFsbCBhdHRlbXB0cyB0byBkZWZlYXQgdGhlIHNoYXJld2FyZSBjaGVjayBhbmQgdGhlIDMw IGRheXMgdHJpYWwgcGVyaW9kIA0KICAgbGltaXQgYXJlIGEgdmlvbGF0aW9uIG9mIG91ciBj b3B5cmlnaHQgYW5kIHN0cmljdGx5IHByb2hpYml0ZWQuICBJZiBzdWNoIA0KICAgYXR0ZW1w dHMgYmVjb21lIGtub3duIHdlIHJlc2VydmUgdGhlIGxlZ2FsIHJpZ2h0IHRvIHByb3NlY3V0 ZSB0aGUgDQogICBvZmZlbmRpbmcgcGFydHkuDQoNCjIuIE1vZGlmaWNhdGlvbiBvZiBhIGZp bGUgdGhhdCBiZWxvbmdzIHRvIHRoZSBNb2Q0V2luIHBhY2thZ2UgaXMgc3RyaWN0bHkgDQog ICBwcm9oaWJpdGVkIQ0KDQozLiBEaXNhc3NlbWJsaW5nLCByZXZlcnNlIGVuZ2luZWVyaW5n LCBwYXRjaGluZywgaGFja2luZywgb3IgY3JhY2tpbmcgb2YgdGhpcyANCiAgIHByb2dyYW0s IGFzIHdlbGwgYXMgZGlzdHJpYnV0aW9uIG9mIGFueSBtYXRlcmlhbCB0aGUgZW5jb3VyYWdl cyBvciBhc3Npc3RzIA0KICAgaW4gYW55IG9mIHRoZXNlIGFjdGl2aXRpZXMgaXMgc3RyaWN0 bHkgcHJvaGliaXRlZC4gIEFueSB2aW9sYXRpb24gYWdhaW5zdCANCiAgIHRoaXMgcnVsZSBj b25zdGl0dXRlcyBjb3B5cmlnaHQgZnJhdWQgYW5kIG1heSBiZSBzdWJqZWN0IHRvIHByb3Nl Y3V0aW9uIA0KICAgdW5kZXIgY29weXJpZ2h0IGxhdy4NCg0KNC4gUG9zc2Vzc2lvbiBvZiB0 aGUgcmVnaXN0ZXJlZCB2ZXJzaW9uIGlzIHBlcm1pdHRlZCBvbmx5IHRvIHRoZSByZWdpc3Rl cmVkIA0KICAgdXNlci4NCg0KTm90ZSBlc3BlY2lhbGx5IHdlbGw6IFRoZSBzYW1wbGUgbW9k dWxlcyBpbmNsdWRlZCBpbiB0aGUgZGlzdHJpYnV0aW9uIHBhY2thZ2UgDQogICAgICAgICAg ICAgICAgICAgICAgb2YgTW9kNFdpbiBhcmUgY29weXJpZ2h0IG9mIHRoZWlyIHJlc3BlY3Rp dmUgb3duZXJzLg0KDQpVc2VycyBvZiBhbnkgdmVyc2lvbiBvZiBNb2Q0V2luIGltcGxpY2l0 bHkgYWdyZWUgdG8gYWxsIGxpY2Vuc2UgcmVndWxhdGlvbnMgDQp3aGVuIHRoZXkgaW5zdGFs bCB0aGUgc29mdHdhcmUgb24gdGhlaXIgbWFjaGluZS4NCg0KRm9yIGRldGFpbGVkIGV4cGxh bmF0aW9uIG9mIGFsbCBsaWNlbnNpbmcgcmVndWxhdGlvbnMgcGxlYXNlIHJlZmVyIHRvIHRo aXMNCnNlY3Rpb24gaW4gdGhlIFdpbmRvd3MgaGVscCBmaWxlLg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KDQpMaWFiaWxpdHksIFdhcnJhbnR5IGFuZCBUcmFkZW1hcmsNCi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpXZSwgdGhlIEF1dGhvcnMsIG1ha2Ug bm8gd2FycmFudHkgb2YgYW55IGtpbmQsIGV4cHJlc3NlZCBvciBpbXBsaWVkLCBpbmNsdWRp bmcgDQpidXQgbm90IGxpbWl0ZWQgdG8gYW55IHdhcnJhbnRpZXMgb2YgZml0bmVzcyBmb3Ig YSBwYXJ0aWN1bGFyIHB1cnBvc2UuICBJbiBubyANCmV2ZW50IHNoYWxsIHRoZSBhdXRob3Jz IGJlIGxpYWJsZSBmb3IgYW55IGluY2lkZW50YWwgb3IgY29uc2VxdWVudGlhbCBkYW1hZ2Ug DQphcmlzaW5nIGZyb20gdGhlIHVzZSBvZiwgb3IgaW5hYmlsaXR5IHRvIHVzZSwgdGhpcyBw cm9ncmFtLiAgV2UgaGVyZWJ5IGRlbnkgDQphbnkgbGlhYmlsaXR5IHRvIHRoZSBtYXhpbXVt IGV4dGVudCBwZXJtaXR0ZWQgYnkgbGF3Lg0KDQpZb3UgYXJlIGZ1bGx5IHJlc3BvbnNpYmxl IGZvciBldmVyeXRoaW5nIHlvdSBhcmUgZG9pbmcgd2l0aCB0aGlzIHByb2dyYW0hDQoNCldl IHJlc2VydmUgYWxsIHJpZ2h0cyBmb3Igb3VyIHByb2dyYW0uDQoNCk1vZDRXaW4gYW5kIElE TyBhcmUgdHJhZGVtYXJrcyBvZiBKU0luYy4gYW5kIFNXRSBCcnVucyAmIFrkbmtlci4NCg0K Rm9yIGEgbW9yZSBkZXRhaWxlZCBleHBsYW5hdGlvbiBvZiBsaWFiaWxpdHksIHdhcnJhbnR5 LCBhbmQgdHJhZGVtYXJrIHBsZWFzZQ0KcmVmZXIgdG8gdGhpcyBzZWN0aW9uIGluIHRoZSBX aW5kb3dzIGhlbHAgZmlsZS4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KUmVnaXN0 cmF0aW9uIGZvciBNb2Q0V2luIDIuMzANCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQoNClRoZSBiYXNpYyByZWdpc3RyYXRpb24gcHJvY2VkdXJlIGlzIHNpbXBsZS4gIEp1c3Qg ZmlsbCBvdXQgdGhlIFJlZ2lzdHJhdGlvbiANCkZvcm0sIGFuZCBzZW5kIGl0IHdpdGggdGhl IHByb3BlciBQYXltZW50IHRvIHlvdXIgZGlzdHJpYnV0b3IuICBEZXBlbmRpbmcgb24gDQp3 aGVyZSB5b3UgbGl2ZSwgeW91IHdpbGwgYmUgc2VydmVkIGJ5IGRpZmZlcmVudCBkaXN0cmli dXRvcnMgYW5kIHNsaWdodGx5IA0KZGlmZmVyZW50IHJlZ2lzdHJhdGlvbiBwcm9jZWR1cmVz IGFwcGx5LiAgRm9yIGRldGFpbHMgcGxlYXNlIHJlZmVyIHRvIHRoZQ0Kc2VjdGlvbiBvbiBS ZWdpc3RyYXRpb24gaW4gdGhlIFdpbmRvd3MgaGVscCBmaWxlLg0KDQpJZiB5b3UgYXJlIHN1 YnNjcmliZWQgdG8gQ29tcHVzZXJ2ZSBJbmZvcm1hdGlvbiBTZXJ2aWNlLCB5b3UgY2FuIGFs c28gcmVnaXN0ZXIgDQpyaWdodCBmcm9tIHRoZSBjb252ZW5pZW5jZSBhbmQgcHJpdmFjeSBv ZiB5b3VyIG1vbml0b3IuICBHbyB0byB0aGUgU1dSRUcgZm9ydW0sDQpJRCAjNDEzOCBhbmQg Zm9sbG93IHRoZSBpbnN0cnVjdGlvbnMgdGhlcmUuDQoNCkZvciB1cCB0byBkYXRlIGluZm8g b24gY3JlZGl0IGNhcmRzLCBwcm9kdWN0IHVwZGF0ZXMsIGFuZCBtb3JlIGNoZWNrIG91ciAN CnByZWxpbWluYXJ5IFdvcmxkIFdpZGUgV2ViIHBhZ2UgYXQgaHR0cDovL3NjdXp6eS5mbW1v LmNhL21lZGlhdHJpeC9tb2Q0d2luLmh0bQ0KKGNvdXJ0ZXN5IG9mIE1lZGlhdHJpeCBQZXJp cGhlcmFscywgSW5jLikuDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNClByaWNlIENo YXJ0IGZvciBNb2Q0V2luIDIuMzANCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0K bmV3IHVzZXIgcmVnaXN0cmF0aW9uIGZlZTogJDMwDQp1cGRhdGUgZnJvbSAxLnh4OiAgICAg ICAgICAkMTUNCnVwZGF0ZSBmcm9tIDIuMDA6ICAgICAgICAgICQxMg0KdXBkYXRlIGZyb20g Mi4xeDogICAgICAgICAgJDEwDQp1cGRhdGUgZnJvbSAyLjJ4OiAgICAgICAgICBGUkVFDQoN CklmIHlvdSBhbHJlYWR5IGhhdmUgYSBjb3B5IG9mIHRoZSBmcmVlIGRlbW8gdmVyc2lvbiBv ZiBNb2Q0V2luIDIuMzAgdGhlcmUgd2lsbA0KYmUgbm8gYWRkaXRpb25hbCBjaGFyZ2UgZm9y IHNlbmRpbmcgeW91IHRoZSByZWdpc3RyYXRpb24gY29kZS4NCg0KSWYgeW91IGRvIG5vdCBo YXZlIGEgY29weSBvZiB0aGUgZnJlZSBkZW1vIHZlcnNpb24gb2YgTW9kNFdpbiAyLjMwIGFu ZCByZXF1aXJlIA0KYSBkaXNrIHdpdGggdGhlIHJlZ2lzdGVyZWQgdmVyc2lvbiB0byBiZSBz ZW50IG91dCB0byB5b3UgdGhlcmUgd2lsbCBiZSBhbiANCmFkZGl0aW9uYWwgJDUgc2hpcHBp bmcgYW5kIGhhbmRsaW5nIGNoYXJnZSBwZXIgb3JkZXIuDQoNCllvdSBhcmUgbm8gbG9uZ2Vy IHJlcXVpcmVkIHRvIHByb3ZpZGUgYSBzZWxmLWFkZHJlc3NlZCBlbnZlbG9wZS4gIFNoaXBw aW5nIGlzIA0KZG9uZSB2aWEgZmlyc3QgY2xhc3MgbWFpbCB3aXRoaW4gdGhlIFVuaXRlZCBT dGF0ZXMgYW5kIENhbmFkYSwgYW5kIHZpYSBhaXIgbWFpbA0KZXZlcnl3aGVyZSBlbHNlLiAg RGlza3MgYXJlIGdlbmVyYWxseSBpbiAzLjUiIERTLUhEIGZvcm1hdC4gIEZvciBtYXhpbWFs IA0KcHJvdGVjdGlvbiwgYWxsIGRpc2tzIGFyZSBzZW50IGluIGEgYnViYmxlIG1haWxlci4N Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KUmVnaXN0cmF0aW9uIEZvcm0gZm9yIE1v ZDRXaW4gMi4zMA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpQbGVh c2UgcHJpbnQgdGhlIHJlZ2lzdHJhdGlvbiBmb3JtIGZyb20gdGhlIFdpbmRvd3MgaGVscCBm aWxlIChjbGljayBvbiANCkNvbnRlbnRzIGFuZCB0aGVuIG9uIFJlZ2lzdHJhdGlvbiBGb3Jt KS4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KRmluYWwgV29yZHMNCi0tLS0tLS0t LS0tDQoNCkhhdmUgZnVuIHdpdGggTW9kNFdpbiENCg0KICAgICAgIFx8Lw0KICAgICAgKC4g LikNCiAgICAgICggfCApDQogICAgICAoIHYgKQ0KICAgICBfX3wgfF9fDQogICAgLyAgICAg ICBcDQ=9 --PNnNYkX839Mh969jK9c09G7-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 26 03:43:34 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5QAhYk7001424; Wed, 26 Jun 2002 03:43:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5QAhXUD001423; Wed, 26 Jun 2002 03:43:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5QAhUk7001416 for ; Wed, 26 Jun 2002 03:43:30 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA29776 for ; Wed, 26 Jun 2002 03:43:35 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA10620 for ; Wed, 26 Jun 2002 03:43:34 -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 GAA10795; Wed, 26 Jun 2002 06:42:48 -0400 (EDT) Message-Id: <200206261042.GAA10795@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-miyakawa-ipv6-prefix-delegation-requirement-00.txt Date: Wed, 26 Jun 2002 06:42:47 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Requirements for IPv6 prefix delegation Author(s) : S. Miyakawa Filename : draft-miyakawa-ipv6-prefix-delegation- requirement-00.txt Pages : 5 Date : 25-Jun-02 This document describes requirements about how an IPv6 address prefix should be delegated to an IPv6 subscriber's network (or 'site'). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-miyakawa-ipv6-prefix-delegation-requirement-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-miyakawa-ipv6-prefix-delegation-requirement-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-miyakawa-ipv6-prefix-delegation-requirement-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: <20020625142036.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-miyakawa-ipv6-prefix-delegation-requirement-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-miyakawa-ipv6-prefix-delegation-requirement-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020625142036.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 Jun 26 10:40:10 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5QHeAk7002642; Wed, 26 Jun 2002 10:40:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5QHe999002641; Wed, 26 Jun 2002 10:40:09 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5QHe5k7002634 for ; Wed, 26 Jun 2002 10:40:05 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA18894 for ; Wed, 26 Jun 2002 10:40:10 -0700 (PDT) Received: from esunmail ([129.147.58.122]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA26987 for ; Wed, 26 Jun 2002 11:40:09 -0600 (MDT) Received: from xpa-fe1 (esunmail-ge1 [129.147.58.122]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 0.3 (built May 13 2002)) with ESMTP id <0GYB00INPQEUVN@edgemail1.Central.Sun.COM> for ipng@sunroof.eng.sun.com; Wed, 26 Jun 2002 11:40:09 -0600 (MDT) Received: from localhost ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 0.2 (built Apr 26 2002)) with ESMTPSA id <0GYB007XWQETFX@mail.sun.net> for ipng@sunroof.eng.sun.com; Wed, 26 Jun 2002 11:40:06 -0600 (MDT) Date: Wed, 26 Jun 2002 10:40:04 -0700 From: Alain Durand Subject: Re: I-D ACTION:draft-ietf-ipv6-default-addr-select-08.txt In-reply-to: <4.3.2.7.2.20020625142522.0268e188@mailhost.iprg.nokia.com> To: Bob Hinden Cc: Keith Moore , ipng@sunroof.eng.sun.com Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.482) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tuesday, June 25, 2002, at 02:56 PM, Bob Hinden wrote: > > Other views on this? > > Bob There has been a very long discussion on the fate of Site Local addresses in the wg. There are still two opposite views of what to do about them: a) Do not require apps to support multi-sited nodes now, but keep the address selection rules in place. This means that in the future, if SL are available, they will be used by ALL applications by default. b) Do not require apps to support multi-sited nodes now, and remove the address selection rule that deal with scoped addresses. This means that in the future, if SL are available, they will not be used by default, but only by applications that request them. Keith has promised a draft to explain the trade-off between those two approaches, I think we should not advance draft-ietf-ipv6-default-addr-select-08.txt until there is a clear resolution on this question. - 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 Jun 26 11:39:32 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5QIdVk7002693; Wed, 26 Jun 2002 11:39:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5QIdVb1002692; Wed, 26 Jun 2002 11:39:31 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5QIdSk7002685 for ; Wed, 26 Jun 2002 11:39:28 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA14443 for ; Wed, 26 Jun 2002 11:39:33 -0700 (PDT) Received: from cichlid.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA00814 for ; Wed, 26 Jun 2002 12:39:31 -0600 (MDT) Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id g5QIc3X01529 for ; Wed, 26 Jun 2002 14:38:03 -0400 Message-Id: <200206261838.g5QIc3X01529@cichlid.adsl.duke.edu> To: ipng@sunroof.eng.sun.com Subject: IESG comments on draft-ietf-ipngwg-icmp-name-lookups-09.txt Date: Wed, 26 Jun 2002 14:38:02 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has reviewed this document and has a number of concerns. General concerns: 1) The applicability statement limits the scope to diagnostic and debugging and states that the mechanism is for name lookups independent of the the DNS. However, there are still places in the document where the use of name lookups suggests that it might be OK to mix DNS operations with ICMP name lookup operations (specific examples given below). The IESG believes that the name space as provided by the DNS should not be mixed or "contaminated" with name resolutions performed using the ICMP mechanism. Doing so raises complex security and trust issues that have not been explored. The document should make it clear that name lookups using the icmp mechanism described in this document are never to be mixed with DNS name lookups. That is, no queries made to the DNS (or implicitely assumed to be going to the DNS) should get back responses that have been learned through the ICMP name lookup mechanism. Note: the IESG notes with concern that some recent comments on the IPng mailing list indicate that there is some feeling that using the icmp mechanism as a replacement for DNS operations is a desirable direction to go in. We have significant concerns with this view. Giving just one example, there is a model for securing DNS data via DNSSEC; there is no apparent model for securing ICMP name lookups. 2) The document doesn't specify security issues around RFC 3041 temporary addresses and how they can be ameliorated. But queries for names and addresses can be used to discover the relationship between more permanent DNS names and IP addresses and the temporary addresses (and names). Stating this threat in the security considerations is needed. Presumably the threat can be avoided by requiring that nodes separate the temporary addresses from other addresses and names e.g. by - having queries sent to a temporary destination address or for a temporary subject address not return non-temporary addresses or domain names - having queries for non-temporary addresses or for domain names not return temporary addresses. While there might be a policy knob to override this, the setting of that knob must default to the above separation. 3) This protocol is a bit loaded with options and features. It supports a number of different queries, leaves a fair amount of flexibility in how such information is obtained (e.g., proxies are supported) and is rather easily extensible, including in proprietary ways. The IANA Considerations Section indicates that anyone can obtain code points to extend the protocol as they please without the need for even a basic sanity review. As one reviewer noted: As an example, the original idea -- that you ask a host for its own name -- is a good one, and for lots of reasons it may be far better than using PTR records. But this draft has mutated to take on aspects of the Kitchen Sink Protocol There does not appear to be a readily applicable security model for how one can secure the protocol or the information it returns. This would lead one to prefer a more narrowly scoped protocol that can't easily be extended in inappropriate ways, especially for a Standards Track protocol. It is strongly suggested that the document should restrict extensions to the protocol to RFC-approved new queries and a small space for private use. ================ More detailed comments from various reviewers: Many application implementations do a reverse DNS lookup on an IP address to learn the DNS Name of the connecting system. This name is then used to make access control decisions. Some may believe that this mechanism can be used to replace the reverse lookup. However this introduces a new security vulnerability, which is to say that a bogus host could connect to a service and when queried with this protocol it would provide the DNS Name that the server is expecting and therefore make an inappropriate access control decisions. The Security Considerations section should have words in it to the effect that the FQDN information (and other information) provided cannot be trusted for making security relevant decisions unless some other mechanism beyond the scope of this document is used to authenticate that information. ================ The applicability statement is ok, but there appears to be text that, counter to the applicability statement, talk about DNS resolvers using this mechanism to answer DNS queries. Section 5.3 If the Query was sent by a DNS server on behalf of a DNS client, the result may be returned to that client as a DNS response with TTL zero. However, if the server has the matching AAAA record, either in cache or in an authoritative zone, then the TTL of that record may be used as the missing TTL of the NI Node Name Reply and the information in the reply may be cached and used for that period. It would be an implementation choice for a server to perform a DNS query for the AAAA or A6 records that match a received NI Node Name Reply. This might be done to obtain a TTL to make the Reply cacheable or in anticipation of such a DNS query from the client that caused the Node Name Query. This seems to take about some interaction between DNS and icmp name lookups which is out of scope per the applicability statement. Section 5.4: If the Query was sent by a DNS server on behalf of a DNS client, the result may be returned to that client as a DNS response with TTL zero. Ditto. Section 5.5 If the Query was sent by a DNS server on behalf of a DNS client, the result may be returned to that client as a DNS response with TTL zero. Ditto. Also, the "serverless environments" in the abstract can lead folks to believe the applicability is larger than stated. --- Nits: Section 3 talks about a "Reply Data" field but the field in the packet is called "Data". Section 4 talks about the MD5 hash to construct a multicast address from a name. It would aid interoperability if that section contained an example name and the resulting hash value and multicast address. Section 4 talks about returning errors when the Qtype is unknown. I think the intent is that those errors, just like other replies be subject to random delay for responses to multicast packets. But this isn't obvious from the text. E.g. adding "subject to the random delay as specified below." would be helpful. ================ A separate applicability section is appended at the end of the document. Since the introduction also talks a bit about applicability, it would be better to merge the two texts into one place near the front. Append the first 32 bits of that 128-bit hash to the prefix FF02:0:0:0:0:2::/96. The resulting multicast address will be termed the "NI Group Address" for the name. Uses an awfully big range of multicast addresses, i.e., all of the "unique" bits that are used to form the corresponding link-layer multicast link-layer address in Ethernet. Is this reasonable? Note that both ND and SLP do similar things, but use smaller independent ranges, so there are no collision in the mapping for different uses. Wouldn't it be be more conservative to carve out a smaller range that doesn't immediately collide with other ranges? If the Query was sent to an anycast or multicast address, transmission of the Reply MUST be delayed by a random interval between zero and MAX_ANYCAST_DELAY_TIME, as defined by IPv6 Neighbor Discovery [2461]. I understand the delay for multicast, but why anycast? There should be only one anycast response, so why delay? > 5.1. NOOP Not that great a name... It is really an echo, because the responder must respond... Maybe call this "Liveness"? "Capability Query"? > This NI type has no defined flags and never has a Data field. A > Reply to a NI NOOP Query tells the Querier that a node with the > Queried Address is up and reachable, implements the Node Information > protocol, and incidentally happens to reveal whether the Queried > Address was an anycast address. On transmission, the ICMPv6 Code in > a NOOP Query must be set to 1 and the Code in a NOOP Reply must be > 0. On reception of a NOOP Query or Reply, the Code must be ignored. Anycast comment is a bit cryptic. Is the assumption that if source address in response is not same as original dest, responses was anycast? If so, would be good to just say so. A 1-valued bit indicates support for the corresponding Qtype. The lowest-order four bits in the first 32-bit word must be set to 1, showing support for the four mandatory Qtypes defined in this specification. Thus the Data field of a NI Supported Qtypes Reply probably should say something about bit order and endianness here. ================ extremely vulnerable to many kinds of attacks, e.g. adress spoofing. --- just when we have dnssec heading for the door, along comes nice totally insecure reverse lookup. --- 5.1. NOOP This NI type has no defined flags and never has a Data field. A Reply to a NI NOOP Query tells the Querier that a node with the Queried Address is up and reachable, implements the Node Information protocol, and incidentally happens to reveal whether the Queried Address was an anycast address. the whole subject of whether an anycast address should be differentiable is, or should be, undecided. --- The compressed form of the Reply Data consists of a sequence of blocks, each block consisting of two 16-bit unsigned integers, nWord and nSkip, followed by nWord 32-bit bitmasks describing the Responder's support for 32 consecutive Qtypes. nSkip is a count of 32-bit words following the included words which would have been all-zero and have been suppressed. The last block MUST have nSkip = 0. As an example, a Responder supporting Qtypes 0, 1, 2, 3, 60, and 4097 could express that information with the following Reply Data (nWord and nSkip fields are written in decimal for easier reading): how clever, and i do not mean that as a compliment. just how many qtypes does this intend? --- a6 resource records, now deprecated, are supported. --- there is nothing keeping these queries local or limiting them to zeroconf environments. ================ 5.3 How can a DNS TTL be returned? TTLs depend on the original value and how long it's been since an authoritative server sent out the information. Besides, how does a typical kernel (the entity that usually processes ICMP messages) know anything about DNS replies or dhcp lease time? I can imagine a DHCP client installing the current lease expiration every time it does a rebind or renew, but on what basis should a host do DNS queries? I think the "use once" semantics mentioned are far better. The document speaks of A6. Should it? 5.4 It speaks of truncation for space reasons. How large can the reply be? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 26 11:59:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5QIxjk7002823; Wed, 26 Jun 2002 11:59:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5QIxjB3002822; Wed, 26 Jun 2002 11:59:45 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5QIxfk7002813 for ; Wed, 26 Jun 2002 11:59:41 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA20696 for ; Wed, 26 Jun 2002 11:59:47 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA12118 for ; Wed, 26 Jun 2002 12:59:45 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id C85E34B29; Thu, 27 Jun 2002 03:59:38 +0900 (JST) To: Thomas Narten Cc: ipng@sunroof.eng.sun.com In-reply-to: narten's message of Wed, 26 Jun 2002 14:38:02 -0400. <200206261838.g5QIc3X01529@cichlid.adsl.duke.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: IESG comments on draft-ietf-ipngwg-icmp-name-lookups-09.txt From: itojun@iijlab.net Date: Thu, 27 Jun 2002 03:59:38 +0900 Message-Id: <20020626185938.C85E34B29@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >3) This protocol is a bit loaded with options and features. It >supports a number of different queries, leaves a fair amount of >flexibility in how such information is obtained (e.g., proxies are >supported) and is rather easily extensible, including in proprietary >ways. The IANA Considerations Section indicates that anyone can obtain >code points to extend the protocol as they please without the need for >even a basic sanity review. As one reviewer noted: I can't agree more. The initial proposal was simple and robust (which was just a name lookup). I personally think Qtypes other than "Node name" are unnecessary. >More detailed comments from various reviewers: > >Many application implementations do a reverse DNS lookup on an IP >address to learn the DNS Name of the connecting system. This name is >then used to make access control decisions. Some may believe that this >mechanism can be used to replace the reverse lookup. However this >introduces a new security vulnerability, which is to say that a bogus >host could connect to a service and when queried with this protocol it >would provide the DNS Name that the server is expecting and therefore >make an inappropriate access control decisions. This part, I have a major objection. This view is completely opposite from concerns raised in draft-ietf-dnsop-inaddr-required-03.txt - DNS PTR records should not be used as sort-of authenticity, therefore, it is not recommended to be used as an access control mechanism. In my understanding, the threat imposed by malicious responses to ICMPv6 node information query (Qtype = node name) is equal to setting up DNS PTR records without forward zone administrators' knowing. For instance, anyone can set up DNS PTR records that returns "www.ietf.org". Similarly, anyone can respond with ICMPv6 node information reply with "www.ietf.org". 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 Jun 26 12:10:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5QJAik7002877; Wed, 26 Jun 2002 12:10:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5QJAi6M002876; Wed, 26 Jun 2002 12:10:44 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5QJAfk7002869 for ; Wed, 26 Jun 2002 12:10:41 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA29564 for ; Wed, 26 Jun 2002 12:10:47 -0700 (PDT) Received: from cichlid.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA06979 for ; Wed, 26 Jun 2002 13:10:45 -0600 (MDT) Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id g5QJ93V02004; Wed, 26 Jun 2002 15:09:07 -0400 Message-Id: <200206261909.g5QJ93V02004@cichlid.adsl.duke.edu> To: itojun@iijlab.net cc: ipng@sunroof.eng.sun.com Subject: Re: IESG comments on draft-ietf-ipngwg-icmp-name-lookups-09.txt In-Reply-To: Message from itojun@iijlab.net of "Thu, 27 Jun 2002 03:59:38 +0900." <20020626185938.C85E34B29@coconut.itojun.org> Date: Wed, 26 Jun 2002 15:09:03 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Let me clarify... itojun@iijlab.net writes: > >More detailed comments from various reviewers: > > > >Many application implementations do a reverse DNS lookup on an IP > >address to learn the DNS Name of the connecting system. This name is > >then used to make access control decisions. Some may believe that this > >mechanism can be used to replace the reverse lookup. However this > >introduces a new security vulnerability, which is to say that a bogus > >host could connect to a service and when queried with this protocol it > >would provide the DNS Name that the server is expecting and therefore > >make an inappropriate access control decisions. > This part, I have a major objection. > This view is completely opposite from concerns raised in > draft-ietf-dnsop-inaddr-required-03.txt - DNS PTR records should > not be used as sort-of authenticity, therefore, it is not recommended > to be used as an access control mechanism. The above suggests that the IESG comment was implying that doing reverse lookups for some sort of security check is a good idea; actually, the IESG view is the opposite. It believes it is generally a bad idea. However, it is also the case that people seem to do this. Thus, the suggestion to put in explicit text saying this is an even worse idea than if one was just using the DNS record. But the issue is more nuanced I think. I *thought* that what implementations did was a) do a lookup of address -> name b) do a lookup of name -> address If the later returns the first address, that is somehow a good enough check. So, one can imagine doing ICMP name lookups for a), but still do b) via the DNS. The issue here would be different than just doing a) via lookups or doing both a) and b) via lookups. > In my understanding, the threat imposed by malicious responses to > ICMPv6 node information query (Qtype = node name) is equal to > setting up DNS PTR records without forward zone administrators' > knowing. For instance, anyone can set up DNS PTR records that returns > "www.ietf.org". Similarly, anyone can respond with ICMPv6 node > information reply with "www.ietf.org". Yep. This would all be appropriate to better explain in the security considerations section. Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 26 12:11:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5QJBOk7002899; Wed, 26 Jun 2002 12:11:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5QJBNhY002897; Wed, 26 Jun 2002 12:11:23 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5QJBJk7002888 for ; Wed, 26 Jun 2002 12:11:19 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA29649 for ; Wed, 26 Jun 2002 12:11:24 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA06911 for ; Wed, 26 Jun 2002 13:11:23 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g5QJBB817030; Wed, 26 Jun 2002 22:11:11 +0300 Date: Wed, 26 Jun 2002 22:11:11 +0300 (EEST) From: Pekka Savola To: itojun@iijlab.net cc: Thomas Narten , Subject: Re: IESG comments on draft-ietf-ipngwg-icmp-name-lookups-09.txt In-Reply-To: <20020626185938.C85E34B29@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 27 Jun 2002 itojun@iijlab.net wrote: > In my understanding, the threat imposed by malicious responses to > ICMPv6 node information query (Qtype = node name) is equal to > setting up DNS PTR records without forward zone administrators' > knowing. For instance, anyone can set up DNS PTR records that returns > "www.ietf.org". Similarly, anyone can respond with ICMPv6 node > information reply with "www.ietf.org". That anyone setting DNS PTR records must be the administrator of an IP address block, and that IP address block must have been assigned to him. Seems like a big difference IMO. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 26 12:21:55 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5QJLtk7003027; Wed, 26 Jun 2002 12:21:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5QJLsd4003026; Wed, 26 Jun 2002 12:21:54 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5QJLok7003019 for ; Wed, 26 Jun 2002 12:21:51 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA03261 for ; Wed, 26 Jun 2002 12:21:56 -0700 (PDT) Received: from esunmail ([129.147.58.122]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA12873 for ; Wed, 26 Jun 2002 13:21:56 -0600 (MDT) Received: from xpa-fe2 (esunmail-ge1 [129.147.58.122]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 0.3 (built May 13 2002)) with ESMTP id <0GYB003ZAV4HAV@edgemail1.Central.Sun.COM> for ipng@sunroof.eng.sun.com; Wed, 26 Jun 2002 13:21:56 -0600 (MDT) Received: from localhost ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 0.2 (built Apr 26 2002)) with ESMTPSA id <0GYB007X2V4GS1@mail.sun.net> for ipng@sunroof.eng.sun.com; Wed, 26 Jun 2002 13:21:53 -0600 (MDT) Date: Wed, 26 Jun 2002 12:21:52 -0700 From: Alain Durand Subject: Re: IESG comments on draft-ietf-ipngwg-icmp-name-lookups-09.txt In-reply-to: <200206261838.g5QIc3X01529@cichlid.adsl.duke.edu> To: Thomas Narten Cc: ipng@sunroof.eng.sun.com Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.482) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wednesday, June 26, 2002, at 11:38 AM, Thomas Narten wrote: > The IESG has reviewed this document and has a number of concerns. > > > The IESG believes that the name space as provided by the DNS should > not be mixed or "contaminated" with name resolutions performed using > the ICMP mechanism. Doing so raises complex security and trust issues > that have not been explored. > > The document should make it clear that name lookups using the icmp > mechanism described in this document are never to be mixed with DNS > name lookups. That is, no queries made to the DNS (or implicitely > assumed to be going to the DNS) should get back responses that have > been learned through the ICMP name lookup mechanism. I do not understand this comment. Vendors have long learned how to integrate different name services: DNS, NIS, NIS+, LDAP, Flat files.... ICMP NI would just be one more service to integrate. - 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 Jun 26 12:25:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5QJPnk7003047; Wed, 26 Jun 2002 12:25:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5QJPn8a003046; Wed, 26 Jun 2002 12:25:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5QJPkk7003039 for ; Wed, 26 Jun 2002 12:25:46 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA01863 for ; Wed, 26 Jun 2002 12:25:51 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA14787 for ; Wed, 26 Jun 2002 13:25:50 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g5QJPks17153; Wed, 26 Jun 2002 22:25:46 +0300 Date: Wed, 26 Jun 2002 22:25:46 +0300 (EEST) From: Pekka Savola To: Alain Durand cc: Thomas Narten , Subject: Re: IESG comments on draft-ietf-ipngwg-icmp-name-lookups-09.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 Wed, 26 Jun 2002, Alain Durand wrote: > On Wednesday, June 26, 2002, at 11:38 AM, Thomas Narten wrote: > > > The IESG has reviewed this document and has a number of concerns. > > > > > > The IESG believes that the name space as provided by the DNS should > > not be mixed or "contaminated" with name resolutions performed using > > the ICMP mechanism. Doing so raises complex security and trust issues > > that have not been explored. > > > > The document should make it clear that name lookups using the icmp > > mechanism described in this document are never to be mixed with DNS > > name lookups. That is, no queries made to the DNS (or implicitely > > assumed to be going to the DNS) should get back responses that have > > been learned through the ICMP name lookup mechanism. > > I do not understand this comment. > Vendors have long learned how to integrate different name services: > DNS, NIS, NIS+, LDAP, Flat files.... These services have some reasonable security models .. > ICMP NI would just be one more service to integrate. .. this has not. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 26 13:04:57 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5QK4uk7003116; Wed, 26 Jun 2002 13:04:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5QK4u6N003115; Wed, 26 Jun 2002 13:04:56 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5QK4qk7003108 for ; Wed, 26 Jun 2002 13:04:52 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA16832 for ; Wed, 26 Jun 2002 13:04:48 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA00475; Wed, 26 Jun 2002 14:04:47 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5QK4j206188; Wed, 26 Jun 2002 16:04:45 -0400 (EDT) Message-Id: <200206262004.g5QK4j206188@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Alain Durand cc: Thomas Narten , ipng@sunroof.eng.sun.com Subject: Re: IESG comments on draft-ietf-ipngwg-icmp-name-lookups-09.txt In-reply-to: (Your message of "Wed, 26 Jun 2002 12:21:52 PDT.") Date: Wed, 26 Jun 2002 16:04:45 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Vendors have long learned how to integrate different name services: > DNS, NIS, NIS+, LDAP, Flat files.... I think that should be 'vendors have long attempted to integrate different name services'. Unfortunately, they still haven't learned NOT to do it - and this applies equally to NIS* and WINS. Both cause fits for system administrators. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 26 13:54:50 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5QKsnk7003202; Wed, 26 Jun 2002 13:54:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5QKsnPv003201; Wed, 26 Jun 2002 13:54:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5QKskk7003194 for ; Wed, 26 Jun 2002 13:54:46 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA04520 for ; Wed, 26 Jun 2002 13:54:51 -0700 (PDT) Received: from tndh.net (evrtwa1-ar8-4-65-028-011.evrtwa1.dsl-verizon.net [4.65.28.11]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA23992 for ; Wed, 26 Jun 2002 14:54:46 -0600 (MDT) Received: from eagleswings (127.0.0.1) by localhost (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Wed, 26 Jun 2002 13:55:48 -0700 From: "Tony Hain" To: "Thomas Narten" , Subject: RE: IESG comments on draft-ietf-ipngwg-icmp-name-lookups-09.txt Date: Wed, 26 Jun 2002 13:54:35 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <200206261838.g5QIc3X01529@cichlid.adsl.duke.edu> Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas Narten wrote: > ... > 2) The document doesn't specify security issues around RFC 3041 > temporary addresses and how they can be ameliorated. But queries for > names and addresses can be used to discover the relationship between > more permanent DNS names and IP addresses and the temporary addresses > (and names). THere is no reason a node would respond to this query if its intent is to remain anonymous. On top of that there are no 'security issues' raised here, though there may be some authentication issues. > > Stating this threat in the security considerations is needed. What threat? Is the concern that some implementer would be stupid enough to reveal a private address? Stupidity can't be legislated against. > Presumably the threat can be avoided by requiring that nodes separate > the temporary addresses from other addresses and names e.g. by > - having queries sent to a temporary destination address or > for a temporary subject address not return non-temporary addresses > or domain names > - having queries for non-temporary addresses or for domain names not > return temporary addresses. > While there might be a policy knob to override this, the setting of > that knob must default to the above separation. Why should there be a policy knob for revealing a 3041 address to name mapping? That is absolutely absurd. Either the node is allowed to use the addresses 'privately' or the node is not allowed to use those addresses at all. The policy knob belongs on the decision to use the format, not on requiring disclosure if they are used. Personally I would leave the querier hung in a timeout, but the politically correct thing to do might be to pretend the node doesn't know its name and return a null list with ttl=0. > > 3) This protocol is a bit loaded with options and features. It > supports a number of different queries, leaves a fair amount of > flexibility in how such information is obtained (e.g., proxies are > supported) and is rather easily extensible, including in proprietary > ways. The IANA Considerations Section indicates that anyone can obtain > code points to extend the protocol as they please without the need for > even a basic sanity review. As one reviewer noted: > > As an example, the original idea -- that you ask a host for its > own name -- is a good one, and for lots of reasons it may be far > better than using PTR records. But this draft has mutated to > take on aspects of the Kitchen Sink Protocol > > There does not appear to be a readily applicable security model for > how one can secure the protocol or the information it returns. This > would lead one to prefer a more narrowly scoped protocol that can't > easily be extended in inappropriate ways, especially for a Standards > Track protocol. It is strongly suggested that the document should > restrict extensions to the protocol to RFC-approved new queries and a > small space for private use. Again there is no 'security' in the information returned, but there may be some concern about authenticity. The potential security issue that has been missed in this set of responses is the ability to use this to seed a dos attack against the complete set of addresses without tripping an IDS frequency counter. It also doesn't make any sense to use a mechansim that is clearly getting packets to the dst node to ask it for other addresses that might be used to get packets to it. THe only possible use I can see would be to allow shifting to a different pair for route selection reasons, but that implies global usage which is itself a bad idea. The best way to restrict the applicability of this protocol is to limit it to link-scope or site-scope addresses. Since an answer from outside the local administrative scope can't be trusted anyway, there is no reason for the protocol to escape that scope. Once the connection exceeds the bounds of a site, either there is no trust, or there is some authentication infrastructure support. If there is authenticated infrastructure, it makes more sense to use DNSsec than create something new. Tony BTW: if the document maintains its Kitchen-Sink flavor, the IPv4 query type should be removed and IPv4 addresses should be returned in IPv4-mapped IPv6 format. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 26 14:00:47 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5QL0lk7003225; Wed, 26 Jun 2002 14:00:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5QL0lMk003224; Wed, 26 Jun 2002 14:00:47 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5QL0ik7003217 for ; Wed, 26 Jun 2002 14:00:44 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA06771 for ; Wed, 26 Jun 2002 14:00:48 -0700 (PDT) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA03389; Wed, 26 Jun 2002 14:00:48 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.05) id 17NJuA-0002GB-00; Wed, 26 Jun 2002 14:00:46 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Alain Durand Cc: Thomas Narten , ipng@sunroof.eng.sun.com Subject: Re: IESG comments on draft-ietf-ipngwg-icmp-name-lookups-09.txt References: <200206261838.g5QIc3X01529@cichlid.adsl.duke.edu> Message-Id: Date: Wed, 26 Jun 2002 14:00:46 -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Vendors have long learned how to integrate different name services: > DNS, NIS, NIS+, LDAP, Flat files.... and users are still having fun debugging the resulting behavior. "was it a funny dns result, an error in the hosts file, yellow plague, ...? there goes 10-30 minutes " -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 26 14:16:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5QLGWk7003295; Wed, 26 Jun 2002 14:16:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5QLGWqX003294; Wed, 26 Jun 2002 14:16:32 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5QLGTk7003287 for ; Wed, 26 Jun 2002 14:16:29 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA07572 for ; Wed, 26 Jun 2002 14:16:33 -0700 (PDT) Received: from tndh.net (evrtwa1-ar8-4-65-028-011.evrtwa1.dsl-verizon.net [4.65.28.11]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA03407 for ; Wed, 26 Jun 2002 15:16:32 -0600 (MDT) Received: from eagleswings (127.0.0.1) by localhost (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Wed, 26 Jun 2002 14:17:35 -0700 From: "Tony Hain" To: "Keith Moore" , "Robert Elz" Cc: "Bill Fenner" , Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols Date: Wed, 26 Jun 2002 14:16:22 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <200206181540.g5IFecY19885@astro.cs.utk.edu> Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith Moore wrote: > ... > I don't think stability is the issue. global addrs need to > be reasonably > stable (which is to say, on the order of MTBFs for reliable machines) > whether or not the prefix is provider-based, topology-based, or > assigned to the site. the idea that a prefix can be changed > at a whim > is just a fantasy. Clearly you still live in the fantasy land where pleanty of addresses were handed out 20 years ago, the birds sing, the air is always clean, and the sun always shines... Changing prefixes is the new reality. I know first hand as my ISP recently changed their subnet prefix & allocations overnight without bothering to inform anyone. Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 26 14:21:58 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5QLLwk7003315; Wed, 26 Jun 2002 14:21:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5QLLwsg003314; Wed, 26 Jun 2002 14:21:58 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5QLLsk7003307 for ; Wed, 26 Jun 2002 14:21:54 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA09303 for ; Wed, 26 Jun 2002 14:21:59 -0700 (PDT) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA25516 for ; Wed, 26 Jun 2002 15:21:58 -0600 (MDT) Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.05) id 17NKEf-0002qH-00; Wed, 26 Jun 2002 14:21:57 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: "Tony Hain" Cc: "Keith Moore" , "Robert Elz" , "Bill Fenner" , Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols References: <200206181540.g5IFecY19885@astro.cs.utk.edu> Message-Id: Date: Wed, 26 Jun 2002 14:21:57 -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Clearly you still live in the fantasy land where pleanty of addresses > were handed out 20 years ago, the birds sing, the air is always clean, > and the sun always shines. is your point sufficiently weak that you need to spout this ? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 26 14:29:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5QLT8k7003336; Wed, 26 Jun 2002 14:29:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5QLT8dA003335; Wed, 26 Jun 2002 14:29:08 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5QLT5k7003328 for ; Wed, 26 Jun 2002 14:29:05 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA11530 for ; Wed, 26 Jun 2002 14:29:10 -0700 (PDT) Received: from tndh.net (evrtwa1-ar8-4-65-028-011.evrtwa1.dsl-verizon.net [4.65.28.11]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA08755 for ; Wed, 26 Jun 2002 15:29:08 -0600 (MDT) Received: from eagleswings (127.0.0.1) by localhost (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Wed, 26 Jun 2002 14:30:11 -0700 From: "Tony Hain" To: "Ralph Droms" , "Michel Py" Cc: "Robert Elz" , Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols Date: Wed, 26 Jun 2002 14:28:58 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <4.3.2.7.2.20020623173820.00ba1978@funnel.cisco.com> Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ralph Droms wrote: > I agree 100% with Micehls' point - assigning unique IDs to > sites for use in > site-local addresses moves the site-local addresses into a globally > routable address space, with the additional feature that > those addresses > are provider independent. The result would be an address > space that is > site-local by (potentially unenforceable) executive fiat > rather than by > technical design. > And if the point is to end up with global addresses, we already have a mechanism for those, so modifying SL to make them globally unique does nothing. If the goal is provider independent space, I agree and have a couple of drafts that talk about why that kind of space is required and one possible way to scale it for routing. Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 26 14:41:28 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5QLfRk7003358; Wed, 26 Jun 2002 14:41:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5QLfRqG003357; Wed, 26 Jun 2002 14:41:27 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5QLfOk7003350 for ; Wed, 26 Jun 2002 14:41:24 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA20694 for ; Wed, 26 Jun 2002 14:41:29 -0700 (PDT) Received: from tndh.net (evrtwa1-ar8-4-65-028-011.evrtwa1.dsl-verizon.net [4.65.28.11]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA13730 for ; Wed, 26 Jun 2002 15:41:28 -0600 (MDT) Received: from eagleswings (127.0.0.1) by localhost (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Wed, 26 Jun 2002 14:42:30 -0700 From: "Tony Hain" To: "Robert Elz" , "Ralph Droms" Cc: "Michel Py" , Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols Date: Wed, 26 Jun 2002 14:41:17 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <18781.1024928412@munnari.OZ.AU> Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert Elz wrote: > Date: Sun, 23 Jun 2002 17:44:17 -0400 > From: Ralph Droms > Message-ID: <4.3.2.7.2.20020623173820.00ba1978@funnel.cisco.com> > > | I agree 100% with Micehls' point - assigning unique IDs > to sites for use in > | site-local addresses moves the site-local addresses into > a globally > | routable address space, with the additional feature that > those addresses > | are provider independent. > > Yes, as I've said - the proposals to stick IDs into SL addresses keeps > getting shot down. > > I'm not sure that I think a lot of an argument that goes > "well, someday > someone might misuse it, so we'd better not have it at all", > but that's > not important for now. > > What matters here, is that "global" addresses from a non > routable prefix > have all of the same problems (they are identical, other than the bit > pattern that makes up the prefix). Maybe the way to solve this is to take the 'must be 0' bits and define them as 'locally administered' with a clear note that FE00::/8 will be blocked on the public net. This would allow sites that want the hassle of coordinating multiple private interconnects to do whatever they want (since they will anyway if the implementations allow it), without leaving any expectations that these are in any way globally unique. Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 26 14:48:32 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5QLmWk7003381; Wed, 26 Jun 2002 14:48:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5QLmVaa003380; Wed, 26 Jun 2002 14:48:31 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5QLmRk7003373 for ; Wed, 26 Jun 2002 14:48:27 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA17761 for ; Wed, 26 Jun 2002 14:48:32 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA20488 for ; Wed, 26 Jun 2002 15:48:32 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5QLhM206629; Wed, 26 Jun 2002 17:43:22 -0400 (EDT) Message-Id: <200206262143.g5QLhM206629@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Tony Hain" cc: "Keith Moore" , "Robert Elz" , "Bill Fenner" , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-reply-to: (Your message of "Wed, 26 Jun 2002 14:16:22 PDT.") Date: Wed, 26 Jun 2002 17:43:22 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > I don't think stability is the issue. global addrs need to > > be reasonably > > stable (which is to say, on the order of MTBFs for reliable machines) > > whether or not the prefix is provider-based, topology-based, or > > assigned to the site. the idea that a prefix can be changed > > at a whim > > is just a fantasy. > > Clearly you still live in the fantasy land where pleanty of addresses > were handed out 20 years ago, the birds sing, the air is always clean, > and the sun always shines... Changing prefixes is the new reality. I > know first hand as my ISP recently changed their subnet prefix & > allocations overnight without bothering to inform anyone. Tony, This kind of statement is a personal attack and it has no place in IETF. Also, you apparently need to reread what I wrote, because you missed it the first time. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 26 14:50:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5QLonk7003398; Wed, 26 Jun 2002 14:50:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5QLoneX003397; Wed, 26 Jun 2002 14:50:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5QLojk7003390 for ; Wed, 26 Jun 2002 14:50:45 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA18506 for ; Wed, 26 Jun 2002 14:50:50 -0700 (PDT) Received: from tndh.net (evrtwa1-ar8-4-65-028-011.evrtwa1.dsl-verizon.net [4.65.28.11]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA17346 for ; Wed, 26 Jun 2002 15:50:49 -0600 (MDT) Received: from eagleswings (127.0.0.1) by localhost (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Wed, 26 Jun 2002 14:51:52 -0700 From: "Tony Hain" To: "Keith Moore" , "Robert Elz" Cc: "Ralph Droms" , "Michel Py" , Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols Date: Wed, 26 Jun 2002 14:50:39 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <200206241602.g5OG2O220497@astro.cs.utk.edu> Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith Moore wrote: > ... > mainly I want a solution to the problem. apps need to be able to do > address referrals and right now the algorithm for selecting > which address > to use is little better than a guess. anything we can do to > make this > faster or more reliable is a good thing, and SLs with > site-ids are better > for this than SLs without site-ids. I don't agree with the stated requirement. While I agree that apps need a way to do referrals, what says that has to be done using addresses rather than name strings? Clearly referrals using IPv4 addresses can't work today, so any app that needs to do a referral will have to use a name. What about IPv6 changes that? Is it simply to save the receiver of the referral from having to resolve an address? If so that is a bogus application design, because the referrer can't know that it has all the possible addresses for the target. Even if it got the full list from DNS, it can't know that the target didn't update DNS since it retrieved the list. In short you are looking to optimize the wrong part of the system and the resulting application failures will leave it no better than it is in an IPv4/NAT world. Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 26 15:03:20 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5QM3Jk7003445; Wed, 26 Jun 2002 15:03:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5QM3J0X003444; Wed, 26 Jun 2002 15:03:19 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5QM3Gk7003437 for ; Wed, 26 Jun 2002 15:03:16 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA22564 for ; Wed, 26 Jun 2002 15:03:21 -0700 (PDT) Received: from tndh.net (evrtwa1-ar8-4-65-028-011.evrtwa1.dsl-verizon.net [4.65.28.11]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA22941 for ; Wed, 26 Jun 2002 16:03:20 -0600 (MDT) Received: from eagleswings (127.0.0.1) by localhost (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Wed, 26 Jun 2002 15:04:22 -0700 From: "Tony Hain" To: Cc: "Robert Elz" , "Bill Fenner" , Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols Date: Wed, 26 Jun 2002 15:03:09 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <200206262143.g5QLhM206629@astro.cs.utk.edu> Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith Moore wrote: > > > I don't think stability is the issue. global addrs need to > > > be reasonably > > > stable (which is to say, on the order of MTBFs for > reliable machines) > > > whether or not the prefix is provider-based, topology-based, or > > > assigned to the site. the idea that a prefix can be changed > > > at a whim > > > is just a fantasy. > > > > Clearly you still live in the fantasy land where pleanty of > addresses > > were handed out 20 years ago, the birds sing, the air is > always clean, > > and the sun always shines... Changing prefixes is the new reality. I > > know first hand as my ISP recently changed their subnet prefix & > > allocations overnight without bothering to inform anyone. > > Tony, > > This kind of statement is a personal attack and it has no > place in IETF. > > Also, you apparently need to reread what I wrote, because you missed > it the first time. > > Keith It was not intended as a personal attack, but I agree it can be read that way so I apologize for any misunderstanding. The statement I was responding to was "the idea that a prefix can be changed at a whim is just a fantasy.". The point is that arbitrary & random prefix changes are reality and believing it doesn't happen is the fantasy. While it is nice to believe that providers that do this are subject to customer retaliation, where are the customers going to go? If the SP otherwise provides the best service available (or increasingly the only service), the renumbering even is a fact of life. Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 26 15:08:07 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5QM87k7003486; Wed, 26 Jun 2002 15:08:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5QM87w1003485; Wed, 26 Jun 2002 15:08:07 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5QM83k7003478 for ; Wed, 26 Jun 2002 15:08:03 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA03670 for ; Wed, 26 Jun 2002 15:08:08 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA08967 for ; Wed, 26 Jun 2002 15:08:08 -0700 (PDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5QM2u206678; Wed, 26 Jun 2002 18:02:56 -0400 (EDT) Message-Id: <200206262202.g5QM2u206678@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Tony Hain" cc: "Keith Moore" , "Robert Elz" , "Ralph Droms" , "Michel Py" , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-reply-to: (Your message of "Wed, 26 Jun 2002 14:50:39 PDT.") Date: Wed, 26 Jun 2002 18:02:56 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > ... > > mainly I want a solution to the problem. apps need to be able to do > > address referrals and right now the algorithm for selecting > > which address > > to use is little better than a guess. anything we can do to > > make this > > faster or more reliable is a good thing, and SLs with > > site-ids are better > > for this than SLs without site-ids. > > I don't agree with the stated requirement. While I agree that apps need > a way to do referrals, what says that has to be done using addresses > rather than name strings? first we would need a naming system that is fast and reliable. > Clearly referrals using IPv4 addresses can't > work today, so any app that needs to do a referral will have to use a > name. no they won't. clearly you live in a fantasy land where DNS always works perfectly and lookups take only microseconds. in the real world, DNS fails to provide the correct answer a significant part of the time and lookups often take 10 seconds or more. > What about IPv6 changes that? nothing about IPv6 changes that, except that IPv6 has the built-in expectation that an app may have to deal wth multiple addresses and somehow choose one of those addresses without any knowledge as which ones are more likely to work than others. and you think *I'm* in a fantasy land. > Is it simply to save the receiver of > the referral from having to resolve an address? If so that is a bogus > application design, who made you the arbitrer of good application design? who are you to dismiss applications' real requirements for low latency and high reliability? > because the referrer can't know that it has all the > possible addresses for the target. the referrer can never be sure that it has all of the possible addresses for a target, no matter where they were obtained. DNS isn't the sole authority on such things, and even DNS is sometimes two-faced. > In short you are looking to optimize the wrong part of the > system I'm trying to make IPv6 a viable alternative for apps that don't work well under IPv4+NAT. Part of the problem in doing so is that the address selection burden imposed by IPv6 is very similar to problems you get when trying to make distributed apps work with NAT. > and the resulting application failures will leave it no better > than it is in an IPv4/NAT world. that, indeed, is my concern. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 26 15:09:36 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5QM9ak7003503; Wed, 26 Jun 2002 15:09:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5QM9a2H003502; Wed, 26 Jun 2002 15:09:36 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5QM9Yk7003495 for ; Wed, 26 Jun 2002 15:09:34 -0700 (PDT) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g5QM9KoR019602 for ; Wed, 26 Jun 2002 15:09:20 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g5QM9Kfl019601 for ipng@sunroof.eng.sun.com; Wed, 26 Jun 2002 15:09:20 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5PBQ9k7026397 for ; Tue, 25 Jun 2002 04:26:09 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA05517 for ; Tue, 25 Jun 2002 04:26:13 -0700 (PDT) Received: from mail.zmailer.org (mail.zmailer.org [62.240.94.4]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA13085 for ; Tue, 25 Jun 2002 04:26:12 -0700 (PDT) Received: (mea@mea-ext) by mail.zmailer.org id ; Tue, 25 Jun 2002 14:26:01 +0300 Date: Tue, 25 Jun 2002 14:26:00 +0300 From: Matti Aarnio To: Anjaneyulu Cc: ipng@sunroof.eng.sun.com Subject: Re: Hop Limit in Router Advertisement????????? Message-ID: <20020625142600.E28720@mea-ext.zmailer.org> References: <009501c21c39$5ff99160$130fa8c0@anji> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <009501c21c39$5ff99160$130fa8c0@anji>; from anjaneyulu@mistralsoftware.com on Tue, Jun 25, 2002 at 04:43:46PM +0530 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, Jun 25, 2002 at 04:43:46PM +0530, Anjaneyulu wrote: > Hi All, > The ND RFC 2461 specifies that the Hop Limit in the IPv6 Header be set > to 255 for Router Advertisement. > > But as far as i understand the router Advertisement should not be > propagated out of the Link by a router. "should not" is the key. If somebody goofs up, and the Advertisement is thus propagatable, seeing that the hop-count is not 255 will tell to all users that no, it is not valid RA. This way only people local to the cable (link) can generate RAs that are identifiable as valid RAs, and no remote attacker can do the same. This does not prevent all kinds of attacks, only the remote ones. > Regards, > Anj /Matti Aarnio -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 26 15:28:12 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5QMSBk7003573; Wed, 26 Jun 2002 15:28:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5QMSBnV003572; Wed, 26 Jun 2002 15:28:11 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5QMS8k7003565 for ; Wed, 26 Jun 2002 15:28:08 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA01175 for ; Wed, 26 Jun 2002 15:28:13 -0700 (PDT) Received: from tndh.net (evrtwa1-ar8-4-65-028-011.evrtwa1.dsl-verizon.net [4.65.28.11]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA03545 for ; Wed, 26 Jun 2002 16:28:11 -0600 (MDT) Received: from eagleswings (127.0.0.1) by localhost (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Wed, 26 Jun 2002 15:29:14 -0700 From: "Tony Hain" To: Cc: "Robert Elz" , "Ralph Droms" , "Michel Py" , Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols Date: Wed, 26 Jun 2002 15:28:01 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <200206262202.g5QM2u206678@astro.cs.utk.edu> Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith Moore wrote: > > > ... > > > mainly I want a solution to the problem. apps need to be > able to do > > > address referrals and right now the algorithm for selecting > > > which address > > > to use is little better than a guess. anything we can do to > > > make this > > > faster or more reliable is a good thing, and SLs with > > > site-ids are better > > > for this than SLs without site-ids. > > > > I don't agree with the stated requirement. While I agree > that apps need > > a way to do referrals, what says that has to be done using addresses > > rather than name strings? > > first we would need a naming system that is fast and reliable. and referrals of addresses trades off reliability for a little speed. As you note here, some DNS servers are two faced, so how does referring addresses actually work in that case? The referring node would have to know the entire topology including the DNS server boundaries to be able to send the right addresses (if it could even get a complete list). It would be much simpler for the app to send the name string and let the receiver find the traget address list from its own topological perspective. > > > Clearly referrals using IPv4 addresses can't > > work today, so any app that needs to do a referral will > have to use a > > name. > > no they won't. clearly you live in a fantasy land where DNS > always works > perfectly and lookups take only microseconds. in the real world, DNS > fails to provide the correct answer a significant part of the time and > lookups often take 10 seconds or more. So apps should pass around a potnetially bogus list of addresses? I am all for multi-party apps, but fixing the real problem with DNS seems like a better approach than a hack that will end up failing anyway. > > > What about IPv6 changes that? > > nothing about IPv6 changes that, except that IPv6 has the built-in > expectation that an app may have to deal wth multiple addresses and > somehow choose one of those addresses without any knowledge as > which ones are more likely to work than others. > > and you think *I'm* in a fantasy land. trying to build complex topological information directly into the app will fail more often than not. Pass name strings and follow draft-ietf-ipv6-default-addr-select-08.txt. It will not be as fast, but it will be more reliable. > > > Is it simply to save the receiver of > > the referral from having to resolve an address? If so that > is a bogus > > application design, > > who made you the arbitrer of good application design? who are you to > dismiss applications' real requirements for low latency and > high reliability? > > > because the referrer can't know that it has all the > > possible addresses for the target. > > the referrer can never be sure that it has all of the > possible addresses > for a target, no matter where they were obtained. DNS isn't the sole > authority on such things, and even DNS is sometimes two-faced. > > > In short you are looking to optimize the wrong part of the > > system > > I'm trying to make IPv6 a viable alternative for apps that don't work > well under IPv4+NAT. Part of the problem in doing so is that > the address > selection burden imposed by IPv6 is very similar to problems you get > when trying to make distributed apps work with NAT. > > > and the resulting application failures will leave it no better > > than it is in an IPv4/NAT world. > > that, indeed, is my concern. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 26 15:37:01 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5QMb1k7003606; Wed, 26 Jun 2002 15:37:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5QMb0I0003605; Wed, 26 Jun 2002 15:37:00 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5QMauk7003598 for ; Wed, 26 Jun 2002 15:36:56 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA07472 for ; Wed, 26 Jun 2002 15:37:02 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA07160 for ; Wed, 26 Jun 2002 16:37:01 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5QMVn206743; Wed, 26 Jun 2002 18:31:50 -0400 (EDT) Message-Id: <200206262231.g5QMVn206743@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Tony Hain" cc: moore@cs.utk.edu, "Robert Elz" , "Bill Fenner" , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-reply-to: (Your message of "Wed, 26 Jun 2002 15:03:09 PDT.") Date: Wed, 26 Jun 2002 18:31:49 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The statement I was responding to was "the idea that a prefix can be > changed at a whim is just a fantasy.". The point is that arbitrary & > random prefix changes are reality and believing it doesn't happen is the > fantasy. Okay, let me rephrase that: The idea that a prefix can be changed at a whim without having a serious impact on the reliability and performance of applications is just a fantasy. People who think that DNS is a sufficient replacement for stable IP addresses haven't actually bothered to look at how poorly DNS works, how ambiguous and unstable DNS names can be in practice, how quickly apps could expect to recover from address changes (especially when the zone servers themselves have moved). Nor have they investigated the burden of expecting apps to implement explicit app-level acks for everything that gets sent over a TCP stream (so that the app can recover from a connection broken by renumbering), because without such acks the app doesn't know how much data has actually been read by its peer. > While it is nice to believe that providers that do this are > subject to customer retaliation, where are the customers going to go? If > the SP otherwise provides the best service available (or increasingly > the only service), the renumbering even is a fact of life. I don't disagree with that - in fact I currently have to live with an BRI ISDN connection to my house because no provider that can provide higher bandwidth is willing to give me a stable IP address. But just as we cannot force providers to be reasonable, neither can we force applications to work under unreasonable conditions. The best we can do is to try to define what is reasonable and what is unreasonable. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 26 15:52:01 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5QMq1k7003636; Wed, 26 Jun 2002 15:52:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5QMq14I003635; Wed, 26 Jun 2002 15:52:01 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5QMpvk7003628 for ; Wed, 26 Jun 2002 15:51:57 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA17129 for ; Wed, 26 Jun 2002 15:52:03 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA07296 for ; Wed, 26 Jun 2002 16:52:02 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5QMkl206812; Wed, 26 Jun 2002 18:46:47 -0400 (EDT) Message-Id: <200206262246.g5QMkl206812@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Tony Hain" cc: moore@cs.utk.edu, "Robert Elz" , "Ralph Droms" , "Michel Py" , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-reply-to: (Your message of "Wed, 26 Jun 2002 15:28:01 PDT.") Date: Wed, 26 Jun 2002 18:46:47 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > first we would need a naming system that is fast and reliable. > > and referrals of addresses trades off reliability for a little speed. when you're trying to complete a phone call, or trying to coordiate between hundreds of processes in a distributed computation, a 10 second delay in your message being transmitted due to a DNS lookup is simply not acceptable. (heck, it's not even acceptable when browsing the web from over a cell phone...) > As > you note here, some DNS servers are two faced, so how does referring > addresses actually work in that case? The referring node would have to > know the entire topology including the DNS server boundaries to be able > to send the right addresses (if it could even get a complete list). It > would be much simpler for the app to send the name string and let the > receiver find the traget address list from its own topological > perspective. You're missing something important, which is that the DNS server doesn't have a much better idea of which addresses work for the app than the app itself does, especially given that the DNS query might have been routed through one or more intermediaries in different parts of the topology. Two-faced DNS works only in very limited cases; it's not a general solution. Regardless of whether the app gets its addresses from DNS or a referral from a peer, it still has to guess about which address is best. > > no they won't. clearly you live in a fantasy land where DNS > > always works > > perfectly and lookups take only microseconds. in the real world, DNS > > fails to provide the correct answer a significant part of the time and > > lookups often take 10 seconds or more. > > So apps should pass around a potnetially bogus list of addresses? so DNS should pass around a potentially bogus list of addresses while apps shouldn't? DNS is just another way of doing address referrals. It works well in some cases, less well in others. It never has been the only way to get addresses for a resource. > I am > all for multi-party apps, but fixing the real problem with DNS seems > like a better approach than a hack that will end up failing anyway. you can't fix some of those problems, they're fairly fundamental consequences of DNS's design. for instance, the wide variation in response times seems to be a direct result of having DNS widely federated and widely distributed and the resulting lack of any reliable RTT estimates in advance of many queries (so the party doing the querying doesn't know when to time out or fail over). a lot of the unreliability (at least, last time I looked) seemed to be due to lots of zone administrators not knowing how to configure slave servers or glue records properly or to update the sequence numbers. this is what happens when you let everybody run their own servers. not that it was a bad decision overall, but it does make the idea that DNS is the only way that a app should obtain addresses sort of dubious. > > > What about IPv6 changes that? > > > > nothing about IPv6 changes that, except that IPv6 has the built-in > > expectation that an app may have to deal wth multiple addresses and > > somehow choose one of those addresses without any knowledge as > > which ones are more likely to work than others. > > > > and you think *I'm* in a fantasy land. > > trying to build complex topological information directly into the app > will fail more often than not. Pass name strings and follow > draft-ietf-ipv6-default-addr-select-08.txt. It will not be as fast, but > it will be more reliable. some apps will be better off doing this, but this is not a tradeoff that you are qualified to make for all apps. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 26 16:08:06 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5QN85k7003808; Wed, 26 Jun 2002 16:08:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5QN85tS003807; Wed, 26 Jun 2002 16:08:05 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5QN82k7003800 for ; Wed, 26 Jun 2002 16:08:02 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA00853 for ; Wed, 26 Jun 2002 16:08:07 -0700 (PDT) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA19175 for ; Wed, 26 Jun 2002 17:08:06 -0600 (MDT) Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 26 Jun 2002 16:08:05 -0700 Message-ID: <2B81403386729140A3A899A8B39B046405E15D@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Fwd: IPv6 Scoped Addresses and Routing Protocols Thread-Index: AcIdWlQiwwJa4n7RRyayPgq0kyZNHQAChUYw From: "Michel Py" To: "Tony Hain" , "Robert Elz" , "Ralph Droms" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5QN82k7003801 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tony, > Tony Hain wrote: > Maybe the way to solve this is to take the 'must be 0' bits and > define them as 'locally administered' That is what we were talking about: site IDs in SL addresses. > with a clear note that FE00::/8 will be blocked on the > public net. How can you guarantee this? If customers demand their ISPs to leak SL addresses because customers see SL as a PI address they can't get otherwise, ISPs will take the money at some point. It is a terrible responsibility to embed everyone-gets-one-PI-address in the addressing architecture. If the policy groups decide to give a PI address to everyone, their call not us me thinks. > This would allow sites that want the hassle of coordinating multiple > private interconnects to do whatever they want (since they will > anyway if the implementations allow it), without leaving any > expectations that these are in any way globally unique. The way I see it is: If they are not globally unique, it serves no purpose. If they are, the fact that they will or will not be seen in the global routing table is a matter of money, not of addressing architecture. So, this can't happen now because there is too big of a temptation. How do we suppress the temptation? By providing people that want PI addresses and multihomers with an _aggregatable_ solution. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 26 16:34:17 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5QNYHk7003862; Wed, 26 Jun 2002 16:34:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5QNYGEY003861; Wed, 26 Jun 2002 16:34:16 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5QNYCk7003854 for ; Wed, 26 Jun 2002 16:34:13 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA11058 for ; Wed, 26 Jun 2002 16:34:18 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA00379 for ; Wed, 26 Jun 2002 17:34:18 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5QNRX207000; Wed, 26 Jun 2002 19:27:33 -0400 (EDT) Message-Id: <200206262327.g5QNRX207000@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Tony Hain" cc: "Ralph Droms" , "Michel Py" , "Robert Elz" , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-reply-to: (Your message of "Wed, 26 Jun 2002 14:28:58 PDT.") Date: Wed, 26 Jun 2002 19:27:33 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > And if the point is to end up with global addresses, we already have a > mechanism for those, so modifying SL to make them globally unique does > nothing. where in the world do you get the idea that all interconnection between IP networks is done using the public Internet? Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 26 16:42:57 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5QNguk7004003; Wed, 26 Jun 2002 16:42:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5QNguJQ004002; Wed, 26 Jun 2002 16:42:56 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5QNgqk7003995 for ; Wed, 26 Jun 2002 16:42:52 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA04466 for ; Wed, 26 Jun 2002 16:42:59 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA20750 for ; Wed, 26 Jun 2002 16:42:58 -0700 (PDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5QNbV207287; Wed, 26 Jun 2002 19:37:31 -0400 (EDT) Message-Id: <200206262337.g5QNbV207287@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Michel Py" cc: "Tony Hain" , "Robert Elz" , "Ralph Droms" , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-reply-to: (Your message of "Wed, 26 Jun 2002 16:08:05 PDT.") <2B81403386729140A3A899A8B39B046405E15D@server2000.arneill-py.sacramento.ca.us> Date: Wed, 26 Jun 2002 19:37:31 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Tony Hain wrote: > > Maybe the way to solve this is to take the 'must be 0' bits and > > define them as 'locally administered' > > That is what we were talking about: site IDs in SL addresses. > > > with a clear note that FE00::/8 will be blocked on the > > public net. > > How can you guarantee this? If customers demand their ISPs to leak SL > addresses because customers see SL as a PI address they can't get > otherwise, ISPs will take the money at some point. so what? an ISP can sell its own routing table space (and router cpu time) if it wishes. that doesn't mean that other ISPs have to propagate those advertisements, and there's a fair amount of incentive for them to not do so. > It is a terrible responsibility to embed everyone-gets-one-PI-address in > the addressing architecture. why do you think it's not an equally terrible responsible to say "nobody gets a global address prefix unless it's tied to a provider"? > If the policy groups decide to give a PI > address to everyone, their call not us me thinks. what makes you think that the policy groups are better qualified than we are to make such a decision? we have enough trouble understanding the various technical implications (at all protocol layers and above) of such a decision - the policy groups are even less knowledgable. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 26 17:16:03 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5R0G3k7004067; Wed, 26 Jun 2002 17:16:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5R0G2Go004066; Wed, 26 Jun 2002 17:16:02 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5R0Fxk7004059 for ; Wed, 26 Jun 2002 17:15:59 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA08482 for ; Wed, 26 Jun 2002 17:16:05 -0700 (PDT) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA26409 for ; Wed, 26 Jun 2002 18:16:05 -0600 (MDT) Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 26 Jun 2002 17:16:03 -0700 Message-ID: <2B81403386729140A3A899A8B39B046405E15E@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Fwd: IPv6 Scoped Addresses and Routing Protocols Thread-Index: AcIdapaKry83e7HiS3mJ6aWelp7+cgAA3wPg From: "Michel Py" To: "Keith Moore" Cc: "Tony Hain" , "Robert Elz" , "Ralph Droms" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5R0G0k7004060 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> Michel Py wrote: >> It is a terrible responsibility to embed everyone-gets-one >> PI-address in the addressing architecture. > Keith Moore wrote: > why do you think it's not an equally terrible responsible > to say "nobody gets a global address prefix unless it's > tied to a provider"? I don't. What part of my postings makes you think so? Tony and I are proposing schemes that are aggregatable and that are not tied to a provider. > what makes you think that the policy groups are better > qualified than we are to make such a decision? we have enough > trouble understanding the various technical implications (at > all protocol layers and above) of such a decision - the policy > groups are even less knowledgable. The policy groups have to deal with user pressure. Instead of questioning their competence, I prefer the path of providing them with a solution that gives them other options than desperate measures. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 26 23:01:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5R61tk7004796; Wed, 26 Jun 2002 23:01:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5R61tU3004795; Wed, 26 Jun 2002 23:01:55 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5R61qk7004788 for ; Wed, 26 Jun 2002 23:01:52 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA25016 for ; Wed, 26 Jun 2002 23:01:58 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.97.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA28618 for ; Thu, 27 Jun 2002 00:01:54 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g5R600V11112; Thu, 27 Jun 2002 13:00:02 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g5R5x6f07194; Thu, 27 Jun 2002 12:59:12 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: "Michel Py" cc: "Keith Moore" , "Tony Hain" , "Ralph Droms" , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-Reply-To: <2B81403386729140A3A899A8B39B046405E15E@server2000.arneill-py.sacramento.ca.us> References: <2B81403386729140A3A899A8B39B046405E15E@server2000.arneill-py.sacramento.ca.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 27 Jun 2002 12:59:06 +0700 Message-ID: <7192.1025157546@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 26 Jun 2002 17:16:03 -0700 From: "Michel Py" Message-ID: <2B81403386729140A3A899A8B39B046405E15E@server2000.arneill-py.sacramento.ca.us> | Tony and I are | proposing schemes that are aggregatable and that are not tied to a | provider. Unfortunately, they have just as many drawbacks - just different ones (in some cases). Both those schemes are geographic based addresses - these aggregate if and only if one assumes that areas that are geographically close are also topologically close. I have seen no evidence that there's any truth in this at all. They're provider independent only of there are multiple providers that have agreed to cooperate with each other and share the prefix (essentially routing packets to each other when they arrive at the "wrong" place). While that is entirely possible to assume might happen in some high density usage parts of the world, where multiple providers can all exist and make a profit, in much of the world, the simply aren't enough active users to support the infrastructure for multiple providers. Anyone would always be free to connect to a different provider, by simply connecting to a more distant location of course - but then their address would not (could not if any aggregation at all is to be achieved) be based upon their geography, but the provider's instead. That is, to change providers an address change is likely to be required for many (perhaps most) and for those it isn't, the provider choice will be limited to those who have managed to join the local provider club. On the other issue ... anyone can (attempt to) pay any ISP, or set of ISPs to carry any address. The rish is certainly no greater of that happening with a SL address with a site-id embedded, than it is for a global address allocated by a different provider, or a geographic address from some other region. If anything, the risk is less with SL addresses, as they can be clearly labelled "for local use only", lowering the chances that people will ever decide they would like to interpret them as global addresses (all of these things are just numbers, so perceptions, and what the ISPs will agree to do are all that matters anyway). Global addresses are expected to be globally visible, and there's no reason at all to assume that people won't go to a competitor ISP and say "I will connect to you, and pay you all these $'s if you will agree to advertise the prefix I have already been allocated this other way" (and even say to ISPs, "I will connect to you, and you allocate me an address, but you agree thatonce allocated you can never reclaim the address, no matter whether I stop paying you or not"). 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 Jun 27 00:32:38 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5R7Wbk7004863; Thu, 27 Jun 2002 00:32:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5R7WbSQ004862; Thu, 27 Jun 2002 00:32:37 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5R7WXk7004855 for ; Thu, 27 Jun 2002 00:32:34 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA03844 for ; Thu, 27 Jun 2002 00:32:38 -0700 (PDT) Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA17057 for ; Thu, 27 Jun 2002 01:32:36 -0600 (MDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5R7WBcK029706; Thu, 27 Jun 2002 09:32:11 +0200 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with SMTP id g5R7W8Z87202; Thu, 27 Jun 2002 09:32:09 +0200 Received: from dhcp23-199.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA61490 from ; Thu, 27 Jun 2002 09:32:02 +0200 Message-Id: <3D1ABFA7.58881411@hursley.ibm.com> Date: Thu, 27 Jun 2002 09:32:55 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Michael Thomas Cc: Michel Py , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols References: <4.3.2.7.2.20020623173820.00ba1978@funnel.cisco.com> <200206241420.g5OEKx206412@astro.cs.utk.edu> <15639.14004.691748.496554@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Michael Thomas wrote: ... > > The thing I don't understand is whether the > address aggregation problem introduced by a > new class of globally unique addresses is > really any worse than the existing problems > with route aggregation, and specifically about > mobility and multihoming. I've been staring at this for three days, and I think the answer (in the current state of the BGP art) is "yes", or at least the risk that it is "yes" is unacceptably high. Just stuffing some probably-unique bits into a SL is not going to generate aggregatable addresses; it's going to generate entropy in the routing table. > ...It's quite possible > that we could make things significantly worse > by introducing a new class of routing prefixes, > but as far as I understand, the ultimate fix > for routing table explosion isn't especially > well understood, and it may require its own > set of draconian measures *regardless* of > site locals. True, but let's not make things even worse in the meantime, by inventing non-aggregatable pseudo-global local addresses. We don't need them; we've got aggregatable real global addresses, and we can perfectly well use them for the sort of bilateral private routing setups that Keith mentioned. Michel Py wrote: > >> It is a terrible responsibility to embed everyone-gets-one > >> PI-address in the addressing architecture. > > > Keith Moore wrote: > > why do you think it's not an equally terrible responsible > > to say "nobody gets a global address prefix unless it's > > tied to a provider"? > > I don't. What part of my postings makes you think so? Tony and I are > proposing schemes that are aggregatable and that are not tied to a > provider. For the record, you've yet to persuade me that these schemes are aggregatable in the real world of competitive ISPs. 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 Jun 27 00:58:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5R7wOk7004961; Thu, 27 Jun 2002 00:58:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5R7wO4K004960; Thu, 27 Jun 2002 00:58:24 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5R7wLk7004953 for ; Thu, 27 Jun 2002 00:58:21 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA07466 for ; Thu, 27 Jun 2002 00:58:26 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA05118 for ; Thu, 27 Jun 2002 00:58:25 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g5R7wOR23030 for ; Thu, 27 Jun 2002 10:58:24 +0300 Date: Thu, 27 Jun 2002 10:58:24 +0300 (EEST) From: Pekka Savola To: ipng@sunroof.eng.sun.com Subject: Re: draft-miyakawa-ipv6-prefix-delegation-requirement-00.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, Just one comment for this rough draft. - negotiation between ISP and site [...] On the other hand, a site should be able to request multiple prefixes to the ISP. [...] ==> I'm not sure if that's really necessary. What kind of scenario do you have in mind? In addition, as this section (coupled with some practical priorization from 'layer 2 consideration') is the most important when considering the possible solutions, the different requirements etc. should probably be elaborated a bit more. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 27 08:01:53 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RF1rk7005554; Thu, 27 Jun 2002 08:01:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5RF1rKZ005553; Thu, 27 Jun 2002 08:01:53 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RF1nk7005546 for ; Thu, 27 Jun 2002 08:01:49 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA01699 for ; Thu, 27 Jun 2002 08:01:54 -0700 (PDT) Received: from tndh.net (evrtwa1-ar8-4-65-028-011.evrtwa1.dsl-verizon.net [4.65.28.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA19839 for ; Thu, 27 Jun 2002 09:01:53 -0600 (MDT) Received: from eagleswings (127.0.0.1) by localhost (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Thu, 27 Jun 2002 08:02:51 -0700 From: "Tony Hain" To: "Robert Elz" , "Michel Py" Cc: "Keith Moore" , "Ralph Droms" , Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols Date: Thu, 27 Jun 2002 08:00:28 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <7192.1025157546@munnari.OZ.AU> Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert Elz wrote: > ... > If anything, the risk is less with SL addresses, as they can > be clearly > labelled "for local use only", lowering the chances that > people will ever > decide they would like to interpret them as global addresses > (all of these > things are just numbers, so perceptions, and what the ISPs > will agree to > do are all that matters anyway). Global addresses are expected to be > globally visible, and there's no reason at all to assume that > people won't > go to a competitor ISP and say "I will connect to you, and pay you all > these $'s if you will agree to advertise the prefix I have > already been > allocated this other way" (and even say to ISPs, "I will > connect to you, > and you allocate me an address, but you agree thatonce > allocated you can > never reclaim the address, no matter whether I stop paying > you or not"). The problem is that the local ISP has every motivation to take the money with no substantial costs, because those appear at the aggregating transit providers upstream. While it sounds nice to say we will legislate against that, reality is that it will happen, so the only reasonable defense is to provide an alternative that scales. Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 27 08:06:34 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RF6Yk7005580; Thu, 27 Jun 2002 08:06:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5RF6X3A005579; Thu, 27 Jun 2002 08:06:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RF6Uk7005572 for ; Thu, 27 Jun 2002 08:06:30 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA23338 for ; Thu, 27 Jun 2002 08:06:35 -0700 (PDT) Received: from tndh.net (evrtwa1-ar8-4-65-028-011.evrtwa1.dsl-verizon.net [4.65.28.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA22900 for ; Thu, 27 Jun 2002 09:06:34 -0600 (MDT) Received: from eagleswings (127.0.0.1) by localhost (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Thu, 27 Jun 2002 08:07:38 -0700 From: "Tony Hain" To: "Brian E Carpenter" , "Michael Thomas" Cc: "Michel Py" , Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols Date: Thu, 27 Jun 2002 08:05:14 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <3D1ABFA7.58881411@hursley.ibm.com> Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian E Carpenter wrote: > ... > > I don't. What part of my postings makes you think so? Tony and I are > > proposing schemes that are aggregatable and that are not tied to a > > provider. > > For the record, you've yet to persuade me that these schemes are > aggregatable in the real world of competitive ISPs. I understand the concern, but it comes down to a matter of cost/benefit tradeoff. If a geo scheme turns out to be cheaper to maintain than an ever expanding table full of holes, it will be deployed. The task at hand is finding *any* scheme that will create provider independent addresses in an operationally sound way. Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 27 08:45:42 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RFjgk7005683; Thu, 27 Jun 2002 08:45:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5RFjffj005682; Thu, 27 Jun 2002 08:45:41 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RFjbk7005675 for ; Thu, 27 Jun 2002 08:45:37 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA03039 for ; Thu, 27 Jun 2002 08:45:39 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA26434 for ; Thu, 27 Jun 2002 09:45:38 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5RFe8220266; Thu, 27 Jun 2002 11:40:09 -0400 (EDT) Message-Id: <200206271540.g5RFe8220266@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Tony Hain" cc: "Robert Elz" , "Michel Py" , "Keith Moore" , "Ralph Droms" , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-reply-to: (Your message of "Thu, 27 Jun 2002 08:00:28 PDT.") Date: Thu, 27 Jun 2002 11:40:08 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The problem is that the local ISP has every motivation to take the money > with no substantial costs, because those appear at the aggregating > transit providers upstream. While it sounds nice to say we will > legislate against that, reality is that it will happen, so the only > reasonable defense is to provide an alternative that scales. Your conclusion doesn't follow. If upstream providers don't already have a mechanism to filter out bogus route advertisements, surely it can be developed - particularly when the bogus prefixes are easily identified. I'd be happy to see a scalable alternative to provider-based addressing, but that's not a good argument against SLs with site-ids. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 27 09:11:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RGB7k7005709; Thu, 27 Jun 2002 09:11:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5RGB78R005708; Thu, 27 Jun 2002 09:11:07 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RGB4k7005701 for ; Thu, 27 Jun 2002 09:11:04 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA04939 for ; Thu, 27 Jun 2002 09:11:09 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA20087 for ; Thu, 27 Jun 2002 10:11:09 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g5RGB6a08106; Thu, 27 Jun 2002 18:11:06 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id SAA27170; Thu, 27 Jun 2002 18:11:06 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id g5RGB5GF085060; Thu, 27 Jun 2002 18:11:05 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200206271611.g5RGB5GF085060@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: lassi.hippelainen@nokia.com cc: ipng@sunroof.eng.sun.com Subject: Re: Security considerations over RFC3041 (was: IPv6 w.g. Last Call on "IPv6 for...) In-reply-to: Your message of Wed, 22 May 2002 18:01:34 +0300. Date: Thu, 27 Jun 2002 18:11:05 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: On Wed, 22 May 2002, Pekka Savola and Hesham Soliman (ERA) wrote: <...> >>Actually, as a side >> node, I think 2462 should be deprecated and replaced by >> 3041....please don't shoot! > >Where did I put my M16..... ;-) > >In the meantime, you might want to check out >draft-dupont-ipv6-rfc3041harmful-00.txt .. there's an omission or two, but >should be recommended reading for RFC3041 advocates :-) => I am revisiting my draft so if you want to participate I'll post the new version only late (Sunday after Brasil's victory :-). Regards Francis.Dupont@enst-bretagne.fr PS: my purpose is to get the next version of RFC 3041 with a better security considerations section. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 27 09:21:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RGLjk7005734; Thu, 27 Jun 2002 09:21:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5RGLj9l005733; Thu, 27 Jun 2002 09:21:45 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RGLfk7005726 for ; Thu, 27 Jun 2002 09:21:41 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA08882 for ; Thu, 27 Jun 2002 09:21:46 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA05092 for ; Thu, 27 Jun 2002 09:21:46 -0700 (PDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5RGLc226234; Thu, 27 Jun 2002 12:21:38 -0400 (EDT) Message-Id: <200206271621.g5RGLc226234@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Brian E Carpenter cc: Michael Thomas , Michel Py , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-reply-to: (Your message of "Thu, 27 Jun 2002 09:32:55 +0200.") <3D1ABFA7.58881411@hursley.ibm.com> Date: Thu, 27 Jun 2002 12:21:38 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I've been staring at this for three days, and I think the > answer (in the current state of the BGP art) is "yes", or > at least the risk that it is "yes" is unacceptably high. > Just stuffing some probably-unique bits into a SL is not > going to generate aggregatable addresses; it's going to > generate entropy in the routing table. the premise has to be that SL + site-ids are NOT going to get advertised to the public routing tables. if there's not a mechanism for preventing this now, we need to invent one. but that's not a reason to force or even encourage sites to use non-unique prefixes, especially when SLs without site-ids cause problems for distributed applications. SLs with site-ids might be acceptable, but we really need to get rid of SLs without site-ids. > True, but let's not make things even worse in the meantime, > by inventing non-aggregatable pseudo-global local addresses. > We don't need them; we've got aggregatable real global addresses, > and we can perfectly well use them for the sort of bilateral > private routing setups that Keith mentioned. please explain how my private network can get a aggregatable real global address when it doesn't connect to the public internet. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 27 09:30:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RGU9k7005858; Thu, 27 Jun 2002 09:30:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5RGU8Ff005857; Thu, 27 Jun 2002 09:30:08 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RGU5k7005847 for ; Thu, 27 Jun 2002 09:30:05 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA12495 for ; Thu, 27 Jun 2002 09:30:10 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA02831 for ; Thu, 27 Jun 2002 10:30:10 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g5RGU5a10867; Thu, 27 Jun 2002 18:30:06 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id SAA27489; Thu, 27 Jun 2002 18:30:06 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id g5RGU4GF085196; Thu, 27 Jun 2002 18:30:05 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200206271630.g5RGU4GF085196@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Das, Kaustubh" cc: ipng@sunroof.eng.sun.com Subject: Re: Comments on In-reply-to: Your message of Thu, 06 Jun 2002 11:17:47 PDT. <8A9A5F4E6576D511B98F00508B68C20A0D56E4A3@orsmsx106.jf.intel.com> Date: Thu, 27 Jun 2002 18:30:04 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: In titled "RFC 3041 considered harmful" Francis argues that rfc 3041 gives no privacy benefit whilst increasing complexity and making DDoS attacks easier. => yes, I maintain my argument (but if you can improve the wording in order to make it clearer...). IMO section 2 which states that privacy extensions "... give only complexity with no benefit" is logically flawed. I quote the relevant sentences from section 2 below ______________________________ "Note the interface identifier is only the half of the whole address, and to change the interface identifier when the prefix remains the same shall not improve the privacy... => IMHO this is the basic limitation of RFC 3041: it changes only one part of the address. There are only two cases where privacy extensions can be justified: where the link has a very high number of nodes or ......" => this comes from the observation that RFC 3041 is fully useless if the link has only one node. ______________________________ I argue that the number of nodes on the link has little to do with existence of privacy for the following reasons:- Defn: Privacy is achieved if when a node X corresponds with a server S, the server S cannot 'unambiguously' associate the IP addr for Node X with the physical machine. If you agree with the defn..... => I disagree. One can track users in place of physical machines, and may assume long prefixes are associated to a low number of users, for instance a dialup /48 is associated to at most a family. Consider a link with 2 nodes (low number of nodes) X and Y each changing its suffix as prescribed in 3041. When one of these nodes, Node X contacts a server with addr A1, can the server later unambiguously associate that IP with this node? The answer is No; since the other node, node Y could have had the address A1. The key to the argument is that it is not enough to have a high probability of association of an address with a physical machine to say that privacy is broken. => no, what we should protect is the privacy of human beings, not of physical machines. Therefore either both the prefix and the IID are changed, or there are a large number of users (so physical machines) sharing the same prefix (i.e., making it useless for tracking purposes). Regards Francis.Dupont@enst-bretagne.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 Thu Jun 27 09:42:59 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RGgxk7005920; Thu, 27 Jun 2002 09:42:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5RGgxtX005919; Thu, 27 Jun 2002 09:42:59 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RGgtk7005912 for ; Thu, 27 Jun 2002 09:42:56 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA21234 for ; Thu, 27 Jun 2002 09:43:01 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA05044 for ; Thu, 27 Jun 2002 10:43:01 -0600 (MDT) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g5RGgtL0012029; Thu, 27 Jun 2002 09:42:55 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ABY57554; Thu, 27 Jun 2002 09:40:06 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA17960; Thu, 27 Jun 2002 09:42:54 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15643.16526.303450.775672@thomasm-u1.cisco.com> Date: Thu, 27 Jun 2002 09:42:54 -0700 (PDT) To: Keith Moore Cc: Brian E Carpenter , Michael Thomas , Michel Py , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-Reply-To: <200206271621.g5RGLc226234@astro.cs.utk.edu> References: <3D1ABFA7.58881411@hursley.ibm.com> <200206271621.g5RGLc226234@astro.cs.utk.edu> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith Moore writes: > > I've been staring at this for three days, and I think the > > answer (in the current state of the BGP art) is "yes", or > > at least the risk that it is "yes" is unacceptably high. > > Just stuffing some probably-unique bits into a SL is not > > going to generate aggregatable addresses; it's going to > > generate entropy in the routing table. > > the premise has to be that SL + site-ids are NOT going to > get advertised to the public routing tables. if there's not > a mechanism for preventing this now, we need to invent one. > but that's not a reason to force or even encourage sites > to use non-unique prefixes, especially when SLs without > site-ids cause problems for distributed applications. Define "public". Given the peerwise distribution of routes, isn't the distinction of "public" rather arbitrary? If I convince my provider to route my site local prefix across their backbone (but not leaked outside their AS's), is that a violation? What about if my provider then convinces their upstream provider to do likewise to extend my reach? Is that public? And how likely is it that ISP's would pay attention to any such strictures if they figured it was an easy way to build what is for all intents and purposes a VPN of the MPLS variety? Mike -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 27 09:53:25 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RGrOk7005955; Thu, 27 Jun 2002 09:53:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5RGrOuT005954; Thu, 27 Jun 2002 09:53:24 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RGrKk7005947 for ; Thu, 27 Jun 2002 09:53:20 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA25096 for ; Thu, 27 Jun 2002 09:53:26 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA23824 for ; Thu, 27 Jun 2002 09:53:26 -0700 (PDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5RGrE201323; Thu, 27 Jun 2002 12:53:14 -0400 (EDT) Message-Id: <200206271653.g5RGrE201323@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Michael Thomas cc: Keith Moore , Brian E Carpenter , Michel Py , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-reply-to: (Your message of "Thu, 27 Jun 2002 09:42:54 PDT.") <15643.16526.303450.775672@thomasm-u1.cisco.com> Date: Thu, 27 Jun 2002 12:53:14 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > I've been staring at this for three days, and I think the > > > answer (in the current state of the BGP art) is "yes", or > > > at least the risk that it is "yes" is unacceptably high. > > > Just stuffing some probably-unique bits into a SL is not > > > going to generate aggregatable addresses; it's going to > > > generate entropy in the routing table. > > > > the premise has to be that SL + site-ids are NOT going to > > get advertised to the public routing tables. if there's not > > a mechanism for preventing this now, we need to invent one. > > but that's not a reason to force or even encourage sites > > to use non-unique prefixes, especially when SLs without > > site-ids cause problems for distributed applications. > > Define "public". Given the peerwise distribution > of routes, isn't the distinction of "public" > rather arbitrary? If I convince my provider to > route my site local prefix across their backbone > (but not leaked outside their AS's), is that a > violation? What about if my provider then convinces > their upstream provider to do likewise to extend > my reach? Is that public? And how likely is it that > ISP's would pay attention to any such strictures if > they figured it was an easy way to build what is > for all intents and purposes a VPN of the MPLS > variety? my opinion is that the space in an ISP's routing tables and the cpu time of their routers belongs to the ISP and the ISP can (and will) do whatever it wishes with it, as long as they keep their agreements. the fact that these are limited resources will quite naturally result in pressure to limit the scope of advertisement of non-aggregatable addresses. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 27 10:01:38 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RH1bk7006007; Thu, 27 Jun 2002 10:01:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5RH1bpr006006; Thu, 27 Jun 2002 10:01:37 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RH1Yk7005999 for ; Thu, 27 Jun 2002 10:01:34 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA28177 for ; Thu, 27 Jun 2002 10:01:40 -0700 (PDT) Received: from roam.psg.com (H-135-207-4-110.research.att.com [135.207.4.110]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA09180 for ; Thu, 27 Jun 2002 11:01:38 -0600 (MDT) Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17NceG-0009gF-00; Thu, 27 Jun 2002 10:01:36 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Keith Moore Cc: ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols References: <15643.16526.303450.775672@thomasm-u1.cisco.com> <200206271653.g5RGrE201323@astro.cs.utk.edu> Message-Id: Date: Thu, 27 Jun 2002 10:01:36 -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > my opinion is that the space in an ISP's routing tables > and the cpu time of their routers belongs to the ISP and > the ISP can (and will) do whatever it wishes with it, as > long as they keep their agreements. the fact that these > are limited resources will quite naturally result in > pressure to limit the scope of advertisement of > non-aggregatable addresses. this was what happened back in '93 or '94 when a large isp had/chose to install pretty serious prefix length filters to keep their routers from falling over. much flamage, even some rational-seeming discussion. but the point you make was the bottom line. randy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 27 10:12:50 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RHCok7006057; Thu, 27 Jun 2002 10:12:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5RHCnUP006056; Thu, 27 Jun 2002 10:12:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RHCjk7006049 for ; Thu, 27 Jun 2002 10:12:45 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA00168 for ; Thu, 27 Jun 2002 10:12:51 -0700 (PDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA11336 for ; Thu, 27 Jun 2002 11:12:50 -0600 (MDT) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g5RHCiBW023181; Thu, 27 Jun 2002 10:12:44 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ABY58448; Thu, 27 Jun 2002 10:09:55 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA17964; Thu, 27 Jun 2002 10:12:43 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15643.18314.879313.315434@thomasm-u1.cisco.com> Date: Thu, 27 Jun 2002 10:12:42 -0700 (PDT) To: Keith Moore Cc: Michael Thomas , Brian E Carpenter , Michel Py , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-Reply-To: <200206271653.g5RGrE201323@astro.cs.utk.edu> References: <15643.16526.303450.775672@thomasm-u1.cisco.com> <200206271653.g5RGrE201323@astro.cs.utk.edu> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith Moore writes: > > Define "public". Given the peerwise distribution > > of routes, isn't the distinction of "public" > > rather arbitrary? If I convince my provider to > > route my site local prefix across their backbone > > (but not leaked outside their AS's), is that a > > violation? What about if my provider then convinces > > their upstream provider to do likewise to extend > > my reach? Is that public? And how likely is it that > > ISP's would pay attention to any such strictures if > > they figured it was an easy way to build what is > > for all intents and purposes a VPN of the MPLS > > variety? > > my opinion is that the space in an ISP's routing tables > and the cpu time of their routers belongs to the ISP and > the ISP can (and will) do whatever it wishes with it, as > long as they keep their agreements. the fact that these > are limited resources will quite naturally result in > pressure to limit the scope of advertisement of > non-aggregatable addresses. Right -- unless they can make a buck off of it. As I understand it, we don't have anything that really approaches a "public network" where global routes are just advertised. Whether routes are advertised or not is much more of a business decision than a common weal obligation. If the business pressures are such that with stupid router tricks(tm) you can make more money on less infrastructure even though it's not a globally healthy thing to do, I think we better not delude ourselves. Site locals definitely toe this line. Alas, the urge to overlay networks seems too strong. "What holds up the network? Why, it's networks all the way down!" Mike -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 27 10:32:07 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RHW7k7006216; Thu, 27 Jun 2002 10:32:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5RHW7q6006215; Thu, 27 Jun 2002 10:32:07 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RHW3k7006208 for ; Thu, 27 Jun 2002 10:32:03 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA10578 for ; Thu, 27 Jun 2002 10:32:07 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA20994 for ; Thu, 27 Jun 2002 11:32:04 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5RHVu206423; Thu, 27 Jun 2002 13:31:56 -0400 (EDT) Message-Id: <200206271731.g5RHVu206423@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Michael Thomas cc: Keith Moore , Brian E Carpenter , Michel Py , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-reply-to: (Your message of "Thu, 27 Jun 2002 10:12:42 PDT.") <15643.18314.879313.315434@thomasm-u1.cisco.com> Date: Thu, 27 Jun 2002 13:31:56 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Keith Moore writes: > > > Define "public". Given the peerwise distribution > > > of routes, isn't the distinction of "public" > > > rather arbitrary? If I convince my provider to > > > route my site local prefix across their backbone > > > (but not leaked outside their AS's), is that a > > > violation? What about if my provider then convinces > > > their upstream provider to do likewise to extend > > > my reach? Is that public? And how likely is it that > > > ISP's would pay attention to any such strictures if > > > they figured it was an easy way to build what is > > > for all intents and purposes a VPN of the MPLS > > > variety? > > > > my opinion is that the space in an ISP's routing tables > > and the cpu time of their routers belongs to the ISP and > > the ISP can (and will) do whatever it wishes with it, as > > long as they keep their agreements. the fact that these > > are limited resources will quite naturally result in > > pressure to limit the scope of advertisement of > > non-aggregatable addresses. > > Right -- unless they can make a buck off of it. as much as I appreciate the limitations of laissez-faire economics, I don't see anything particularly wrong with it in this particular case. the fact that ISPs can make a buck off of selling an entry in their routing table doesn't mean they can sell significant numbers of additional entries - at last not unless a significant breakthrough in routing computation is discovered (entirely possible, but I'll believe in it when the router vendors have it in shipping product). the real question is whether ISPs will honor SL prefixes in the absence of explicit compensation to do so. My guess (based on current technology) is "no", but they're welcome to do so if they can manage to deal with the flood. also, in the IPv4 world there is a sort of slippery slope - there is no magical number of prefix bits, and no designated bit pattern, that distinguishes one kind of network from another. so it requires some justification to block advertisements of some prefixes of length N while honoring advertisements of other prefixes of length N. and it's easy to have a "what's one more prefix bit among friends?" attitude. But IPv6 does have very visible distinctions, and doesn't normally delegate on arbitrary bit boundaries, which makes it easier for an ISP to push back on every prefix in a given category. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 27 11:03:52 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RI3qk7006342; Thu, 27 Jun 2002 11:03:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5RI3qHO006341; Thu, 27 Jun 2002 11:03:52 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RI3nk7006334 for ; Thu, 27 Jun 2002 11:03:49 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA06178 for ; Thu, 27 Jun 2002 11:03:53 -0700 (PDT) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA20216 for ; Thu, 27 Jun 2002 12:03:53 -0600 (MDT) Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 27 Jun 2002 11:03:52 -0700 Received: from 157.54.8.109 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 27 Jun 2002 11:03:52 -0700 Received: from red-msg-06.redmond.corp.microsoft.com ([157.54.12.71]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 27 Jun 2002 11:03:52 -0700 x-mimeole: Produced By Microsoft Exchange V6.0.6177.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Comments on Date: Thu, 27 Jun 2002 11:03:51 -0700 Message-ID: <7695E2F6903F7A41961F8CF888D87EA8063CED87@red-msg-06.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on Thread-Index: AcId+EFKfYUGp2zAR5+1b+1Ip1veVwAC1AKg From: "Richard Draves" To: "Francis Dupont" Cc: X-OriginalArrivalTime: 27 Jun 2002 18:03:52.0472 (UTC) FILETIME=[FEE1F980:01C21E04] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5RI3nk7006335 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Even if the adversary somehow knows there is only one machine per subnet, I think RFC 3041 still enhances privacy. First, it hides the manufacturer of your network card. Second, it prevents the adversary from tracking usage of the network card across multiple subnets. This is important for mobile devices. 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 Jun 27 11:14:16 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RIEFk7006379; Thu, 27 Jun 2002 11:14:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5RIEF1T006378; Thu, 27 Jun 2002 11:14:15 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RIECk7006371 for ; Thu, 27 Jun 2002 11:14:12 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA26745 for ; Thu, 27 Jun 2002 11:14:16 -0700 (PDT) Received: from tndh.net (evrtwa1-ar8-4-65-028-011.evrtwa1.dsl-verizon.net [4.65.28.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA21737 for ; Thu, 27 Jun 2002 12:14:16 -0600 (MDT) Received: from eagleswings (127.0.0.1) by localhost (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Thu, 27 Jun 2002 11:15:15 -0700 From: "Tony Hain" To: Cc: "Robert Elz" , "Michel Py" , "Ralph Droms" , Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols Date: Thu, 27 Jun 2002 11:12:37 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <200206271540.g5RFe8220266@astro.cs.utk.edu> Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith Moore wrote: > ... > I'd be happy to see a scalable alternative to provider-based > addressing, > but that's not a good argument against SLs with site-ids. I was not arguing against SLs with site-ids, just that we should not try in any way to lead people down the path where those site-ids are perceived to be globally unique. As long as the site-id is a locally administered value, a network administrator can use them privately in any way he sees fit, including private connections to other networks (assuming they can coordinate amongst themselves to avoid collisions). My primary concern is that we avoid building what amounts to an address registry of global scope, which ends up maximizes entropy in the routing system. Yes we need PI public space, see: draft-hain-ipv6-pi-addr-use-02.txt for some of the reasons why. The actual mechanism is still to be resolved, but the fundemental need remains. We also need space that is set aside for private use, and the SL space does that with the exception that it tried to legislate that /16-/48 must be 0. If I were building a network, since FEC0: is defined for local use, I see no reason that I would leave those bits as 0. Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 27 11:23:01 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RIN0k7006472; Thu, 27 Jun 2002 11:23:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5RIN0le006471; Thu, 27 Jun 2002 11:23:00 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RIMuk7006461 for ; Thu, 27 Jun 2002 11:22:56 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA13380 for ; Thu, 27 Jun 2002 11:23:01 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA26577 for ; Thu, 27 Jun 2002 12:23:00 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5RIHj208320; Thu, 27 Jun 2002 14:17:46 -0400 (EDT) Message-Id: <200206271817.g5RIHj208320@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Tony Hain" cc: moore@cs.utk.edu, "Robert Elz" , "Michel Py" , "Ralph Droms" , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-reply-to: (Your message of "Thu, 27 Jun 2002 11:12:37 PDT.") Date: Thu, 27 Jun 2002 14:17:45 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > ... > > I'd be happy to see a scalable alternative to provider-based > > addressing, > > but that's not a good argument against SLs with site-ids. > > I was not arguing against SLs with site-ids, just that we should not try > in any way to lead people down the path where those site-ids are > perceived to be globally unique. I disagree in the strongest possible terms. It's absolutely insane to expect applications (that may spam more than one site) to have to deal with ambiguous addresses. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 27 12:10:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RJAfk7006902; Thu, 27 Jun 2002 12:10:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5RJAfmA006901; Thu, 27 Jun 2002 12:10:41 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RJAbk7006894 for ; Thu, 27 Jun 2002 12:10:38 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA25491 for ; Thu, 27 Jun 2002 12:10:43 -0700 (PDT) Received: from tndh.net (evrtwa1-ar8-4-65-028-011.evrtwa1.dsl-verizon.net [4.65.28.11]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA24562 for ; Thu, 27 Jun 2002 13:10:42 -0600 (MDT) Received: from eagleswings (127.0.0.1) by localhost (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Thu, 27 Jun 2002 12:11:45 -0700 From: "Tony Hain" To: Cc: "Robert Elz" , "Michel Py" , "Ralph Droms" , Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols Date: Thu, 27 Jun 2002 12:09:01 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <200206271817.g5RIHj208320@astro.cs.utk.edu> Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith Moore wrote: > ... > > I was not arguing against SLs with site-ids, just that we > should not try > > in any way to lead people down the path where those site-ids are > > perceived to be globally unique. > > I disagree in the strongest possible terms. > > It's absolutely insane to expect applications (that may spam more > than one site) to have to deal with ambiguous addresses. Well any app that is generating 'spam' should be restrained.... You missed the point of what I was saying. Within the context of a private network of one or more sites, there should be no ambiguity because the local manager is in control of the proposed site-id bits. If two or more private networks want to join togther and form a larger private network, as long as they coordinate the site-id bits, there will still be no ambiguity. If an application wants to depart from the confines of a private network, it should not be using private addresses. We already have PA space for public use, and some activity around PI space. Since the scope of a private network is managed by the local administrator, there is no need make SL space globally unique. I agree it needs to by unique within a private network. Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 27 12:11:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RJB8k7006912; Thu, 27 Jun 2002 12:11:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5RJB8XV006911; Thu, 27 Jun 2002 12:11:08 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RJB3k7006904 for ; Thu, 27 Jun 2002 12:11:03 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA25645 for ; Thu, 27 Jun 2002 12:11:08 -0700 (PDT) Received: from esunmail ([129.147.58.121]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA07717 for ; Thu, 27 Jun 2002 13:11:08 -0600 (MDT) Received: from xpa-fe2 (esunmail-ge1 [129.147.58.122]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 0.3 (built May 13 2002)) with ESMTP id <0GYD00E6PPAJ2Y@edgemail1.Central.Sun.COM> for ipng@sunroof.eng.sun.com; Thu, 27 Jun 2002 13:11:08 -0600 (MDT) Received: from localhost ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 0.2 (built Apr 26 2002)) with ESMTPSA id <0GYD00DYCPAI5D@mail.sun.net> for ipng@sunroof.eng.sun.com; Thu, 27 Jun 2002 13:11:07 -0600 (MDT) Date: Thu, 27 Jun 2002 12:11:05 -0700 From: Alain Durand Subject: Re: Comments on In-reply-to: <7695E2F6903F7A41961F8CF888D87EA8063CED87@red-msg-06.redmond.corp.microsoft.com> To: Richard Draves Cc: Francis Dupont , ipng@sunroof.eng.sun.com Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.482) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thursday, June 27, 2002, at 11:03 AM, Richard Draves wrote: > Even if the adversary somehow knows there is only one machine per > subnet, I think RFC 3041 still enhances privacy. > > First, it hides the manufacturer of your network card. > > Second, it prevents the adversary from tracking usage of the network > card across multiple subnets. This is important for mobile devices. I thought the goal was to protect people's privacy and obviously I was wrong... ;-) What 3041 achieves is to make traceability in IPv6 the same as traceability in IPv4+NAT. One can track my IPv6 prefix/household identifier the same way one can track the IPv4 global address of my NAT box/house hold identifier but no one can say that I'm typing this message from a computer with a nic. - 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 Jun 27 12:12:30 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RJCTk7006936; Thu, 27 Jun 2002 12:12:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5RJCTOd006935; Thu, 27 Jun 2002 12:12:29 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RJCPk7006928 for ; Thu, 27 Jun 2002 12:12:26 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA19631 for ; Thu, 27 Jun 2002 12:12:31 -0700 (PDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA13052 for ; Thu, 27 Jun 2002 12:12:30 -0700 (PDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5RJChj01337 for ; Thu, 27 Jun 2002 14:12:43 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 27 Jun 2002 14:12:28 -0500 Message-ID: <933FADF5E673D411B8A30002A5608A0E0465409B@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: ipng@sunroof.eng.sun.com Subject: Site Locals and the DFZ Date: Thu, 27 Jun 2002 14:12:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C21E0E.94178520" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C21E0E.94178520 Content-Type: text/plain; charset="iso-8859-1" There has recently been a very large discussion about site locals in the thread, "Re: Fwd: IPv6 Scoped Addresses and Routing Protocols". Paul Francis' draft and this discussion has made me wonder if there might be a use for an aggregatable concept of site locals in the context of an Internet Default Free Zone, DFZ. I am hoping that this new thread can be used to begin discussion on the open mail list of such a concept, the possible uses, impacts and ramifications, pros, cons and the feasibility of these uses. I guess the first question to pose is should the DFZ be a network (i.e. more than just a set of L2 links) of sorts and be treated as a site of some kind as well and for what useful purpose? Another question would be is the DFZ a site? Thanks, Glenn ------_=_NextPart_001_01C21E0E.94178520 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Site Locals and the DFZ

There has recently been a very large discussion about = site locals in the thread, "Re: Fwd: IPv6 Scoped Addresses and = Routing Protocols". Paul Francis' draft and this discussion has = made me wonder if there might be a use for an aggregatable concept of = site locals in the context of an Internet Default Free Zone, DFZ. =

I am hoping that this new thread can be used to begin = discussion on the open mail list of such a concept, the possible uses, = impacts and ramifications, pros, cons and the feasibility of these = uses.

I guess the first question to pose is should the DFZ = be a network (i.e. more than just a set of L2 links) of sorts and be = treated as a site of some kind as well and for what useful purpose? = Another question would be is the DFZ a site?

Thanks,

Glenn

------_=_NextPart_001_01C21E0E.94178520-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 27 12:24:14 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RJODk7006958; Thu, 27 Jun 2002 12:24:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5RJODgE006957; Thu, 27 Jun 2002 12:24:13 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RJO9k7006950 for ; Thu, 27 Jun 2002 12:24:09 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA00332 for ; Thu, 27 Jun 2002 12:24:14 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA01699 for ; Thu, 27 Jun 2002 13:24:14 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5RJIa208733; Thu, 27 Jun 2002 15:18:36 -0400 (EDT) Message-Id: <200206271918.g5RJIa208733@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Tony Hain" cc: moore@cs.utk.edu, "Robert Elz" , "Michel Py" , "Ralph Droms" , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-reply-to: (Your message of "Thu, 27 Jun 2002 12:09:01 PDT.") Date: Thu, 27 Jun 2002 15:18:36 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Well any app that is generating 'spam' should be restrained.... > > You missed the point of what I was saying. Within the context of a > private network of one or more sites, there should be no ambiguity > because the local manager is in control of the proposed site-id bits. no, because there is more than one site, and there is more than one local manager, and given enough private interconnections the chances of a conflict start to become significant. (in other words, it's not reasonable to assume that a private network is well-bounded or that it doesn't interconnect with other networks that do connect to the public network. and even if those networks don't provide transit to the between the public network and private network there may be apps that have to deal with addresses from both types of networks) if you have enough bits for the site-id you can make the probability of a conflict approach zero *provided* the site bits are randomly chosen. but the easiest way to avoid conflicts is to make the site-id globally unique, and there's no good reason to not do so. now if we really get PI space set up in such a way that any site can get a unique chunk of PI space whether or not it is connected to any public network, that would remove the need for unique SL prefixes, and that would be fine with me. but while I'm glad people are working on proposals to do that, I'm not holding my breath waiting for it to happen. if we end up with both unique SL addresses and PI addresses, that's not a horrible thing. but SL addresses without a site-id just cause more harm than good, and they really need to be eliminated in favor of unique SL addresses, unique PI addresses, or both. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 27 12:37:25 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RJbPk7006983; Thu, 27 Jun 2002 12:37:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5RJbOdt006982; Thu, 27 Jun 2002 12:37:24 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RJbLk7006975 for ; Thu, 27 Jun 2002 12:37:21 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA10882 for ; Thu, 27 Jun 2002 12:37:26 -0700 (PDT) Received: from mail7.nc.rr.com (mail7.southeast.rr.com [24.93.67.54]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA25498 for ; Thu, 27 Jun 2002 12:37:26 -0700 (PDT) Received: from nc.rr.com ([24.162.252.183]) by mail7.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Thu, 27 Jun 2002 15:36:17 -0400 Message-ID: <3D1B6886.14724D73@nc.rr.com> Date: Thu, 27 Jun 2002 15:33:26 -0400 From: Brian Haberman X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Keith Moore CC: ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols References: <200206271918.g5RJIa208733@astro.cs.utk.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith, Keith Moore wrote: > > if you have enough bits for the site-id you can make the probability > of a conflict approach zero *provided* the site bits are randomly > chosen. but the easiest way to avoid conflicts is to make the > site-id globally unique, and there's no good reason to not do so. Who delegates the globally-unique site-ids? If the site-ids are globally unique, how are they any different from global addresses? 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 Jun 27 12:51:40 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RJpdk7007083; Thu, 27 Jun 2002 12:51:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5RJpdRb007082; Thu, 27 Jun 2002 12:51:39 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RJpZk7007075 for ; Thu, 27 Jun 2002 12:51:35 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA04415 for ; Thu, 27 Jun 2002 12:51:38 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA14830 for ; Thu, 27 Jun 2002 13:51:37 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5RJpZ208852; Thu, 27 Jun 2002 15:51:35 -0400 (EDT) Message-Id: <200206271951.g5RJpZ208852@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Brian Haberman cc: Keith Moore , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-reply-to: (Your message of "Thu, 27 Jun 2002 15:33:26 EDT.") <3D1B6886.14724D73@nc.rr.com> Date: Thu, 27 Jun 2002 15:51:35 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Who delegates the globally-unique site-ids? presumably ICANN or their designees. > If the site-ids are > globally unique, how are they any different from global addresses? they have a different prefix so they can easily be distingiushed from public addreses. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 27 12:54:13 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RJsDk7007112; Thu, 27 Jun 2002 12:54:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5RJsCsS007111; Thu, 27 Jun 2002 12:54:12 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RJs8k7007104 for ; Thu, 27 Jun 2002 12:54:08 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA16334 for ; Thu, 27 Jun 2002 12:54:10 -0700 (PDT) Received: from tndh.net (evrtwa1-ar8-4-65-028-011.evrtwa1.dsl-verizon.net [4.65.28.11]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA16298 for ; Thu, 27 Jun 2002 13:54:09 -0600 (MDT) Received: from eagleswings (127.0.0.1) by localhost (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Thu, 27 Jun 2002 12:55:13 -0700 From: "Tony Hain" To: Cc: "Robert Elz" , "Michel Py" , "Ralph Droms" , Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols Date: Thu, 27 Jun 2002 12:52:25 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <200206271918.g5RJIa208733@astro.cs.utk.edu> Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith Moore wrote: > ... > (in other words, it's not reasonable to assume that a private network > is well-bounded Like it or not, routing protocols actually do require that the boundaries of a network be well defined. > or that it doesn't interconnect with other networks > that do connect to the public network. As I said, all they have to do is coordinate the space. While it might be nice if they didn't have to worry about any possibility of collisions, their private use of space does not justify a public registry. Even if we created a public registry, who would pay for its maintenance, and what would be the rules for acquiring a site-id? We already have public registries struggling with these issues just to keep a relatively small number of SPs happy. How would that scale up to handle every possible side-id request, and garbage collection as the original requestor goes away? > and even if those networks > don't provide transit to the between the public network and private > network there may be apps that have to deal with addresses from both > types of networks) > > if you have enough bits for the site-id you can make the probability > of a conflict approach zero *provided* the site bits are randomly > chosen. but the easiest way to avoid conflicts is to make the > site-id globally unique, and there's no good reason to not do so. Yes there is, and it has everything to do with managing a large global database, and nothing to do with bit patterns as seen by an app. > > now if we really get PI space set up in such a way that any site > can get a unique chunk of PI space whether or not it is connected > to any public network, that would remove the need for unique SL > prefixes, and that would be fine with me. but while I'm glad > people are working on proposals to do that, I'm not holding my > breath waiting for it to happen. if we end up with both unique > SL addresses and PI addresses, that's not a horrible thing. The focus of my PI draft has been on multi-homing, but it could be expanded to cover the case of the globally unique range for a disconnected set of sites. This is not because I prefer it over making SL unique from a bit-pattern perspective, but from the operational perspective a global database for SL can't scale. > > but SL addresses without a site-id just cause more harm than good, > and they really need to be eliminated in favor of unique SL > addresses, unique PI addresses, or both. SL addresses without a globally unique site-id are only a problem if people expect them to work outside the context of a private network. I will agree that there is a need for a private address space that spans multiple sites within a private network, so we do need to remove the 'must be zero' restriction on those bits. Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 27 13:16:51 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RKGok7007314; Thu, 27 Jun 2002 13:16:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5RKGoWF007313; Thu, 27 Jun 2002 13:16:50 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RKGkk7007306 for ; Thu, 27 Jun 2002 13:16:46 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA28491 for ; Thu, 27 Jun 2002 13:16:52 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA27656 for ; Thu, 27 Jun 2002 14:16:52 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5RKBR209072; Thu, 27 Jun 2002 16:11:27 -0400 (EDT) Message-Id: <200206272011.g5RKBR209072@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Tony Hain" cc: moore@cs.utk.edu, "Robert Elz" , "Michel Py" , "Ralph Droms" , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-reply-to: (Your message of "Thu, 27 Jun 2002 12:52:25 PDT.") Date: Thu, 27 Jun 2002 16:11:27 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Keith Moore wrote: > > ... > > (in other words, it's not reasonable to assume that a private network > > is well-bounded > > Like it or not, routing protocols actually do require that the > boundaries of a network be well defined. but not all routers share the same view. and in general applications aren't aware of such views at all. > > or that it doesn't interconnect with other networks > > that do connect to the public network. > > As I said, all they have to do is coordinate the space. this is more difficult than you make it sound. private networks have found it difficult to coordinate IPv4 private address space, or even to coordinate the NAT mappings between their addresses spaces. and there's no good reason to require them to do so. > While it might > be nice if they didn't have to worry about any possibility of > collisions, their private use of space does not justify a public > registry. the fact that the same apps can interact with peers on both private and public IP networks does justify it. (though I'd be happy if we can find a way to prefixes unique without such a registry. the best way I can find to do that is to allow a prefix to be derived from something like a MAC address of a network device - which is fine as long as you always keep that network device... problem is that makes the prefixes something like /64. but unique prefixes are the essential feature, the registry is just an implementaiton mechanism.) > Even if we created a public registry, who would pay for its > maintenance, and what would be the rules for acquiring a site-id? We > already have public registries struggling with these issues just to keep > a relatively small number of SPs happy. How would that scale up to > handle every possible side-id request, and garbage collection as the > original requestor goes away? make sure there are plenty of site-ids available. delegate blocks of site-ids to parties in a good position to make them available to customers - say router vendors. let them ship one attached to each router, with a bar code label. allow people to obtain them from other parties (DNS registrars, RIRs, etc) as a backup mechanism. try not to GC the addresses at all. or if necessary, 'lease' them for long periods of time. > > if you have enough bits for the site-id you can make the probability > > of a conflict approach zero *provided* the site bits are randomly > > chosen. but the easiest way to avoid conflicts is to make the > > site-id globally unique, and there's no good reason to not do so. > > Yes there is, and it has everything to do with managing a large global > database, and nothing to do with bit patterns as seen by an app. where is the large global database of Ethernet MAC addresses? that system of assigning unique IDs seems to have worked reasonably well without an expensive infrastructure. so I think your concerns about management are unfounded. > > now if we really get PI space set up in such a way that any site > > can get a unique chunk of PI space whether or not it is connected > > to any public network, that would remove the need for unique SL > > prefixes, and that would be fine with me. but while I'm glad > > people are working on proposals to do that, I'm not holding my > > breath waiting for it to happen. if we end up with both unique > > SL addresses and PI addresses, that's not a horrible thing. > > The focus of my PI draft has been on multi-homing, but it could be > expanded to cover the case of the globally unique range for a > disconnected set of sites. This is not because I prefer it over making > SL unique from a bit-pattern perspective, but from the operational > perspective a global database for SL can't scale. again I don't have a problem with PI addresses if you can solve the problems associated with them, but it seems premature to exclude globally unique SLs until you'e convinced people you can solve the ambiguous address problem in a better way. and your argument that the global site-id space "can't scale" is so far unconvincing. > > but SL addresses without a site-id just cause more harm than good, > > and they really need to be eliminated in favor of unique SL > > addresses, unique PI addresses, or both. > > SL addresses without a globally unique site-id are only a problem if > people expect them to work outside the context of a private network. private networks aren't always bounded like you seem to think they are, and even when the network is bounded as far as routers are concerned, an app may have to communicate with peers in several networks. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 27 13:20:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RKKOk7007349; Thu, 27 Jun 2002 13:20:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5RKKOxa007348; Thu, 27 Jun 2002 13:20:24 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RKKKk7007341 for ; Thu, 27 Jun 2002 13:20:21 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA19248 for ; Thu, 27 Jun 2002 13:20:26 -0700 (PDT) Received: from mail8.nc.rr.com (fe8.southeast.rr.com [24.93.67.55]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA29681 for ; Thu, 27 Jun 2002 14:20:26 -0600 (MDT) Received: from nc.rr.com ([24.162.252.183]) by mail8.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Thu, 27 Jun 2002 16:20:23 -0400 Message-ID: <3D1B72DC.17B8A451@nc.rr.com> Date: Thu, 27 Jun 2002 16:17:32 -0400 From: Brian Haberman X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Keith Moore CC: ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols References: <200206271951.g5RJpZ208852@astro.cs.utk.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith Moore wrote: > > > Who delegates the globally-unique site-ids? > > presumably ICANN or their designees. This introduces a management headache. The address registries already are struggling with managing the global address space. Adding another registry will not be beneficial. > > > If the site-ids are > > globally unique, how are they any different from global addresses? > > they have a different prefix so they can easily be distingiushed > from public addreses. But with a globally unique site-id, they are globally routable. What's the point? If the site local addresses are used within a private network, there is no need for a global registry since they won't be seen in the global Internet. 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 Jun 27 13:28:01 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RKS1k7007387; Thu, 27 Jun 2002 13:28:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5RKS1JR007386; Thu, 27 Jun 2002 13:28:01 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RKRwk7007379 for ; Thu, 27 Jun 2002 13:27:58 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA02399 for ; Thu, 27 Jun 2002 13:28:04 -0700 (PDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA18457 for ; Thu, 27 Jun 2002 14:28:03 -0600 (MDT) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-253.cisco.com [161.44.149.253]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA12442; Thu, 27 Jun 2002 16:28:00 -0400 (EDT) Message-Id: <4.3.2.7.2.20020627154400.01b16d88@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 27 Jun 2002 16:27:57 -0400 To: Brian Haberman From: Ralph Droms Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols Cc: Keith Moore , ipng@sunroof.eng.sun.com In-Reply-To: <3D1B6886.14724D73@nc.rr.com> References: <200206271918.g5RJIa208733@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 03:33 PM 6/27/2002 -0400, Brian Haberman wrote: >Keith, > >Keith Moore wrote: > > > > if you have enough bits for the site-id you can make the probability > > of a conflict approach zero *provided* the site bits are randomly > > chosen. but the easiest way to avoid conflicts is to make the > > site-id globally unique, and there's no good reason to not do so. > >Who delegates the globally-unique site-ids? If the site-ids are >globally unique, how are they any different from global addresses? Exactly. Perhaps I'm over-abstracting...but it seems to me like a globally-unique site-id is just another form of a global address. I think there are lots of reasons not to make these site-ids globally unique, if we choose to adopt them. For instance, how does an ad hoc, disconnected network get a site-id? Maybe it doesn't need one. What about my home? Do I have to go to my ISP or ICANN to get a site-local ID for my home? - Ralph >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 >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 27 13:43:16 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RKhGk7007433; Thu, 27 Jun 2002 13:43:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5RKhGh5007432; Thu, 27 Jun 2002 13:43:16 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RKhCk7007425 for ; Thu, 27 Jun 2002 13:43:12 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA27160 for ; Thu, 27 Jun 2002 13:43:18 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA11945 for ; Thu, 27 Jun 2002 14:43:17 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5RKhE209193; Thu, 27 Jun 2002 16:43:14 -0400 (EDT) Message-Id: <200206272043.g5RKhE209193@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Brian Haberman cc: Keith Moore , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-reply-to: (Your message of "Thu, 27 Jun 2002 16:17:32 EDT.") <3D1B72DC.17B8A451@nc.rr.com> Date: Thu, 27 Jun 2002 16:43:14 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Keith Moore wrote: > > > > > Who delegates the globally-unique site-ids? > > > > presumably ICANN or their designees. > > This introduces a management headache. The address registries already > are struggling with managing the global address space. Adding another > registry will not be beneficial. okay, give the job to someone else who can do it well then. vendors don't seem to have any trouble assigning a unique serial number to each products. this isn't rocket science. > > > If the site-ids are > > > globally unique, how are they any different from global addresses? > > > > they have a different prefix so they can easily be distingiushed > > from public addreses. > > But with a globally unique site-id, they are globally routable. no, they're *potentially* globally routable, but only if every network agrees to route them. which they won't because there will be too many of them. so no, they won't be globally routable in general. a few may be routable on limited portions of the public network because they've made special arrangements with particular ISPs, but that's between them and their ISPs. > If the site local addresses are used within a private > network, there is no need for a global registry since they won't be > seen in the global Internet. not so, because the private networks and the public internet are not disjoint. they overlap, and apps on hosts that appear in multiple networks have to deal with addresses from each of those networks. it's a bit like the problem of a host with multiple interfaces trying to send traffic to a link-local address. to which interface does it send the traffic (in the absence of explicit information)? can it use a LL address in a referral to peer on a different host? etc. you get the same problem with non-unique SLs that you do with LLs just at a different scale. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 27 13:50:51 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RKopk7007465; Thu, 27 Jun 2002 13:50:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5RKopqc007464; Thu, 27 Jun 2002 13:50:51 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RKolk7007457 for ; Thu, 27 Jun 2002 13:50:47 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA29516 for ; Thu, 27 Jun 2002 13:50:53 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA01083 for ; Thu, 27 Jun 2002 14:50:52 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5RKmb209210; Thu, 27 Jun 2002 16:48:37 -0400 (EDT) Message-Id: <200206272048.g5RKmb209210@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Ralph Droms cc: Brian Haberman , Keith Moore , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-reply-to: (Your message of "Thu, 27 Jun 2002 16:27:57 EDT.") <4.3.2.7.2.20020627154400.01b16d88@funnel.cisco.com> Date: Thu, 27 Jun 2002 16:48:37 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Exactly. Perhaps I'm over-abstracting...but it seems to me > like a globally-unique site-id is just another form of a global > address. of course it's a global address. but that doesn't mean it's globally routable. > I think there are lots of reasons not to make these site-ids globally > unique, if we choose to adopt them. name one. > For instance, how does an > ad hoc, disconnected network get a site-id? that's not a reason, that's a problem to be solved. there is every reason to believe it can be solved as long as we can get enough bits for the site-id. similarly the routing table concern is a valid concern that has to be addressed, but in a way the mechanism is its own solution, since there's no way that ISPs are going to even attempt to route every site-specific prefix in existence. those that try will quickly lose, thus solving the problem. > Maybe it doesn't need one. there's no way to know. most sites currently using v4 private addresses probably didn't realize the mess they were getting themselves into either. > What about my home? Do I have to go to my ISP or ICANN to get a > site-local ID for my home? why not just get it for free with your cable modem/router/whatever? Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 27 14:03:30 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RL3Uk7007505; Thu, 27 Jun 2002 14:03:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5RL3Ur4007504; Thu, 27 Jun 2002 14:03:30 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RL3Rk7007497 for ; Thu, 27 Jun 2002 14:03:27 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA04368 for ; Thu, 27 Jun 2002 14:03:31 -0700 (PDT) Received: from mail5.nc.rr.com (fe5.southeast.rr.com [24.93.67.52]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA27458 for ; Thu, 27 Jun 2002 15:03:30 -0600 (MDT) Received: from nc.rr.com ([24.162.252.183]) by mail5.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Thu, 27 Jun 2002 17:02:35 -0400 Message-ID: <3D1B7CBF.ACC9A7F7@nc.rr.com> Date: Thu, 27 Jun 2002 16:59:43 -0400 From: Brian Haberman X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Keith Moore CC: Ralph Droms , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols References: <200206272048.g5RKmb209210@astro.cs.utk.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith Moore wrote: > > I think there are lots of reasons not to make these site-ids globally > > unique, if we choose to adopt them. > > name one. The cost of administration of the global database. 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 Jun 27 14:04:51 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RL4ok7007537; Thu, 27 Jun 2002 14:04:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5RL4osQ007536; Thu, 27 Jun 2002 14:04:50 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RL4kk7007529 for ; Thu, 27 Jun 2002 14:04:47 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA04960 for ; Thu, 27 Jun 2002 14:04:51 -0700 (PDT) Received: from tndh.net (evrtwa1-ar8-4-65-028-011.evrtwa1.dsl-verizon.net [4.65.28.11]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA23634 for ; Thu, 27 Jun 2002 15:04:50 -0600 (MDT) Received: from eagleswings (127.0.0.1) by localhost (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Thu, 27 Jun 2002 14:05:54 -0700 From: "Tony Hain" To: Cc: "Robert Elz" , "Michel Py" , "Ralph Droms" , Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols Date: Thu, 27 Jun 2002 14:02:59 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <200206272011.g5RKBR209072@astro.cs.utk.edu> Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith Moore wrote: > > ... > > As I said, all they have to do is coordinate the space. > > this is more difficult than you make it sound. private networks > have found it difficult to coordinate IPv4 private address space, > or even to coordinate the NAT mappings between their addresses > spaces. and there's no good reason to require them to do so. That is a poor analogy because they really haven't had enough space to work with. Also, they are the ones motivated to make the interconnect work, so there is in fact every reason to make them responsible for it rather than burdening a public resource for private gain. > > > While it might > > be nice if they didn't have to worry about any possibility of > > collisions, their private use of space does not justify a public > > registry. > > the fact that the same apps can interact with peers on both private > and public IP networks does justify it. > > (though I'd be happy if we can find a way to prefixes unique > without such a registry. the best way I can find to do that is > to allow a prefix to be derived from something like a MAC address > of a network device - which is fine as long as you always keep > that network device... problem is that makes the prefixes > something like /64. > > but unique prefixes are the essential feature, > the registry is just an implementaiton mechanism.) and that implementation mechanism is not free. > > > Even if we created a public registry, who would pay for its > > maintenance, and what would be the rules for acquiring a site-id? We > > already have public registries struggling with these issues > just to keep > > a relatively small number of SPs happy. How would that scale up to > > handle every possible side-id request, and garbage collection as the > > original requestor goes away? > > make sure there are plenty of site-ids available. There are only 37 bits to work with, and what is to keep everyone on the planet from asking for 1000? > > delegate blocks of site-ids to parties in a good position to make > them available to customers - say router vendors. let them > ship one attached to each router, with a bar code label. > allow people to obtain them from other parties (DNS registrars, > RIRs, etc) as a backup mechanism. As soon as you introduce the inefficiency of aggregates, the potential number of sites goes down. > > try not to GC the addresses at all. > or if necessary, 'lease' them for long periods of time. how do you know it is unique if there is no GC, even if it is broken into multiple database segments? > > > > if you have enough bits for the site-id you can make the > probability > > > of a conflict approach zero *provided* the site bits are randomly > > > chosen. but the easiest way to avoid conflicts is to make the > > > site-id globally unique, and there's no good reason to not do so. > > > > Yes there is, and it has everything to do with managing a > large global > > database, and nothing to do with bit patterns as seen by an app. > > where is the large global database of Ethernet MAC addresses? > that system of assigning unique IDs seems to have worked > reasonably well without an expensive infrastructure. You pay for it with every device you purchase. Another poor analogy because if we were running a global ethernet bridged network, there would in fact need to be a very large database of address to contact mapping for any hope of operational debugging support. With IPv4 we reduce that database by aggregating collections of addresses under a single contact, and that system still struggles to maintain accurate data. > > so I think your concerns about management are unfounded. > > > > now if we really get PI space set up in such a way that any site > > > can get a unique chunk of PI space whether or not it is connected > > > to any public network, that would remove the need for unique SL > > > prefixes, and that would be fine with me. but while I'm glad > > > people are working on proposals to do that, I'm not holding my > > > breath waiting for it to happen. if we end up with both unique > > > SL addresses and PI addresses, that's not a horrible thing. > > > > The focus of my PI draft has been on multi-homing, but it could be > > expanded to cover the case of the globally unique range for a > > disconnected set of sites. This is not because I prefer it > over making > > SL unique from a bit-pattern perspective, but from the operational > > perspective a global database for SL can't scale. > > again I don't have a problem with PI addresses if you can solve the > problems associated with them, but it seems premature to exclude > globally unique SLs until you'e convinced people you can solve the > ambiguous address problem in a better way. > > and your argument that the global site-id space "can't scale" is so > far unconvincing. and your argument that a group of sites can't coordinate is unconvincing. If we had set aside 32 /8's and it wasn't working, then I might buy it. > > > > > but SL addresses without a site-id just cause more harm than good, > > > and they really need to be eliminated in favor of unique SL > > > addresses, unique PI addresses, or both. > > > > SL addresses without a globally unique site-id are only a problem if > > people expect them to work outside the context of a private > network. > > private networks aren't always bounded like you seem to think > they are, By definition a private network is bounded, just ask the administrator where the boundaries are. If they don't know where the boundaries of their network are they are open to much bigger problems than a few apps not working. > and even when the network is bounded as far as routers are concerned, > an app may have to communicate with peers in several networks. If an app needs to leave the bounds of a private network, it should be using global addresses. If you are arguing that a multiparty app with multiple participants on both sides of the site boundary should be able to pass around both SL & Global as explicit addresses, explain why. The only reason I see where it might need to is if one of the participants has only a SL prefix. If that is the case, that node has clearly been put in a region where access to, and interactions with, nodes in the global space are administratively intended to not work. Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 27 14:09:23 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RL9Mk7007647; Thu, 27 Jun 2002 14:09:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5RL9M36007646; Thu, 27 Jun 2002 14:09:22 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RL9Gk7007636 for ; Thu, 27 Jun 2002 14:09:16 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA16173 for ; Thu, 27 Jun 2002 14:09:16 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA00073 for ; Thu, 27 Jun 2002 15:09:16 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5RL8o209312; Thu, 27 Jun 2002 17:08:50 -0400 (EDT) Message-Id: <200206272108.g5RL8o209312@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Brian Haberman cc: Keith Moore , Ralph Droms , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-reply-to: (Your message of "Thu, 27 Jun 2002 16:59:43 EDT.") <3D1B7CBF.ACC9A7F7@nc.rr.com> Date: Thu, 27 Jun 2002 17:08:50 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > I think there are lots of reasons not to make these site-ids globally > > > unique, if we choose to adopt them. > > > > name one. > > The cost of administration of the global database. there doesn't need to be a global database. try again. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 27 14:12:06 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RLC6k7007688; Thu, 27 Jun 2002 14:12:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5RLC6bL007687; Thu, 27 Jun 2002 14:12:06 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RLC2k7007680 for ; Thu, 27 Jun 2002 14:12:03 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA17287 for ; Thu, 27 Jun 2002 14:12:07 -0700 (PDT) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA27240 for ; Thu, 27 Jun 2002 15:12:06 -0600 (MDT) Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 27 Jun 2002 14:12:04 -0700 Message-ID: <2B81403386729140A3A899A8B39B046405E161@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Fwd: IPv6 Scoped Addresses and Routing Protocols Thread-Index: AcIeBoeAaeZusGtiS36p4AaKyshfFgABbQGg From: "Michel Py" To: "Tony Hain" , Cc: "Robert Elz" , "Ralph Droms" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5RLC3k7007681 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Tony Hain wrote: > I was not arguing against SLs with site-ids, just that we should > not try in any way to lead people down the path where those > site-ids are perceived to be globally unique. > As long as the site-id is a locally administered value, a network > administrator can use them privately in any way he sees fit, > including private connections to other networks (assuming they can > coordinate amongst themselves to avoid collisions). > My primary concern is that we avoid building what amounts to an > address registry of global scope, which ends up maximizes entropy > in the routing system. I agree, but you would have to restrict to a very few the number of bits that are locally administered. If there are 16 bits to play with, it won't take long to figure out that filling them with the AS number does indeed make a globally unique "local" address without even a need for coordination to avoid collisions. > Yes we need PI public space, see: draft-hain-ipv6-pi-addr-use-02.txt > for some of the reasons why. This text is excellent. Tony and I are following different paths on the resolution, but the reasons remain the same. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 27 14:19:16 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RLJGk7007727; Thu, 27 Jun 2002 14:19:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5RLJFEY007726; Thu, 27 Jun 2002 14:19:15 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RLJCk7007719 for ; Thu, 27 Jun 2002 14:19:12 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA09624 for ; Thu, 27 Jun 2002 14:19:16 -0700 (PDT) Received: from mail5.nc.rr.com (fe5.southeast.rr.com [24.93.67.52]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA21085 for ; Thu, 27 Jun 2002 14:19:16 -0700 (PDT) Received: from nc.rr.com ([24.162.252.183]) by mail5.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Thu, 27 Jun 2002 17:18:33 -0400 Message-ID: <3D1B807E.B87FDBB3@nc.rr.com> Date: Thu, 27 Jun 2002 17:15:42 -0400 From: Brian Haberman X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Keith Moore CC: Ralph Droms , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols References: <200206272108.g5RL8o209312@astro.cs.utk.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith Moore wrote: > > > > > I think there are lots of reasons not to make these site-ids globally > > > > unique, if we choose to adopt them. > > > > > > name one. > > > > The cost of administration of the global database. > > there doesn't need to be a global database. try again. If there isn't a global administration db: 1. How do we know a site-id is unique? 2. How do we know who owns the site-id? And if you want to use AS numbers, just remember that a 64 bit AS number will not fit inside 37 bits. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 27 14:20:43 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RLKhk7007789; Thu, 27 Jun 2002 14:20:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5RLKgMX007788; Thu, 27 Jun 2002 14:20:42 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RLKck7007778 for ; Thu, 27 Jun 2002 14:20:38 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA21382 for ; Thu, 27 Jun 2002 14:20:43 -0700 (PDT) Received: from tndh.net (evrtwa1-ar8-4-65-028-011.evrtwa1.dsl-verizon.net [4.65.28.11]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA01241 for ; Thu, 27 Jun 2002 15:20:42 -0600 (MDT) Received: from eagleswings (127.0.0.1) by localhost (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Thu, 27 Jun 2002 14:21:46 -0700 From: "Tony Hain" To: "Keith Moore" , "Ralph Droms" Cc: "Brian Haberman" , Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols Date: Thu, 27 Jun 2002 14:18:49 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <200206272048.g5RKmb209210@astro.cs.utk.edu> Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith Moore wrote: > ... > of course it's a global address. but that doesn't mean it's globally > routable. You have just argued yourself into a corner. If the address the app chooses is not globally routable, how does it connect? Why would it have chosen SL over the PA prefix to begin with? Wouldn't it make more sense to avoid the possibility of being black-holed? You are looking for addresses that are both locally administered (for the site that is not attached), and globally routable (for the app to actually connect in any arbitrary case with nodes outside the private network), but recognizing those are mutually exclusive. The reason I have gleaned from this thread is that you don't want the app to have to worry about scope. How can it avoid worrying about scope if your preferred address mechanism doesn't go everywhere? Functionally the scope mechanism provides a much cleaner decision point for an app than a nebulous expansion of SL to include globally unique site-ids. Again I have no problem with locally administered site-ids, because those are routed within the context of the private network so an app can rely on them. If the app wants to connect outside the scope of the private network, it really needs to be using a global address, or have lots more knowledge about current routing policy than anyone will ever share with an app. Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 27 14:24:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RLOXk7007846; Thu, 27 Jun 2002 14:24:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5RLOWJs007845; Thu, 27 Jun 2002 14:24:32 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RLOTk7007838 for ; Thu, 27 Jun 2002 14:24:30 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA22958 for ; Thu, 27 Jun 2002 14:24:34 -0700 (PDT) Received: from mail5.nc.rr.com (fe5.southeast.rr.com [24.93.67.52]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA12630 for ; Thu, 27 Jun 2002 14:24:34 -0700 (PDT) Received: from nc.rr.com ([24.162.252.183]) by mail5.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Thu, 27 Jun 2002 17:22:50 -0400 Message-ID: <3D1B817F.ED37B945@nc.rr.com> Date: Thu, 27 Jun 2002 17:19:59 -0400 From: Brian Haberman X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Tony Hain CC: Keith Moore , Ralph Droms , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tony, Tony Hain wrote: > > Keith Moore wrote: > > ... > > of course it's a global address. but that doesn't mean it's globally > > routable. > > You have just argued yourself into a corner. If the address the app > chooses is not globally routable, how does it connect? Why would it have > chosen SL over the PA prefix to begin with? Wouldn't it make more sense > to avoid the possibility of being black-holed? You are looking for > addresses that are both locally administered (for the site that is not > attached), and globally routable (for the app to actually connect in any > arbitrary case with nodes outside the private network), but recognizing > those are mutually exclusive. The reason I have gleaned from this thread > is that you don't want the app to have to worry about scope. How can it > avoid worrying about scope if your preferred address mechanism doesn't > go everywhere? > > Functionally the scope mechanism provides a much cleaner decision point > for an app than a nebulous expansion of SL to include globally unique > site-ids. Again I have no problem with locally administered site-ids, > because those are routed within the context of the private network so an > app can rely on them. If the app wants to connect outside the scope of > the private network, it really needs to be using a global address, or > have lots more knowledge about current routing policy than anyone will > ever share with an app. Thank you. I completely agree. 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 Jun 27 14:26:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RLQlk7007869; Thu, 27 Jun 2002 14:26:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5RLQlRX007868; Thu, 27 Jun 2002 14:26:47 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RLQik7007861 for ; Thu, 27 Jun 2002 14:26:44 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA22840 for ; Thu, 27 Jun 2002 14:26:48 -0700 (PDT) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA08715 for ; Thu, 27 Jun 2002 15:26:47 -0600 (MDT) Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 27 Jun 2002 14:26:45 -0700 Message-ID: <2B81403386729140A3A899A8B39B046406C8A9@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Fwd: IPv6 Scoped Addresses and Routing Protocols Thread-Index: AcIeINDP7kSZKP0hRnKE8Bef+gsmJgAABa4A From: "Michel Py" To: "Brian Haberman" , "Keith Moore" Cc: "Ralph Droms" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5RLQik7007862 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, > And if you want to use AS numbers, just remember that a 64 bit > AS number will not fit inside 37 bits. I don't think this is a good argument. Today, the AS number is 16 bits. Tomorrow, it will be 32, which is 4 Billion AS numbers. 37 bits would be 128 Billion AS numbers, probably more than we need. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 27 14:30:15 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RLUFk7007887; Thu, 27 Jun 2002 14:30:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5RLUFUh007886; Thu, 27 Jun 2002 14:30:15 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RLUCk7007879 for ; Thu, 27 Jun 2002 14:30:12 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA24974 for ; Thu, 27 Jun 2002 14:30:17 -0700 (PDT) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA15346 for ; Thu, 27 Jun 2002 14:30:16 -0700 (PDT) Subject: RE: Site Locals and the DFZ MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C21E21.D3C3BEE0" Date: Thu, 27 Jun 2002 14:30:15 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message Message-ID: <2B81403386729140A3A899A8B39B046405E162@server2000.arneill-py.sacramento.ca.us> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Site Locals and the DFZ Thread-Index: AcIeDyFGj3ifdpKrSKKv/l+IzjiFlgAEX6EA From: "Michel Py" To: "Glenn Morrow" , Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C21E21.D3C3BEE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > Glenn Morrow wrote: > Another question would be is the DFZ a site? =20 No, it is not; and I don't think it will ever be. If there is a place where you would find disparate routing policies, that is the DFZ. =20 Michel. =20 ------_=_NextPart_001_01C21E21.D3C3BEE0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Site Locals and the DFZ

> Glenn Morrow = wrote:

> Another question would be is = the DFZ a site?

 

No, it is not; and I don’t = think it will ever be. If there is a place where you would find disparate routing = policies, that is the DFZ.

 

Michel.

 

=00 ------_=_NextPart_001_01C21E21.D3C3BEE0-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 27 14:31:06 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RLV6k7007913; Thu, 27 Jun 2002 14:31:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5RLV5x7007912; Thu, 27 Jun 2002 14:31:05 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RLV0k7007905 for ; Thu, 27 Jun 2002 14:31:00 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA13634 for ; Thu, 27 Jun 2002 14:31:04 -0700 (PDT) Received: from mail7.nc.rr.com (fe7.southeast.rr.com [24.93.67.54]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA08327 for ; Thu, 27 Jun 2002 15:31:04 -0600 (MDT) Received: from nc.rr.com ([24.162.252.183]) by mail7.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Thu, 27 Jun 2002 17:30:55 -0400 Message-ID: <3D1B8365.C75F70D2@nc.rr.com> Date: Thu, 27 Jun 2002 17:28:05 -0400 From: Brian Haberman X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Michel Py CC: ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols References: <2B81403386729140A3A899A8B39B046406C8A9@server2000.arneill-py.sacramento.ca.us> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Oops. My mistake. Brian Michel Py wrote: > > Brian, > > > And if you want to use AS numbers, just remember that a 64 bit > > AS number will not fit inside 37 bits. > > I don't think this is a good argument. Today, the AS number is 16 bits. > Tomorrow, it will be 32, which is 4 Billion AS numbers. 37 bits would be > 128 Billion AS numbers, probably more than we need. > > Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 27 14:40:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RLeek7008048; Thu, 27 Jun 2002 14:40:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5RLee1f008047; Thu, 27 Jun 2002 14:40:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RLeZk7008040 for ; Thu, 27 Jun 2002 14:40:35 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA27976 for ; Thu, 27 Jun 2002 14:40:39 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA13211 for ; Thu, 27 Jun 2002 15:40:39 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5RLZL209530; Thu, 27 Jun 2002 17:35:23 -0400 (EDT) Message-Id: <200206272135.g5RLZL209530@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Tony Hain" cc: moore@cs.utk.edu, "Robert Elz" , "Michel Py" , "Ralph Droms" , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-reply-to: (Your message of "Thu, 27 Jun 2002 14:02:59 PDT.") Date: Thu, 27 Jun 2002 17:35:21 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > ... > > > As I said, all they have to do is coordinate the space. > > > > this is more difficult than you make it sound. private networks > > have found it difficult to coordinate IPv4 private address space, > > or even to coordinate the NAT mappings between their addresses > > spaces. and there's no good reason to require them to do so. > > That is a poor analogy because they really haven't had enough space to > work with. I agree the analogy is imperfect for coordination of address spaces. however they have plenty of latitude regarding the nat mapping tables, and it's still a major pain to coordinate more than a small number of sites. > Also, they are the ones motivated to make the interconnect > work, so there is in fact every reason to make them responsible for it > rather than burdening a public resource for private gain. strongly disagree. even though the use of NATs only directly affects those who use NATs, their effect is actually much broader - effectively preventing widespread deployment of any app that cannot deal with NATs. we have evidence that coordination of site-ids doesn't scale well, and at present the only alternative to having global addresses for private sites is v6 NAT. > > the fact that the same apps can interact with peers on both private > > and public IP networks does justify it. > > > > (though I'd be happy if we can find a way to prefixes unique > > without such a registry. the best way I can find to do that is > > to allow a prefix to be derived from something like a MAC address > > of a network device - which is fine as long as you always keep > > that network device... problem is that makes the prefixes > > something like /64. > > > > but unique prefixes are the essential feature, > > the registry is just an implementaiton mechanism.) > > and that implementation mechanism is not free. nothing is free, strictly speaking. if you print a site-id on a label then the label costs a few cents. > > > Even if we created a public registry, who would pay for its > > > maintenance, and what would be the rules for acquiring a site-id? We > > > already have public registries struggling with these issues > > just to keep > > > a relatively small number of SPs happy. How would that scale up to > > > handle every possible side-id request, and garbage collection as the > > > original requestor goes away? > > > > make sure there are plenty of site-ids available. > > There are only 37 bits to work with, and what is to keep everyone on the > planet from asking for 1000? 37 bits might not be enough in which case we'd need a separate allocation for globally unique site locals. but if the normal way you get a site local is to buy a router, why would anybody need more site local prefixes than routers? > > delegate blocks of site-ids to parties in a good position to make > > them available to customers - say router vendors. let them > > ship one attached to each router, with a bar code label. > > allow people to obtain them from other parties (DNS registrars, > > RIRs, etc) as a backup mechanism. > > As soon as you introduce the inefficiency of aggregates, the potential > number of sites goes down. agreed, which is part of why 37 bits might not be quite enough. still, allocating 11 bits for vendors would give each vendor 67 million numbers to assign, and that's assuming that every vendor got the same size allocation. or you could have more vendor IDs and give each one fewer addresses per allocation chunk, which would use the space more efficiently. I see no reason why we shouldn't be able to get at least 2**32 distinct site IDs from 37 bits of address space. > > try not to GC the addresses at all. > > or if necessary, 'lease' them for long periods of time. > > how do you know it is unique if there is no GC, even if it is broken > into multiple database segments? the same way you know that an ethernet address is unique. > > where is the large global database of Ethernet MAC addresses? > > that system of assigning unique IDs seems to have worked > > reasonably well without an expensive infrastructure. > > You pay for it with every device you purchase. yep, and it's both cheap and transparent. works beautifully. > Another poor analogy > because if we were running a global ethernet bridged network, who said anything about running a global ethernet bridged network, or anything on that scale? surely you don't expect every private network in the world to establish a bilateral interconnection with every other one? that's what the public network is for. > > again I don't have a problem with PI addresses if you can solve the > > problems associated with them, but it seems premature to exclude > > globally unique SLs until you'e convinced people you can solve the > > ambiguous address problem in a better way. > > > > and your argument that the global site-id space "can't scale" is so > > far unconvincing. > > and your argument that a group of sites can't coordinate is > unconvincing. If we had set aside 32 /8's and it wasn't working, then I > might buy it. as I understand it, sheer lack of address space isn't usually the problem because they're typically not using one-to-one mapping anyway. > > private networks aren't always bounded like you seem to think > > they are, > > By definition a private network is bounded, just ask the administrator > where the boundaries are. tell that to the apps that have to live in multiple networks at once. > > and even when the network is bounded as far as routers are concerned, > > an app may have to communicate with peers in several networks. > > If an app needs to leave the bounds of a private network, it should be > using global addresses. then figure out how to give every network in the world a global address. which it seems is what we're both trying to do, though we have different ideas of how to go about it. I don't have any fundamental objection to PI addresses, but I acknowledge there are problems to be solved, and I wish you the best in your efforts to solve them. OTOH you seem to have fundamental objections to globally unique site prefixes even though you reject the proffered solutions out of hand without really considering them. Frankly I think that's counterproductive. > If you are arguing that a multiparty app with > multiple participants on both sides of the site boundary should be able > to pass around both SL & Global as explicit addresses, explain why. no I'm arguing that every network, private or public, should have globally unique addresses available to it, and every host on such a network should be capable of using those addresses, so that apps don't have to deal with limited-scope or ambiguous addresses at all. > The > only reason I see where it might need to is if one of the participants > has only a SL prefix. If that is the case, that node has clearly been > put in a region where access to, and interactions with, nodes in the > global space are administratively intended to not work. not true, at least not so long as addresses have to be obtained from an ISP. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 27 14:40:51 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RLeok7008058; Thu, 27 Jun 2002 14:40:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5RLeotR008057; Thu, 27 Jun 2002 14:40:50 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RLejk7008050 for ; Thu, 27 Jun 2002 14:40:46 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA28051 for ; Thu, 27 Jun 2002 14:40:50 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA20471 for ; Thu, 27 Jun 2002 14:40:50 -0700 (PDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5RLdT209575; Thu, 27 Jun 2002 17:39:29 -0400 (EDT) Message-Id: <200206272139.g5RLdT209575@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Tony Hain" cc: "Keith Moore" , "Ralph Droms" , "Brian Haberman" , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-reply-to: (Your message of "Thu, 27 Jun 2002 14:18:49 PDT.") Date: Thu, 27 Jun 2002 17:39:29 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > ... > > of course it's a global address. but that doesn't mean it's globally > > routable. > > You have just argued yourself into a corner. no I haven't. the addresses are for private interconnection agreements, not for global routing. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 27 15:14:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RMEOk7008453; Thu, 27 Jun 2002 15:14:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5RMENus008452; Thu, 27 Jun 2002 15:14:23 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RMEKk7008445 for ; Thu, 27 Jun 2002 15:14:20 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA26428 for ; Thu, 27 Jun 2002 15:14:25 -0700 (PDT) Received: from tndh.net (evrtwa1-ar8-4-65-028-011.evrtwa1.dsl-verizon.net [4.65.28.11]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA26203 for ; Thu, 27 Jun 2002 16:14:24 -0600 (MDT) Received: from eagleswings (127.0.0.1) by localhost (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Thu, 27 Jun 2002 15:15:23 -0700 From: "Tony Hain" To: Cc: "Robert Elz" , "Michel Py" , "Ralph Droms" , Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols Date: Thu, 27 Jun 2002 15:12:21 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <200206272135.g5RLZL209530@astro.cs.utk.edu> Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith Moore wrote: > ... > but if the normal way > you get a site local is to buy a router, why would anybody need > more site local prefixes than routers? Because routers have interfaces in multiple sites. > ... > > If you are arguing that a multiparty app with > > multiple participants on both sides of the site boundary > should be able > > to pass around both SL & Global as explicit addresses, explain why. > > no I'm arguing that every network, private or public, should have > globally unique addresses available to it, and every host on such > a network should be capable of using those addresses, so that apps > don't have to deal with limited-scope or ambiguous addresses at all. > ... > > > ... > > > of course it's a global address. but that doesn't mean > it's globally > > > routable. > > > > You have just argued yourself into a corner. > > no I haven't. the addresses are for private interconnection > agreements, > not for global routing. These arguments are contradictory. If an address isn't globally routed, the app needs to deal with some addresses having a limited scope. Right now we have told the app unambiguously that a specific set of addresses has a limited scope. What you are asking for is that we remove the explicit scope, and leave it up to dynamic routing policy as to where the scope boundary is. How does the app learn where the scope boundary is? At least with the concept of a two-faced DNS, the app has a chance of knowing that if a SL comes back in the query that the node is somewhere in the same private net. I agree no address should ever be ambiguous, but that doesn't require global uniqueness. The thing that is required is that the address be unique within the scope of routability. If you expect an app to figure out that scope, it needs to be through the one piece of information that the app has about topology, and that is the name-to-address-mapping process. The resolution of a restricted-scope address requires an exact match between the administrative boundary of the resolution tool and the routing boundary. If those don't match there is no hope the app will work reliably. Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 27 15:35:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RMZ7k7008716; Thu, 27 Jun 2002 15:35:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5RMZ7cr008715; Thu, 27 Jun 2002 15:35:07 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RMZ4k7008708 for ; Thu, 27 Jun 2002 15:35:04 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA16655 for ; Thu, 27 Jun 2002 15:35:09 -0700 (PDT) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA09678 for ; Thu, 27 Jun 2002 16:35:08 -0600 (MDT) Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 27 Jun 2002 15:35:07 -0700 Message-ID: <2B81403386729140A3A899A8B39B046405E163@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Fwd: IPv6 Scoped Addresses and Routing Protocols Thread-Index: AcIdoKS8lz0iiBgpRAKs02qKKRS6oQAgw+BA From: "Michel Py" To: "Robert Elz" Cc: "Keith Moore" , "Tony Hain" , "Ralph Droms" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5RMZ4k7008709 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk kre, >> Tony and I are proposing schemes that are aggregatable and >> that are not tied to a provider. > kre wrote: > Both those schemes are geographic based addresses - these aggregate > if and only if one assumes that areas that are geographically close > are also topologically close. This is absolutely untrue. I will let Tony defend his own, but for the two different methods that ipv6mh is working on, there is no relation whatsoever between the network/fiber plant topology and the geographical aggregation. > They're provider independent only of there are multiple providers > that have agreed to cooperate with each other and share the > prefix (essentially routing packets to each other when they arrive > at the "wrong" place). This is another wrong assumption. We know that asking ISPs to advertise a geographical aggregate that contains competitor's addresses is not going to fly. I would not do it myself. The solutions that we are developing do _not_ require transporting competitor's traffic. > While that is entirely possible to assume might happen in some > high density usage parts of the world, where multiple providers > can all exist and make a profit, in much of the world, the simply > aren't enough active users to support the infrastructure for > multiple providers. We do not require any local infrastructure. > Anyone would always be free to connect to a different provider, > by simply connecting to a more distant location of course - but > then their address would not (could not if any aggregation at all > is to be achieved) be based upon their geography, but the > provider's instead. That is, to change providers an address > change is likely to be required for many (perhaps most) and for > those it isn't, the provider choice will be limited to those who > have managed to join the local provider club. True, but what if joining the local provider club is free? You would have a point if being present at some kind of IX was required, but it's not. > On the other issue ... anyone can (attempt to) pay any ISP, or set > of ISPs to carry any address. The rish is certainly no greater of > that happening with a SL address with a site-id embedded, than it is > for a global address allocated by a different provider, or a > geographic address from some other region. A valid point. Please note that we are not claiming that geographical addresses alone will solve all of the problems at once. > If anything, the risk is less with SL addresses, as they can be > clearly labelled "for local use only", lowering the chances that > people will ever decide they would like to interpret them as global > addresses (all of these things are just numbers, so perceptions, > and what the ISPs will agree to do are all that matters anyway). > Global addresses are expected to be globally visible, and there's > no reason at all to assume that people won't go to a competitor > ISP and say "I will connect to you, and pay you all these $'s if > you will agree to advertise the prefix I have already been > allocated this other way" True enough. However, you forgot two important things: 1. If we make SLs with site IDs globally unique, there might be no assignement (or the assignement might be automatically granted by the addressing architecture, say a 37-bot hash of the MAC address, or whatever). With the geographic scheme we are designing, there would still be the need to go to a RIR and register a block, so we might still decide that someone with a dial-up 28.8k modem does not qualify for a portable, globally unique /48 block. 2. SLs do would not have a supporting protocol if used globally (how could there be one, if they are not supposed to be used that way). The way I see the geographical addresses is a support of the multihoming protocol. And if there is a protocol, there can be safeties and policy enforcement features built in. > (and even say to ISPs, "I will connect > to you, and you allocate me > an address, but you agree that once allocated you can never reclaim > the address, no matter whether I stop paying you or not"). Not very realistic, IMHO. First, no ISP would put that in writing. The, what happens if the ISP bellies up? Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 27 15:47:22 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RMlMk7008785; Thu, 27 Jun 2002 15:47:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5RMlMpA008784; Thu, 27 Jun 2002 15:47:22 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RMlIk7008777 for ; Thu, 27 Jun 2002 15:47:18 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA06429 for ; Thu, 27 Jun 2002 15:47:24 -0700 (PDT) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA20894 for ; Thu, 27 Jun 2002 15:47:23 -0700 (PDT) Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 27 Jun 2002 15:47:22 -0700 Message-ID: <2B81403386729140A3A899A8B39B046405E165@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Fwd: IPv6 Scoped Addresses and Routing Protocols Thread-Index: AcId7FI3x/z7aSYvRWq/efb7TuK1tgAPrdQw From: "Michel Py" To: "Tony Hain" , "Brian E Carpenter" , "Michael Thomas" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5RMlJk7008778 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> Brian E Carpenter wrote: >> For the record, you've yet to persuade me that these schemes are >> aggregatable in the real world of competitive ISPs. > Tony Hain wrote: > I understand the concern, but it comes down to a matter of > cost/benefit tradeoff. If a geo scheme turns out to be cheaper to > maintain than an ever expanding table full of holes, it will be > deployed. The task at hand is finding *any* scheme that will > create provider independent addresses in an operationally sound > way. Agree with Tony. Brian, I don't expect a miracle in terms of aggregation initially. ISPs will aggregate only if they find a gain in it. But if there is a gain, they will. If your concern is that they will not cooperate because they would not want to announce a prefix that contains addresses that belong to their competitors, I have addressed it in a reply to kre a few minutes ago. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 27 15:49:58 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RMnvk7008825; Thu, 27 Jun 2002 15:49:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5RMnvqV008824; Thu, 27 Jun 2002 15:49:57 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RMnrk7008817 for ; Thu, 27 Jun 2002 15:49:53 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA21200 for ; Thu, 27 Jun 2002 15:49:59 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA16610 for ; Thu, 27 Jun 2002 16:49:58 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5RMim210059; Thu, 27 Jun 2002 18:44:48 -0400 (EDT) Message-Id: <200206272244.g5RMim210059@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Tony Hain" cc: moore@cs.utk.edu, "Robert Elz" , "Michel Py" , "Ralph Droms" , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-reply-to: (Your message of "Thu, 27 Jun 2002 15:12:21 PDT.") Date: Thu, 27 Jun 2002 18:44:48 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Keith Moore wrote: > > ... > > but if the normal way > > you get a site local is to buy a router, why would anybody need > > more site local prefixes than routers? > > Because routers have interfaces in multiple sites. seems like a stretch for those 'sites' to not have routers themselves and thus, their own site prefixes. sure you can make each site a bridged ethernet, but then you are unlikely to have so many hosts on any of those ethernets that you can't subnet a single SL prefix for the whole thing. still, the idea isn't to force people to get prefixes or site-ids from a router vendor, it's to set up some cheap ways of distributing prefixes so that everyone who needs one probably gets one automatically. there can be other mechanisms for the few that don't get enough via this mechanism. > These arguments are contradictory. If an address isn't globally routed, > the app needs to deal with some addresses having a limited scope. true enough, but there's still a useful difference between a globally unique address with a limited scope, and an ambiguous address. if the app tries to send to a globally unique SL address with a limited scope, the message will either get there or it will fail. if the message fails it's almost certainly because there is no route to the destination - in other words, it's completely beyond the ability of either the app or the network to fix, everything has fulfilled its function as well as possible. also it's likely that the network can issue a network unreachable ICMP giving quick feedback to the app. if the app tries to send to an ambiguous address, like a LL or a SL without a site-id, and the transmission fails, it could be for any reason - the host is on the local net/site but is down, the host is on another network/site but there's no way to tell, the app didn't send the message through the right interface, etc. part of what I'm discovering is that if you want to make any kind of address selection algorithm work well, you need to ensure that IF there is an allowed signal path from source to destination, the hosts will (or are very likely to) (a) have addresses assigned to them that allow that signal path to be used, and (b) the address selection algorithm will choose a addresses that meet those criteria over those that do not. in order to meet condition (a) then we need to make sure that every site has a globally-unique prefix. in order to meet condition (b) then we need to make sure that globally routable prefixes are chosen in preference to site-specific prefixes. > I agree no address should ever be ambiguous, but that doesn't require > global uniqueness. The thing that is required is that the address be > unique within the scope of routability. the app has no good way of knowing about scope - and multi-faced DNS just doesn't cut it - DNS really doesn't know more about topology than any other app, and the DNS server has no control over who caches its messages. but it's not necessary that the app know about scope. it's only necessary that a) if the app can send a message to a destination, it can easily find out which address will work b) if the app can't send a message to that destination, it can find out quickly at least, I think this is the optimal result given the assumption that we don't have a completely connected network - i.e. that there will be some host pairs (A,B) for which A cannot reach B due to either the lack of a signal path or an administrative prohibition. none of this really requires that we get rid of limited scope addresses, just that we always use global address in preference to LS addresses. though if we can provide privately-routable provider- independent addresses then it's hard to see how to justify keeping ambiguous SL addresses in the architecture. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 27 18:02:40 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5S12ek7009068; Thu, 27 Jun 2002 18:02:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5S12e0A009067; Thu, 27 Jun 2002 18:02:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5S12bk7009060 for ; Thu, 27 Jun 2002 18:02:37 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA29206 for ; Thu, 27 Jun 2002 18:02:41 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA27115 for ; Thu, 27 Jun 2002 19:02:41 -0600 (MDT) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g5S12fLH002427 for ; Thu, 27 Jun 2002 18:02:41 -0700 (PDT) Received: from CHMETZ-W2K2.cisco.com (dhcp-171-71-62-50.cisco.com [171.71.62.50]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id SAA29701 for ; Thu, 27 Jun 2002 18:02:39 -0700 (PDT) Message-Id: <4.3.2.7.2.20020627205814.02757698@mail1.cisco.com> X-Sender: chmetz@mail1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 27 Jun 2002 21:02:38 -0400 To: ipng@sunroof.eng.sun.com From: Chris Metz Subject: CFP on IPv6 for IEEE Internet Computing Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Folks- My apologies for any duplicates, thanks ... http://computer.org/internet/call4ppr.htm#v7n3 Call for Papers on Special Issue on IPv6 Protocols and Applications (May/June 2003) Issue Guest Editor: Chris Metz, Cisco Systems, chmetz@cisco.com Submission Deadline: 1 October 2002 The effort to develop a successor to the current IPv4 protocol suite has been underway for the past ten years. IP version 6 (IPv6) provides several enhancements over its predecessor, including a larger address space, plug-and-play autoconfiguration, and a simplified header format. IPv6 has largely remained on the sidelines, however, due to aggressive IPv4 address conservation efforts (through network address configuration, CIDR, dynamic host configuration protocol, and other techniques), which have successfully extended the limited IPv4 address space. This has served to obviate the only compelling reason to migrate to a new version of IP on the Internet. Looking ahead, however, several market and technology developments could drive the need to introduce IPv6 sooner rather than later. Mobile wireless networks supporting large numbers of IP-addressable handsets mandate the use of IPv6. Vendors are now shipping products with robust IPv6 features and capabilities. Experimental IPv6 networks have grown in size and participation thus providing practical operational experience on a large scale. The IPv6 support in just about every popular operating system including Windows and Linux augurs well for application development. And finally there is a plethora of possible IPv4-to-IPv6 transition mechanisms that will enable co-existence and interoperability with IPv4 for many years to come. This special issue covers developments in IPv6 protocols and applications. Topics of interest for technical articles include: Operating system support for IPv6 Comparing IPv4-to-IPv6 transition mechanisms (tunneling, 6to4, DSTM, and so on) Routing protocol implementations (such as OSPFv3, Integrated IS-IS, MP-BGP) Mobile IPv6 protocols and services Service provider, enterprise, and home networking environments and applications Migrating IPv4 applications to IPv6 Implementing IPv6 in emerging 3G wireless networks IPv6 anycast addressing for autoprovisioning and discovery Operational experiences on IPv6 networks (such as 6Bone) QoS and flow-label semantics IPv6 packet header processing (classification, table lookup, and so on) in routers IPv6 and MPLS All papers should explicate the technical issues related to the Internet. Research papers should demonstrate the feasibility of the approach and describe the state of realization. Case studies and applied papers should discuss the key factors that allowed for a successful implementation and any pitfalls and problems encountered. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 27 21:36:44 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5S4aik7009336; Thu, 27 Jun 2002 21:36:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5S4aiI7009335; Thu, 27 Jun 2002 21:36:44 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5S4afk7009328 for ; Thu, 27 Jun 2002 21:36:41 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA04801 for ; Thu, 27 Jun 2002 21:36:46 -0700 (PDT) Received: from smtp.huawei.com ([61.144.161.21]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA07631 for ; Thu, 27 Jun 2002 21:36:44 -0700 (PDT) Received: from mailin.huawei.com ([172.17.1.113]) by smtp.huawei.com (Netscape Messaging Server 4.15) with ESMTP id GYEFE500.28M for ; Fri, 28 Jun 2002 12:34:53 +0800 Received: from CL5002VJAMRIT ([10.18.4.151]) by mailin.huawei.com (Netscape Messaging Server 4.15) with ESMTP id GYEFJ100.A0F for ; Fri, 28 Jun 2002 12:37:49 +0800 Message-ID: <006601c21e5e$e2383a10$9704120a@in.huawei.com> From: "Vijay Amrit Agrawal" To: References: Subject: Maybe: IPv6 Scoped Addresses and Routing Protocols Date: Fri, 28 Jun 2002 10:17:18 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, . Aren't we suppose to have sufficient IP address so that each can have globally unique address? If that is the case, can't each user get his/her own IP address without bothering about renumbering in the service provider? Why are we trying to constrain the end user, to solve the routing problem? IPV4 doesn't work well with NAT. We are trying to address many limitation of IPV4 in IPv6. Why not try to make IPv6 such that, it can work well even when technology like NAT is deployed i.e. the end address is different from the transport address. Any way we are modifying application, won't it be better if they are modified in more flexible way.For example: We use one address to address the end systems, this address has certain bits that are unique globally, but certain bits that are used only for routing and can take any value depending on the routing path that exist at that moment? When somebody uses a new service provider, the upper bits are changed by the gateway routers (or by the routing component in the host itself by doing a dns queery), and since the end systems don't use those upper bits at all, they could care less who is the service provider? In telephone system we have the countrycode-areaCode-number, may be for Ip we need serviceProviderCode-countryCode-areaCode-number. When we want to ping or do any such thing, we keep the service provider code as zero or something else. Address aggregation can be done at service provider code or using country code or any other combination.(May be in IP world we would use domaincode like.com, .edu instead of country code so the address also reflect the DNS hierarchy). There can be many other use of separating the transport address from the end address as there are advantages of decoupling them (one can argue that the dns name are the end address but a string doesn't usually form a good thing for end address). One can also have certain bit in the transport address (or can be in ipHeader) to indicate that this packet is from a customer and service provider may treat this packet differently. Regards, Vijay -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 27 21:41:13 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5S4fDk7009380; Thu, 27 Jun 2002 21:41:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5S4fDRA009379; Thu, 27 Jun 2002 21:41:13 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5S4f9k7009372 for ; Thu, 27 Jun 2002 21:41:09 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA29562 for ; Thu, 27 Jun 2002 21:41:13 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA19684 for ; Thu, 27 Jun 2002 22:41:13 -0600 (MDT) Received: from kenawang ([147.11.233.18]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id VAA17801; Thu, 27 Jun 2002 21:39:29 -0700 (PDT) Message-Id: <4.2.2.20020628002926.02399570@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 28 Jun 2002 00:41:10 -0400 To: Alain Durand From: Margaret Wasserman Subject: Re: I-D ACTION:draft-ietf-ipv6-default-addr-select-08.txt Cc: Bob Hinden , Keith Moore , ipng@sunroof.eng.sun.com In-Reply-To: References: <4.3.2.7.2.20020625142522.0268e188@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Alain, >There has been a very long discussion on the fate of Site Local addresses >in the wg. There are still two opposite views of what to do about them: Most of that discussion focused on whether or not to remove site-local addresses from the architecture, not on this draft. And, we have already determined that there was no consensus to remove them from the architecture. So, I don't know why it would make sense to remove them from this draft. >a) Do not require apps to support multi-sited nodes now, but > keep the address selection rules in place. > This means that in the future, if SL are available, > they will be used by ALL applications by default. An application will only use a site-local destination addresses if it is returned in the DNS and/or typed locally. So, it can't happen without the administrator or user doing something to make it happen. >b) Do not require apps to support multi-sited nodes now, and > remove the address selection rule that deal with scoped addresses. > This means that in the future, if SL are available, > they will not be used by default, but only by applications that request them. I don't understand how this is achieved by removing the default selection rules. If an application receives a site-local address from the DNS, how will removing scoped addressing rules from the default address selection draft prevent the app from using the site-local address? The assumption is that we are dealing with old apps that don't know anything about IPv6 scoped addressing, so we can't expect the app to recognize a site-local address and refuse to use it... > Keith has promised a draft to explain the trade-off between those two approaches, >I think we should not advance draft-ietf-ipv6-default-addr-select-08.txt >until there is a clear resolution on this question. Unfortunately, Keith did not submit a draft by the deadline, so there will not be a draft before Yokohama. The Default Address Selection document has been out for months, has been reviewed several times by the WG, has undergone a WG last call and has been reviewed by the IESG. It doesn't seem right to delay this draft indefinitely waiting for another draft, especially when we haven't been told about any specific problems that this draft will cause. If there are specific, technical objections to this draft, please state them clearly on the mailing list. It would also be helpful to suggest specific text changes to the draft. This will give others and opportunity to agree or disagree about whether the issues should block the publication of this draft. Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 28 00:19:20 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5S7JJk7009595; Fri, 28 Jun 2002 00:19:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5S7JJ0g009594; Fri, 28 Jun 2002 00:19:19 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5S7JEk7009587 for ; Fri, 28 Jun 2002 00:19:14 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA01877 for ; Fri, 28 Jun 2002 00:19:18 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA25071 for ; Fri, 28 Jun 2002 01:19:17 -0600 (MDT) Received: from localhost ([3ffe:501:4819:2000:200:39ff:fe10:85d7]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g5S7IxA01323; Fri, 28 Jun 2002 16:19:00 +0900 (JST) Date: Fri, 28 Jun 2002 16:18:57 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Pekka Savola Cc: itojun@iijlab.net, Thomas Narten , Subject: Re: IESG comments on draft-ietf-ipngwg-icmp-name-lookups-09.txt In-Reply-To: References: <20020626185938.C85E34B29@coconut.itojun.org> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 33 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Wed, 26 Jun 2002 22:11:11 +0300 (EEST), >>>>> Pekka Savola said: >> In my understanding, the threat imposed by malicious responses to >> ICMPv6 node information query (Qtype = node name) is equal to >> setting up DNS PTR records without forward zone administrators' >> knowing. For instance, anyone can set up DNS PTR records that returns >> "www.ietf.org". Similarly, anyone can respond with ICMPv6 node >> information reply with "www.ietf.org". > That anyone setting DNS PTR records must be the administrator of an IP > address block, and that IP address block must have been assigned to him. > Seems like a big difference IMO. It's true, but please concentrate on the main point of this discussion. The point, IMO, is that even DNS PTR responses are not reliable enough for access control purposes, as described in draft-ietf-dnsop-inaddr-required-03.txt. With this fact it does not matter that DNS PTRs are much more reliable than node information replies. We can only use the responses/replies just as a hint anyway. (DNSSEC may change the difference significantly, but it is not widely deployed at least for now.) In my understanding, the IESG comments do not oppose to using node information replies as a replacement/alternative of (insecure) DNS PTRs. They just suggest better wording about the applicability and implication. I think the comment is reasonable. 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 Fri Jun 28 00:31:55 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5S7Vsk7009656; Fri, 28 Jun 2002 00:31:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5S7VsnN009655; Fri, 28 Jun 2002 00:31:54 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5S7Vok7009648 for ; Fri, 28 Jun 2002 00:31:51 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA21114 for ; Fri, 28 Jun 2002 00:31:54 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA23490 for ; Fri, 28 Jun 2002 00:31:52 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g5S7VZm02575; Fri, 28 Jun 2002 10:31:35 +0300 Date: Fri, 28 Jun 2002 10:31:34 +0300 (EEST) From: Pekka Savola To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: itojun@iijlab.net, Thomas Narten , Subject: Re: IESG comments on draft-ietf-ipngwg-icmp-name-lookups-09.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 28 Jun 2002, JINMEI Tatuya / [ISO-2022-JP] $B?@L@C#:H(B wrote: > The point, IMO, is that even DNS PTR responses are not reliable enough > for access control purposes, as described in > draft-ietf-dnsop-inaddr-required-03.txt. The draft does not descibe that adequately. The only places I see are in: 4: [...] The use of IN-ADDR, sometimes in conjunction with a lookup of the name resulting from the PTR record adds no real security, [...] and 5: By recommending applications avoid using IN-ADDR as a security mechanism this document points out that this practice, despite its use by many applications, is an ineffective form of security. Applications should use better mechanisms of authentication. I would not call this a "description", I call it FUD. >With this fact it does not > matter that DNS PTRs are much more reliable than node information > replies. We can only use the responses/replies just as a hint anyway. I would agree that if a security mechanism checks only PTR, and _not_ the resulting address to match that PTR, the security level is roughly the same. But no self-respecting implementation does that. In any case, I regard PTR+name lookup as a (relatively strong) hint, not an only form of authentication. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 28 00:49:54 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5S7nsk7009690; Fri, 28 Jun 2002 00:49:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5S7nrnM009689; Fri, 28 Jun 2002 00:49:53 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5S7nnk7009682 for ; Fri, 28 Jun 2002 00:49:49 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA24236 for ; Fri, 28 Jun 2002 00:49:50 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA00212 for ; Fri, 28 Jun 2002 00:49:44 -0700 (PDT) Received: from localhost ([3ffe:501:4819:2000:200:39ff:fe10:85d7]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g5S7nWA01664; Fri, 28 Jun 2002 16:49:32 +0900 (JST) Date: Fri, 28 Jun 2002 16:49:30 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Pekka Savola Cc: itojun@iijlab.net, Thomas Narten , Subject: Re: IESG comments on draft-ietf-ipngwg-icmp-name-lookups-09.txt In-Reply-To: References: User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 45 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Fri, 28 Jun 2002 10:31:34 +0300 (EEST), >>>>> Pekka Savola said: >> The point, IMO, is that even DNS PTR responses are not reliable enough >> for access control purposes, as described in >> draft-ietf-dnsop-inaddr-required-03.txt. > The draft does not descibe that adequately. > The only places I see are in: > 4: > [...] The use > of IN-ADDR, sometimes in conjunction with a lookup of the name > resulting from the PTR record adds no real security, [...] > and > 5: > By recommending applications avoid using IN-ADDR as a security > mechanism this document points out that this practice, despite its > use by many applications, is an ineffective form of security. > Applications should use better mechanisms of authentication. > I would not call this a "description", I call it FUD. So the point is whether it is reasonable to rely on PTRs (+name) for access control, rather than about the usage of node information as a replacement of PTRs (assuming that PTRs are insecure too). If we can agree to the sense of the "inaddr-required" draft, the usage of node information will also be acceptable. Otherwise, the usage of node information will also be unacceptable. In my understanding, draft-ietf-dnsop-inaddr-required-03.txt is based on some consensus in the dnsop group, and it seems to me the IESG also agrees on this according to a previous message from Thomas. I basically agree, too. If you think it a FUD, please convince them (including me) and make an opposite consensus. 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 Fri Jun 28 00:59:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5S7xmk7009749; Fri, 28 Jun 2002 00:59:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5S7xmqo009748; Fri, 28 Jun 2002 00:59:48 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5S7xjk7009741 for ; Fri, 28 Jun 2002 00:59:45 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA11367 for ; Fri, 28 Jun 2002 00:59:50 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA09050 for ; Fri, 28 Jun 2002 01:59:49 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g5S7xdY02783; Fri, 28 Jun 2002 10:59:39 +0300 Date: Fri, 28 Jun 2002 10:59:39 +0300 (EEST) From: Pekka Savola To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: itojun@iijlab.net, Thomas Narten , Subject: Re: IESG comments on draft-ietf-ipngwg-icmp-name-lookups-09.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 28 Jun 2002, JINMEI Tatuya / [ISO-2022-JP] $B?@L@C#:H(B wrote: > So the point is whether it is reasonable to rely on PTRs (+name) for > access control, rather than about the usage of node information as a > replacement of PTRs (assuming that PTRs are insecure too). If we can > agree to the sense of the "inaddr-required" draft, the usage of node > information will also be acceptable. Otherwise, the usage of node > information will also be unacceptable. The reality is not always black and white (hence the applicability statements..). > In my understanding, draft-ietf-dnsop-inaddr-required-03.txt is based > on some consensus in the dnsop group, and it seems to me the IESG also > agrees on this according to a previous message from Thomas. I > basically agree, too. If you think it a FUD, please convince them > (including me) and make an opposite consensus. I do not disagree with the conclusions as much as I disagree with the way they were reached; the draft does not discuss the actual insecurity at all. I'll send specific comments to the draft to dnsop and you later; unless I hear otherwise, I'm not sure whether it's useful to include ipng in this discussion. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 28 01:06:42 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5S86gk7009773; Fri, 28 Jun 2002 01:06:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5S86fub009772; Fri, 28 Jun 2002 01:06:41 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5S86Zk7009765 for ; Fri, 28 Jun 2002 01:06:35 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA13498 for ; Fri, 28 Jun 2002 01:06:40 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.97.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA26160 for ; Fri, 28 Jun 2002 02:06:13 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g5S85VV11616; Fri, 28 Jun 2002 15:05:31 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g5S84Ef13010; Fri, 28 Jun 2002 15:04:25 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: "Tony Hain" cc: moore@cs.utk.edu, "Michel Py" , "Ralph Droms" , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 28 Jun 2002 15:04:14 +0700 Message-ID: <13008.1025251454@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 27 Jun 2002 15:12:21 -0700 From: "Tony Hain" Message-ID: | I agree no address should ever be ambiguous, but that doesn't require | global uniqueness. This all depends upon the frame of reference for "ambiouous". You're agreeing that addresses should be unambiguous from a particular point of reference. Keith wants addresses to be unambiguous from any point of reference - in particular, so an app can send an address from one node to another, without having to worry about whether it will mean the same thing when it arrives as it dopes when it was sent. My take on that is that limited scope addresses simply shouldn't be used that way - it may be true that using DNS names as a reference to ship around isn't good enough (personally, I'm not convinced that if it ever became important they wouldn't be good enough - most of the reported problems are due to laziness or poor knowledge, which affect anything when there's no incentive to do better). But I see no reason not to ship around only known global addresses (ones expected to be globally reachable), and then allow apps that desire to use more limited scope addresses to discover the limited scope address from the global. Incidentally - this also relates to your comment's on the icmp-name-lookups draft ... It also doesn't make any sense to use a mechansim that is clearly getting packets to the dst node to ask it for other addresses that might be used to get packets to it. THe only possible use I can see would be to allow shifting to a different pair for route selection reasons, Another possible use is to shift to a different pair, of a different scope (not caring about the routing used in the slightest). That is, you ask the global addr to return you the site local addresses. As long as it is obvious on the face of it what is a global address, and what is limited scope (which matching fe80::/9 tells us now), having apps only tell others about global addresses, and never passing off a SL addr to another app looks real easy to me. The only requirement is that a global address actually exists 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 Fri Jun 28 01:18:12 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5S8ICk7009802; Fri, 28 Jun 2002 01:18:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5S8IB1w009801; Fri, 28 Jun 2002 01:18:11 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5S8I8k7009794 for ; Fri, 28 Jun 2002 01:18:08 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA12187 for ; Fri, 28 Jun 2002 01:18:14 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.97.5]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA16599 for ; Fri, 28 Jun 2002 02:18:09 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g5S8HQV18137; Fri, 28 Jun 2002 15:17:27 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g5S8Grf13027; Fri, 28 Jun 2002 15:16:53 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: "Michel Py" cc: "Keith Moore" , "Tony Hain" , "Ralph Droms" , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-Reply-To: <2B81403386729140A3A899A8B39B046405E163@server2000.arneill-py.sacramento.ca.us> References: <2B81403386729140A3A899A8B39B046405E163@server2000.arneill-py.sacramento.ca.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 28 Jun 2002 15:16:53 +0700 Message-ID: <13025.1025252213@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 27 Jun 2002 15:35:07 -0700 From: "Michel Py" Message-ID: <2B81403386729140A3A899A8B39B046405E163@server2000.arneill-py.sacramento.ca.us> | but for the | two different methods that ipv6mh is working on, there is no relation | whatsoever between the network/fiber plant topology and the geographical | aggregation. I am waiting to see how this is going to be achieved. That is, all of what you're promising in this message. So far, from what I have seen, I don't see how it can be done. But maybe there's something out there that I just don't understand yet. | True enough. However, you forgot two important things: | | 1. If we make SLs with site IDs globally unique, there might be no | assignement (or the assignement might be automatically granted by the | addressing architecture, say a 37-bot hash of the MAC address, or | whatever). With the geographic scheme we are designing, there would | still be the need to go to a RIR and register a block, so we might still | decide that someone with a dial-up 28.8k modem does not qualify for a | portable, globally unique /48 block. I certainly hope that isn't ever going to happen (with PI or PA addresses). The aim is a /48 for everyone (who requests one), right? What this has to do with anything I said I'm not sure though. | 2. SLs do would not have a supporting protocol if used globally (how | could there be one, if they are not supposed to be used that way). The | way I see the geographical addresses is a support of the multihoming | protocol. And if there is a protocol, there can be safeties and policy | enforcement features built in. Yes, there could be a protocol, with all kinds of things. And it can be turned off, or replaced, if it gets in the way. Once RIP required that there be only one subnet mask through a network ... It isn't possible to enforce anything by relying upon protocols, we have to depend upon agreements, and when appropriate "it is the only possible way". The way we enforce aggregation now, isn't because there's some magic in BGP that requires it, it is because we know of no other way to make routing work. As long as that remains true, we don't have to create protocols to enforce aggregation in IPv6 - it will just naturally be enforced, because no-one can figure out how to not enforce it (nb: it doesn't really matter if a few stray /48's or even /128's "pollute" the global tables - remember the aim is to keep routing working, not to enforce the rule just because it is a rule). If the assumption ("we know no way") ceases to be true, then there's no reason at all that what we currently consider to be non-routable addresses shouldn't appear in the routing tables. Ie: as soon as it is possible to put them there, any policy aimed at keeping them out no longer has a purpose, and should be scrapped. 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 Fri Jun 28 01:30:36 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5S8Uak7009821; Fri, 28 Jun 2002 01:30:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5S8Ua9K009820; Fri, 28 Jun 2002 01:30: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.12.4/8.12.4) with ESMTP id g5S8UXk7009813 for ; Fri, 28 Jun 2002 01:30:33 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA14677 for ; Fri, 28 Jun 2002 01:30:38 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA20647 for ; Fri, 28 Jun 2002 02:30:33 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g5S8UQa10412; Fri, 28 Jun 2002 10:30:26 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id KAA05183; Fri, 28 Jun 2002 10:30:26 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id g5S8UPGF087664; Fri, 28 Jun 2002 10:30:26 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200206280830.g5S8UPGF087664@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Richard Draves" cc: ipng@sunroof.eng.sun.com Subject: Re: Comments on In-reply-to: Your message of Thu, 27 Jun 2002 11:03:51 PDT. <7695E2F6903F7A41961F8CF888D87EA8063CED87@red-msg-06.redmond.corp.microsoft.com> Date: Fri, 28 Jun 2002 10:30:25 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Even if the adversary somehow knows there is only one machine per subnet, I think RFC 3041 still enhances privacy. => I agree but I still have two major concerns about RFC 3041: - one could believe the privacy benefits of RFC 3041 are much higher than they are (the I-D/rfc3041bis(*) is very frank about the limitations). - RFC 3041 (or any random IID scheme) makes the "in-prefix" source address spoofing very easy. Perhaps this is not an important issue but IMHO this must be described in the security considerations. First, it hides the manufacturer of your network card. => if I need this I'll just use the IID ::1... Second, it prevents the adversary from tracking usage of the network card across multiple subnets. This is important for mobile devices. => this is the second case: I tried to make clear this works only when the subnet prefix(es) *and* the interface ID are changed at the same time. Thanks Francis.Dupont@enst-bretagne.fr PS (*): draft-ietf-ipngwg-temp-addresses-v2-00.txt is fine but is expired. IMHO we really need a revision of RFC 3041! -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 28 03:07:26 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5SA7Qk7009981; Fri, 28 Jun 2002 03:07:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5SA7PFT009980; Fri, 28 Jun 2002 03:07:25 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5SA7Mk7009973 for ; Fri, 28 Jun 2002 03:07:22 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA14264 for ; Fri, 28 Jun 2002 03:07:27 -0700 (PDT) Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA13957 for ; Fri, 28 Jun 2002 04:07:26 -0600 (MDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5SA6s2F057872; Fri, 28 Jun 2002 12:06:55 +0200 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with SMTP id g5SA6rK129004; Fri, 28 Jun 2002 12:06:53 +0200 Received: from dhcp23-199.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA37548 from ; Fri, 28 Jun 2002 12:06:50 +0200 Message-Id: <3D1C356E.CDCDE1BD@hursley.ibm.com> Date: Fri, 28 Jun 2002 12:07:42 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Margaret Wasserman Cc: Alain Durand , Bob Hinden , Keith Moore , ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-ietf-ipv6-default-addr-select-08.txt References: <4.3.2.7.2.20020625142522.0268e188@mailhost.iprg.nokia.com> <4.2.2.20020628002926.02399570@mail.windriver.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret Wasserman wrote: > > Hi Alain, > > >There has been a very long discussion on the fate of Site Local addresses > >in the wg. There are still two opposite views of what to do about them: > > Most of that discussion focused on whether or not to remove site-local > addresses from the architecture, not on this draft. And, we have > already determined that there was no consensus to remove them from > the architecture. So, I don't know why it would make sense to remove > them from this draft. > > >a) Do not require apps to support multi-sited nodes now, but > > keep the address selection rules in place. > > This means that in the future, if SL are available, > > they will be used by ALL applications by default. > > An application will only use a site-local destination addresses if it > is returned in the DNS and/or typed locally. So, it can't happen > without the administrator or user doing something to make it happen. > > >b) Do not require apps to support multi-sited nodes now, and > > remove the address selection rule that deal with scoped addresses. > > This means that in the future, if SL are available, > > they will not be used by default, but only by applications that request them. > > I don't understand how this is achieved by removing the default > selection rules. If an application receives a site-local address > from the DNS, how will removing scoped addressing rules from the > default address selection draft prevent the app from using the site-local > address? The assumption is that we are dealing with old apps that don't > know anything about IPv6 scoped addressing, so we can't expect the app > to recognize a site-local address and refuse to use it... > > > Keith has promised a draft to explain the trade-off between those two approaches, > >I think we should not advance draft-ietf-ipv6-default-addr-select-08.txt > >until there is a clear resolution on this question. > > Unfortunately, Keith did not submit a draft by the deadline, so there will > not be a draft before Yokohama. > > The Default Address Selection document has been out for months, has > been reviewed several times by the WG, has undergone a WG last call and > has been reviewed by the IESG. It doesn't seem right to delay this > draft indefinitely waiting for another draft, especially when we haven't > been told about any specific problems that this draft will cause. > > If there are specific, technical objections to this draft, please state > them clearly on the mailing list. It would also be helpful to suggest > specific text changes to the draft. This will give others and opportunity > to agree or disagree about whether the issues should block the publication > of this draft. I think that at this point we should advance the document as it is. While I'm sympathetic to Keith's concerns, I think we have needed address selection *defaults* for a long time, and the default behaviour recommended for SLs is consistent and logical. Defaults are made to be overridden, so the behaviour can always be adjusted. 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 Jun 28 03:09:36 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5SA9Zk7010010; Fri, 28 Jun 2002 03:09:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5SA9ZHe010009; Fri, 28 Jun 2002 03:09:35 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5SA9Wk7010002 for ; Fri, 28 Jun 2002 03:09:32 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA15791 for ; Fri, 28 Jun 2002 03:09:37 -0700 (PDT) Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA14893 for ; Fri, 28 Jun 2002 03:09:36 -0700 (PDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5SA9AEr020214; Fri, 28 Jun 2002 12:09:10 +0200 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with SMTP id g5SA99u112728; Fri, 28 Jun 2002 12:09:09 +0200 Received: from dhcp23-199.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA56234 from ; Fri, 28 Jun 2002 12:09:01 +0200 Message-Id: <3D1C35F1.60689652@hursley.ibm.com> Date: Fri, 28 Jun 2002 12:09:53 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Keith Moore Cc: Michael Thomas , Michel Py , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols References: <200206271621.g5RGLc226234@astro.cs.utk.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > please explain how my private network can get a aggregatable real > global address when it doesn't connect to the public internet. 6to4 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 Jun 28 03:10:53 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5SAArk7010033; Fri, 28 Jun 2002 03:10:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5SAAqJD010032; Fri, 28 Jun 2002 03:10:52 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5SAAnk7010025 for ; Fri, 28 Jun 2002 03:10:49 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA15188 for ; Fri, 28 Jun 2002 03:10:54 -0700 (PDT) Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA25770 for ; Fri, 28 Jun 2002 04:10:52 -0600 (MDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5SAAOEr022228; Fri, 28 Jun 2002 12:10:24 +0200 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with SMTP id g5SAAOK129776; Fri, 28 Jun 2002 12:10:24 +0200 Received: from dhcp23-199.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA38366 from ; Fri, 28 Jun 2002 12:10:18 +0200 Message-Id: <3D1C363E.F60855EA@hursley.ibm.com> Date: Fri, 28 Jun 2002 12:11:10 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Keith Moore Cc: Michael Thomas , Michel Py , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols References: <200206271621.g5RGLc226234@astro.cs.utk.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > SLs without > site-ids cause problems for distributed applications. Only if they leak, which the scope rules prevent. 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 Jun 28 03:14:53 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5SAErk7010059; Fri, 28 Jun 2002 03:14:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5SAEqvm010058; Fri, 28 Jun 2002 03:14:52 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5SAEnk7010051 for ; Fri, 28 Jun 2002 03:14:49 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA01534 for ; Fri, 28 Jun 2002 03:14:54 -0700 (PDT) Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA03538 for ; Fri, 28 Jun 2002 04:14:53 -0600 (MDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5SAEQ2F054170; Fri, 28 Jun 2002 12:14:26 +0200 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with SMTP id g5SAEOu58908; Fri, 28 Jun 2002 12:14:25 +0200 Received: from dhcp23-199.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA54144 from ; Fri, 28 Jun 2002 12:14:23 +0200 Message-Id: <3D1C3733.AB7DEAB6@hursley.ibm.com> Date: Fri, 28 Jun 2002 12:15:15 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Keith Moore Cc: Michael Thomas , Michel Py , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols References: <200206271731.g5RHVu206423@astro.cs.utk.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > the real question is whether ISPs will honor SL prefixes > in the absence of explicit compensation to do so. > My guess (based on current technology) is "no", but they're > welcome to do so if they can manage to deal with the flood. The great advantage of *not* making them globally pseudo-unique is that it makes it impossible for ISPs to do this. Again, they are local and mustn't ever leak; then the whole problem goes away. We didn't have a problem until somebody started talking about exporting local addresses. If we stop talking about it, no more problem. 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 Jun 28 03:21:05 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5SAL5k7010099; Fri, 28 Jun 2002 03:21:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5SAL4lV010098; Fri, 28 Jun 2002 03:21:04 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5SAL1k7010091 for ; Fri, 28 Jun 2002 03:21:01 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA02359 for ; Fri, 28 Jun 2002 03:21:06 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA05850 for ; Fri, 28 Jun 2002 04:21:05 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id F03D34B22; Fri, 28 Jun 2002 19:20:59 +0900 (JST) To: Brian E Carpenter Cc: Keith Moore , Michael Thomas , Michel Py , ipng@sunroof.eng.sun.com In-reply-to: brian's message of Fri, 28 Jun 2002 12:11:10 +0200. <3D1C363E.F60855EA@hursley.ibm.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols From: itojun@iijlab.net Date: Fri, 28 Jun 2002 19:20:59 +0900 Message-Id: <20020628102100.F03D34B22@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> SLs without >> site-ids cause problems for distributed applications. >Only if they leak, which the scope rules prevent. given the common leakage of net 10 addresses (routes, packets with net 10 src/dst, and DNS records), i don't feel confortable with "only if they leak". they will leak. 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 Jun 28 03:36:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5SAabk7010123; Fri, 28 Jun 2002 03:36:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5SAabXf010122; Fri, 28 Jun 2002 03:36:37 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5SAaXk7010115 for ; Fri, 28 Jun 2002 03:36:33 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA20533 for ; Fri, 28 Jun 2002 03:36:38 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA24796 for ; Fri, 28 Jun 2002 04:36:37 -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 GAA17203; Fri, 28 Jun 2002 06:35:38 -0400 (EDT) Message-Id: <200206281035.GAA17203@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-ata-ipv6-anycast-resolving-00.txt Date: Fri, 28 Jun 2002 06:35:38 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A Protocol for Anycast Address Resolving Author(s) : S. Ata, H. Kitamura, M. Murata Filename : draft-ata-ipv6-anycast-resolving-00.txt Pages : Date : 27-Jun-02 This document describes a mechanism to realize anycast communication without any modifications of applications and/or underlying protocols. The mechanism, using a DLL (Dynamic Linkable Library) based approach, is called AARP (Anycast Address Resolving Protocol), which resolves the anycast address into the corresponding unicast address prior to establishing the communication. AARP smoothly supports anycasting without change of existing applications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ata-ipv6-anycast-resolving-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ata-ipv6-anycast-resolving-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-ata-ipv6-anycast-resolving-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: <20020627132905.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ata-ipv6-anycast-resolving-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ata-ipv6-anycast-resolving-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020627132905.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 28 03:44:52 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5SAiqk7010450; Fri, 28 Jun 2002 03:44:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5SAiqtP010449; Fri, 28 Jun 2002 03:44:52 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5SAimk7010442 for ; Fri, 28 Jun 2002 03:44:48 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA21996 for ; Fri, 28 Jun 2002 03:44:53 -0700 (PDT) From: john.loughney@nokia.com Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA14657 for ; Fri, 28 Jun 2002 04:44:52 -0600 (MDT) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g5SAhQd26126 for ; Fri, 28 Jun 2002 13:43:26 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 28 Jun 2002 13:44:51 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 28 Jun 2002 13:44:51 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Section 4.2.1 - draft-ietf-ipv6-node-requirements-00.txt Date: Fri, 28 Jun 2002 13:44:50 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC6559C@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Section 4.2.1 - draft-ietf-ipv6-node-requirements-00.txt Thread-Index: AcIbgAPuGV1pGc7XSWS3d7CXWfEZOADEEEHw To: , X-OriginalArrivalTime: 28 Jun 2002 10:44:51.0438 (UTC) FILETIME=[D4D0E8E0:01C21E90] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5SAink7010443 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Adam, > In section 4.2.1 on RFC2461, you repeat that Router Discovery is > Unconditionally manatory twice. Thanks, got it. > Also, I'd like to understand why the ability to disable Router Discovery is > marked as a SHOULD instead of a MAY. I don't recall anything in 2461 that > calls this out. > > With the way I do things, making this a SHOULD in this type of document > pretty much means I'm going to have to add and document yet another > configuration toggle, one that I personally don't see any value to (at > least for the type of equipment we are producing). Making this a MAY > allows those vendors who see this as a requirment to go ahead and implement > this, while giving other vendors who see no such requirement the option to > leave it out. Thinking about this, I tend to agree with you. I think router discovery is mandatory, and nowhere does 2461 talk about disabling it. John -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 28 04:08:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5SB89k7010594; Fri, 28 Jun 2002 04:08:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5SB89Jc010593; Fri, 28 Jun 2002 04:08:09 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5SB86k7010586 for ; Fri, 28 Jun 2002 04:08:06 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA09893 for ; Fri, 28 Jun 2002 04:08:11 -0700 (PDT) From: john.loughney@nokia.com Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA13939 for ; Fri, 28 Jun 2002 05:08:10 -0600 (MDT) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g5SB6hd08799 for ; Fri, 28 Jun 2002 14:06:43 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 28 Jun 2002 14:08:08 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 28 Jun 2002 13:54:19 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C21E92.27110FA3" Subject: RE: Stateful Address Config - I-D ACTION:draft-ietf-ipv6-node-requirements-00.txt Date: Fri, 28 Jun 2002 13:54:18 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC6559D@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Stateful Address Config - I-D ACTION:draft-ietf-ipv6-node-requirements-00.txt Thread-Index: AcIZPZgy8+uKW4V4QuqxPGtOHAtoKwFVH1eA To: , X-OriginalArrivalTime: 28 Jun 2002 10:54:19.0695 (UTC) FILETIME=[27860BF0:01C21E92] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C21E92.27110FA3 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Adam, =20 Very good point. I have added the following text: =20 =20 4.5.5 Stateful Address Autoconfiguration IPv6 Stateless Address Autoconfiguration [RFC2462] defines stateless = address autoconfiguation. However, it does state that in the absence of = routers, hosts must perform host MUST attempt to use stateful = autoconfiguration. There is also reference to stateful address = autoconfiguration being defined elsewhere. Additionally, DHCP [DHCP] = states that it is on option for stateful address autoconfiguation. =20 >From the current set of specification, it is not clear the level of = support that is needed for statefull Address Autoconfiguration. =20 -----Original Message----- From: ext Adam Machalek [mailto:Adam_Machalek@nmss.com] Sent: 21 June, 2002 18:52 To: ipng@sunroof.eng.sun.com Subject: Stateful Address Config - I-D = ACTION:draft-ietf-ipv6-node-requirements-00.txt John,=20 Section 5.4 on DHCPv6 states that DHCPv6 is unconditionally optional, = which today implicitly makes Stateful Address config optional. =20 However, I'd like to see some direct clarification in this document on = Stateful Address config, probably directly after Section 4.5.2 = discussing Stateless Address config. =20 RFC2462 has some ambiguities, in particular, it states "a managed = address configuration flag indicates whether hosts should use stateful = autoconfiguration", not SHOULD. Later in 2462 in section 5.2 it = continues this ambiguity by never explicitly using MAY/SHOULD/MUST = anywhere.=20 Still later in section RFC2462 5.5.2 Absence of Router Advertisements, = it finally states that in the absence of a router, a host MUST attempt = to use stateful autoconfiguration.=20 And lastly, the DHCPv6 draft states "DHCP is one vehicle to perform = stateful autoconfiguration", implying that there may be others.=20 So in the end, even with DHCPv6 optional, this doesn't clarify exactly = what a host should do about Stateful Address autoconfiguration.=20 Adam Machalek ------_=_NextPart_001_01C21E92.27110FA3 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi=20 Adam,
 
Very=20 good point.  I have added the following text:
 
 

4.5.5=20 Stateful Address Autoconfiguration

IPv6=20 Stateless Address Autoconfiguration [RFC2462] defines stateless address=20 autoconfiguation.  = However, it does=20 state that in the absence of routers, hosts must perform host MUST = attempt to=20 use stateful autoconfiguration.  There is also reference to = stateful=20 address autoconfiguration being defined elsewhere. Additionally, DHCP = [DHCP]=20 states that it is on option for stateful address autoconfiguation. 

From=20 the current set of specification, it is not clear the level of support = that is=20 needed for statefull Address Autoconfiguration.

 

-----Original Message-----
From: ext Adam Machalek=20 [mailto:Adam_Machalek@nmss.com]
Sent: 21 June, 2002=20 18:52
To: ipng@sunroof.eng.sun.com
Subject: = Stateful=20 Address Config - I-D=20 = ACTION:draft-ietf-ipv6-node-requirements-00.txt


<= FONT=20 face=3Dsans-serif size=3D2>John,

Section 5.4 on DHCPv6 states that DHCPv6 is unconditionally = optional,=20 which today implicitly makes Stateful Address config optional. =  =20

However, I'd like to see some = direct=20 clarification in this document on Stateful Address config, probably = directly=20 after Section 4.5.2 discussing Stateless Address config.   =

RFC2462 has some ambiguities, = in=20 particular, it states "a managed address configuration flag indicates = whether=20 hosts should use stateful autoconfiguration", not SHOULD.   Later = in 2462=20 in section 5.2 it continues this ambiguity by never explicitly using=20 MAY/SHOULD/MUST anywhere.

Still=20 later in section RFC2462 5.5.2 Absence of Router Advertisements, it = finally=20 states that in the absence of a router, a host MUST attempt to use = stateful=20 autoconfiguration.

And = lastly, the=20 DHCPv6 draft states "DHCP is one vehicle to perform stateful=20 autoconfiguration", implying that there may be others. =

So in the end, even with DHCPv6 optional, = this doesn't=20 clarify exactly what a host should do about Stateful Address=20 autoconfiguration.

Adam=20 Machalek ------_=_NextPart_001_01C21E92.27110FA3-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 28 04:19:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5SBJik7010640; Fri, 28 Jun 2002 04:19:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5SBJimu010639; Fri, 28 Jun 2002 04:19:44 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5SBJfk7010632 for ; Fri, 28 Jun 2002 04:19:41 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA12529 for ; Fri, 28 Jun 2002 04:19:47 -0700 (PDT) From: john.loughney@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA12477 for ; Fri, 28 Jun 2002 04:19:46 -0700 (PDT) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g5SBKCi02023 for ; Fri, 28 Jun 2002 14:20:13 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 28 Jun 2002 14:19:45 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 28 Jun 2002 14:19:44 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Comments on Node Requirements document Date: Fri, 28 Jun 2002 14:19:43 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC6559E@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on Node Requirements document Thread-Index: AcIcOJkPCvMcr05bTruVTRvHTTiCowCXOA2A To: , X-OriginalArrivalTime: 28 Jun 2002 11:19:44.0504 (UTC) FILETIME=[B4616F80:01C21E95] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5SBJgk7010633 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Pekka, > 4.2.1 RFC2461 - Neighbor Discovery for IPv6 > > Receiving Router Advertisement is unconditionally mandatory for host > implementation, with a configuration option to disable this > functionality. > > ==> I guess the node must also process the RA, but that's semantics. Are > all features (now and future :-) in RA's a must to implement > and support? Well, that would be some code if it could do all of that. What is your suggestion for text? John -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 28 04:34:11 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5SBYBk7010683; Fri, 28 Jun 2002 04:34:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5SBYB9X010682; Fri, 28 Jun 2002 04:34:11 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5SBY8k7010675 for ; Fri, 28 Jun 2002 04:34:08 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA03005 for ; Fri, 28 Jun 2002 04:34:13 -0700 (PDT) Received: from mail8.nc.rr.com (fe8.southeast.rr.com [24.93.67.55]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA16255 for ; Fri, 28 Jun 2002 05:34:12 -0600 (MDT) Received: from nc.rr.com ([24.162.252.183]) by mail8.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Fri, 28 Jun 2002 07:25:53 -0400 Message-ID: <3D1C4716.5037B2DB@nc.rr.com> Date: Fri, 28 Jun 2002 07:23:02 -0400 From: Brian Haberman X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: itojun@iijlab.net CC: Brian E Carpenter , Keith Moore , Michael Thomas , Michel Py , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols References: <20020628102100.F03D34B22@coconut.itojun.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk itojun@iijlab.net wrote: > > >> SLs without > >> site-ids cause problems for distributed applications. > >Only if they leak, which the scope rules prevent. > > given the common leakage of net 10 addresses (routes, packets > with net 10 src/dst, and DNS records), i don't feel confortable > with "only if they leak". they will leak. At least now the scoped addressing architecture has rules that prevent leakage (from the routing and forwarding perspective). I don't recall those existing for net 10. 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 Jun 28 04:40:55 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5SBetk7010717; Fri, 28 Jun 2002 04:40:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5SBesYZ010716; Fri, 28 Jun 2002 04:40:54 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5SBeok7010709 for ; Fri, 28 Jun 2002 04:40:50 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA15467 for ; Fri, 28 Jun 2002 04:40:55 -0700 (PDT) Received: from fep04-svc.swip.net (fep04.swip.net [130.244.199.132]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA23709 for ; Fri, 28 Jun 2002 05:40:54 -0600 (MDT) Received: from nansb ([193.216.185.140]) by fep04-svc.swip.net with SMTP id <20020628114053.IQUA16964.fep04-svc.swip.net@nansb> for ; Fri, 28 Jun 2002 13:40:53 +0200 Message-ID: <003f01c21e98$a8b176a0$8cb9d8c1@nansb> From: "Nils Agne Nordbotten" To: Subject: Duplicate Address Detection Date: Fri, 28 Jun 2002 13:40:52 +0200 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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, RFC 2462 (IPv6 Stateless Address Autoconfiguration) states that: "....for a set of addresses formed from the same interface identifier, it is sufficient to check that the link-local address generated from the identifier is unique on the link. In such cases, the link-local address MUST be tested for uniqueness, and if no duplicate address is detected, an implementation MAY choose to skip Duplicate Address Detection for additional addresses derived from the same interface identifier..." It also says: ".....To accommodate sites that believe the overhead of performing Duplicate Address Detection outweighs its benefits, the use of Duplicate Address Detection can be disabled through the administrative setting of a per-interface configuration flag....." Does this last segment mean that Duplicate Address Detection can be skipped completely at a site, or does it refer to the MAY part of the first segment (that it may be skipped for additional addresses, but not for the link-local IPv6 address)? I belive skipping this check completely could be effective in networks with low resources and where each device has a unique interface identifier. Thanks in advance. Nils Nordbotten -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 28 05:15:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5SCF7k7010848; Fri, 28 Jun 2002 05:15:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5SCF7Ul010847; Fri, 28 Jun 2002 05:15:07 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5SCF4k7010839 for ; Fri, 28 Jun 2002 05:15:04 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA11225 for ; Fri, 28 Jun 2002 05:15:10 -0700 (PDT) Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA13023 for ; Fri, 28 Jun 2002 06:15:09 -0600 (MDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5SBC6Er010046; Fri, 28 Jun 2002 13:12:09 +0200 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with SMTP id g5SBC4u57816; Fri, 28 Jun 2002 13:12:04 +0200 Received: from dhcp23-199.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA59754 from ; Fri, 28 Jun 2002 13:11:55 +0200 Message-Id: <3D1C44AE.CDA9F359@hursley.ibm.com> Date: Fri, 28 Jun 2002 13:12:46 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: itojun@iijlab.net Cc: Keith Moore , Michael Thomas , Michel Py , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols References: <20020628102100.F03D34B22@coconut.itojun.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk itojun@iijlab.net wrote: > > >> SLs without > >> site-ids cause problems for distributed applications. > >Only if they leak, which the scope rules prevent. > > given the common leakage of net 10 addresses (routes, packets > with net 10 src/dst, and DNS records), i don't feel confortable > with "only if they leak". they will leak. Is that any reason to make them meaningful once leaked? 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 Jun 28 05:58:50 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5SCwnk7010996; Fri, 28 Jun 2002 05:58:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5SCwnUC010995; Fri, 28 Jun 2002 05:58:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5SCwhk7010988 for ; Fri, 28 Jun 2002 05:58:43 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA21447 for ; Fri, 28 Jun 2002 05:58:49 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA26361; Fri, 28 Jun 2002 05:58:49 -0700 (PDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5SCwh202045; Fri, 28 Jun 2002 08:58:44 -0400 (EDT) Message-Id: <200206281258.g5SCwh202045@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Margaret Wasserman cc: Alain Durand , Bob Hinden , Keith Moore , ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-ietf-ipv6-default-addr-select-08.txt In-reply-to: (Your message of "Fri, 28 Jun 2002 00:41:10 EDT.") <4.2.2.20020628002926.02399570@mail.windriver.com> Date: Fri, 28 Jun 2002 08:58:43 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >There has been a very long discussion on the fate of Site Local addresses > >in the wg. There are still two opposite views of what to do about them: > > Most of that discussion focused on whether or not to remove site-local > addresses from the architecture, not on this draft. And, we have > already determined that there was no consensus to remove them from > the architecture. So, I don't know why it would make sense to remove > them from this draft. they really are separate issues - SL addresses could still exist and be useful (to a very limited degree - which I think is a reasonable assement of their utility anyway) even if they were never selected when other alternatives were available. however I think that as long as they exist at all the address selection document should mention them for completeness, even if it says to not use them when other alternatives are available. otherwise it's confusing. > >a) Do not require apps to support multi-sited nodes now, but > > keep the address selection rules in place. > > This means that in the future, if SL are available, > > they will be used by ALL applications by default. > > An application will only use a site-local destination addresses if it > is returned in the DNS and/or typed locally. So, it can't happen > without the administrator or user doing something to make it happen. this is a bit over-simplistic. apps obtain addresses from other sources besides DNS and direct input, and the trend is toward more ways to get addresses rather than fewer. for instance, a component of a distributed app that wishes to advertise addresses to peers may get them from the host's interface table, because this is the most reliable source. it has no idea about which of its host's addresses are advertised in dns or what their scopes or lifetimes are, nor even which dns names (if any) are proprely used in that context for that application. DNS names are not just names of hosts any more - they're more commonly used as names of services, and the mapping of service names onto hosts is not one-to-one but essentially arbitrary. multiple service names may point to an IP address if multiple services are provided at that IP address, and a single service name may point to multiple IP addresses if the equivalent service is provided on each of those hosts. the idea that a host has "a" DNS name - especially for a host that supports multiple applications - is an anachronism. > > Keith has promised a draft to explain the trade-off between those two approaches, > >I think we should not advance draft-ietf-ipv6-default-addr-select-08.txt > >until there is a clear resolution on this question. > > Unfortunately, Keith did not submit a draft by the deadline, so there will > not be a draft before Yokohama. there won't be an internet-draft, but you will have my comments by then. since I don't expect this draft to be a work item of ipv6 wg anyway (the issue is wider than ipv6), I don't think it violates procedure to consider that input any more than it violates procedure to consider input from an email message. unfortunately, *I* won't be in Yokahama to discuss it. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 28 06:04:28 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5SD4Rk7011194; Fri, 28 Jun 2002 06:04:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5SD4Rag011193; Fri, 28 Jun 2002 06:04:27 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5SD4Ok7011186 for ; Fri, 28 Jun 2002 06:04:24 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA13059 for ; Fri, 28 Jun 2002 06:04:30 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA19767 for ; Fri, 28 Jun 2002 07:04:29 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g5SD4Qa18652; Fri, 28 Jun 2002 15:04:26 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id PAA08336; Fri, 28 Jun 2002 15:04:26 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id g5SD4PGF088851; Fri, 28 Jun 2002 15:04:26 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200206281304.g5SD4PGF088851@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Nils Agne Nordbotten" cc: ipng@sunroof.eng.sun.com Subject: Re: Duplicate Address Detection In-reply-to: Your message of Fri, 28 Jun 2002 13:40:52 +0200. <003f01c21e98$a8b176a0$8cb9d8c1@nansb> Date: Fri, 28 Jun 2002 15:04:25 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: RFC 2462 (IPv6 Stateless Address Autoconfiguration) states that: "....for a set of addresses formed from the same interface identifier, it is sufficient to check that the link-local address generated from the identifier is unique on the link. In such cases, the link-local address MUST be tested for uniqueness, and if no duplicate address is detected, an implementation MAY choose to skip Duplicate Address Detection for additional addresses derived from the same interface identifier..." It also says: ".....To accommodate sites that believe the overhead of performing Duplicate Address Detection outweighs its benefits, the use of Duplicate Address Detection can be disabled through the administrative setting of a per-interface configuration flag....." => this (the fact RFC 2462 and the address architecture I-D don't make a clear choice between DAD and DIIDD (Duplicate Interface ID Detection)) is already well known but not (yet?) fixed. I belive skipping this check completely could be effective in networks with low resources and where each device has a unique interface identifier. => I count this as a vote in favor of DIIDD. Regards Francis.Dupont@enst-bretagne.fr PS: BTW I haven't seen yet the call for agenda for the IPv6 WG... -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 28 06:16:11 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5SDGAk7011228; Fri, 28 Jun 2002 06:16:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5SDGAlJ011227; Fri, 28 Jun 2002 06:16:10 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5SDG5k7011220 for ; Fri, 28 Jun 2002 06:16:06 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA26482 for ; Fri, 28 Jun 2002 06:15:42 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA14951 for ; Fri, 28 Jun 2002 07:15:41 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5SDAK204059; Fri, 28 Jun 2002 09:10:21 -0400 (EDT) Message-Id: <200206281310.g5SDAK204059@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Robert Elz cc: "Tony Hain" , moore@cs.utk.edu, "Michel Py" , "Ralph Droms" , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-reply-to: (Your message of "Fri, 28 Jun 2002 15:04:14 +0700.") <13008.1025251454@munnari.OZ.AU> Date: Fri, 28 Jun 2002 09:10:20 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > This all depends upon the frame of reference for "ambiouous". You're > agreeing that addresses should be unambiguous from a particular point > of reference. Keith wants addresses to be unambiguous from any point > of reference - in particular, so an app can send an address from one > node to another, without having to worry about whether it will mean the > same thing when it arrives as it dopes when it was sent. > > My take on that is that limited scope addresses simply shouldn't be used > that way - I could agree with this *if* there were a mechanism to ensure that sites always had a globally-scoped address available to them - then we could say that limited-scope addresses should not be used in referrals. > it may be true that using DNS names as a reference to ship > around isn't good enough (personally, I'm not convinced that if it > ever became important they wouldn't be good enough - most of the reported > problems are due to laziness or poor knowledge, which affect anything > when there's no incentive to do better). it's important *now*, it's just that you don't see the apps for which it is important. and the problems are inherent in DNS itself - the degree to which it is federated and distributed, that and the names don't mean what you think they mean - and in a network that has differences in link bandwidths (and delays) ranging several orders of magnitude - to say nothing of varying load and packet loss rates. > But I see no reason not to ship around only known global addresses > (ones expected to be globally reachable), and then allow apps that desire > to use more limited scope addresses to discover the limited scope address > from the global. the reason to ship around limited-scope adresses in the current environment is that in some cases they're the only ones available, and in some cases the limited-scope address might work better than the global-scoped address. however one could argue that the latter situation is a failure of the network, or more likely a failure to configure the routing protocols properly. > As long as it is obvious on the face of it what is a global address, > and what is limited scope (which matching fe80::/9 tells us now), having > apps only tell others about global addresses, and never passing off a SL > addr to another app looks real easy to me. > > The only requirement is that a global address actually exists to use. and that if provided there is a signal path available, then that address serves to route the packet to the destination from that source. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 28 06:19:52 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5SDJqk7011253; Fri, 28 Jun 2002 06:19:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5SDJqSE011252; Fri, 28 Jun 2002 06:19:52 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5SDJmk7011245 for ; Fri, 28 Jun 2002 06:19:48 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA17229 for ; Fri, 28 Jun 2002 06:19:54 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA17259 for ; Fri, 28 Jun 2002 07:19:53 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5SDJg205535; Fri, 28 Jun 2002 09:19:42 -0400 (EDT) Message-Id: <200206281319.g5SDJg205535@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Brian E Carpenter cc: Margaret Wasserman , Alain Durand , Bob Hinden , Keith Moore , ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-ietf-ipv6-default-addr-select-08.txt In-reply-to: (Your message of "Fri, 28 Jun 2002 12:07:42 +0200.") <3D1C356E.CDCDE1BD@hursley.ibm.com> Date: Fri, 28 Jun 2002 09:19:42 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I think that at this point we should advance the document as it is. While > I'm sympathetic to Keith's concerns, I think we have needed address selection > *defaults* for a long time, and the default behaviour recommended for SLs > is consistent and logical. > > Defaults are made to be overridden, so the behaviour can always be adjusted. I think the appropriate goal should be to provide a consistent API - both from one platform to another and over time. The trick is making this API work despite potential introduction of new address classifications (e.g. globally-unique non-publically-routables) or deprecation of old ones (e.g. non-unique site-locals). I'll be very surprised if we manage to make things work with the existing set of address classifications. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 28 06:23:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5SDN8k7011289; Fri, 28 Jun 2002 06:23:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5SDN8bX011288; Fri, 28 Jun 2002 06:23:08 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5SDN4k7011281 for ; Fri, 28 Jun 2002 06:23:04 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA03597 for ; Fri, 28 Jun 2002 06:23:10 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA07342 for ; Fri, 28 Jun 2002 06:23:10 -0700 (PDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5SDN1205956; Fri, 28 Jun 2002 09:23:01 -0400 (EDT) Message-Id: <200206281323.g5SDN1205956@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Brian E Carpenter cc: Keith Moore , Michael Thomas , Michel Py , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-reply-to: (Your message of "Fri, 28 Jun 2002 12:09:53 +0200.") <3D1C35F1.60689652@hursley.ibm.com> Date: Fri, 28 Jun 2002 09:23:01 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > please explain how my private network can get a aggregatable real > > global address when it doesn't connect to the public internet. > > 6to4 to me "doesn't connect to the public Internet" means that neither v4 nor v6 connectivity is provided. also, 6to4 has the built-in assumption that if you use a 6to4 prefixes then you can actually route to that prefix over the public IPv4 Internet. and 6to4 has its own special place in the address selection rules based on assumptions about how it is used. so it's not reasonable to use 6to4 merely as a means for allocating a unique v6 prefix. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 28 06:24:21 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5SDOLk7011308; Fri, 28 Jun 2002 06:24:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5SDOL6S011307; Fri, 28 Jun 2002 06:24:21 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5SDOGk7011299 for ; Fri, 28 Jun 2002 06:24:16 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA28850 for ; Fri, 28 Jun 2002 06:24:23 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA28977 for ; Fri, 28 Jun 2002 07:24:22 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5SDNw206093; Fri, 28 Jun 2002 09:23:58 -0400 (EDT) Message-Id: <200206281323.g5SDNw206093@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Brian E Carpenter cc: Keith Moore , Michael Thomas , Michel Py , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-reply-to: (Your message of "Fri, 28 Jun 2002 12:11:10 +0200.") <3D1C363E.F60855EA@hursley.ibm.com> Date: Fri, 28 Jun 2002 09:23:58 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > SLs without > > site-ids cause problems for distributed applications. > > Only if they leak, which the scope rules prevent. scope rules don't prevent SLs from being used in referrals, and in the current state of things apps may not have any suitable alternative to using an SL in a referral. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 28 06:28:16 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5SDSFk7011331; Fri, 28 Jun 2002 06:28:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5SDSFmO011330; Fri, 28 Jun 2002 06:28:15 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5SDSBk7011323 for ; Fri, 28 Jun 2002 06:28:11 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA29831 for ; Fri, 28 Jun 2002 06:28:17 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA00766 for ; Fri, 28 Jun 2002 07:28:17 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5SDQm206474; Fri, 28 Jun 2002 09:26:48 -0400 (EDT) Message-Id: <200206281326.g5SDQm206474@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Brian E Carpenter cc: Keith Moore , Michael Thomas , Michel Py , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-reply-to: (Your message of "Fri, 28 Jun 2002 12:15:15 +0200.") <3D1C3733.AB7DEAB6@hursley.ibm.com> Date: Fri, 28 Jun 2002 09:26:48 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > the real question is whether ISPs will honor SL prefixes > > in the absence of explicit compensation to do so. > > My guess (based on current technology) is "no", but they're > > welcome to do so if they can manage to deal with the flood. > > The great advantage of *not* making them globally pseudo-unique > is that it makes it impossible for ISPs to do this. Again, they > are local and mustn't ever leak; then the whole problem goes away. > We didn't have a problem until somebody started talking about > exporting local addresses. If we stop talking about it, no > more problem. sounds like the ostrich theory of engineering. ignoring the problem doesn't mean that it will go away, it means that we'll have an even less reliable network than we do now. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 28 06:34:30 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5SDYUk7011356; Fri, 28 Jun 2002 06:34:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5SDYUHf011355; Fri, 28 Jun 2002 06:34:30 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5SDYQk7011348 for ; Fri, 28 Jun 2002 06:34:26 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA06069 for ; Fri, 28 Jun 2002 06:34:32 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA16031 for ; Fri, 28 Jun 2002 07:34:32 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5SDVO207269; Fri, 28 Jun 2002 09:31:24 -0400 (EDT) Message-Id: <200206281331.g5SDVO207269@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Brian Haberman cc: itojun@iijlab.net, Brian E Carpenter , Keith Moore , Michael Thomas , Michel Py , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-reply-to: (Your message of "Fri, 28 Jun 2002 07:23:02 EDT.") <3D1C4716.5037B2DB@nc.rr.com> Date: Fri, 28 Jun 2002 09:31:24 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > >> SLs without > > >> site-ids cause problems for distributed applications. > > >Only if they leak, which the scope rules prevent. > > > > given the common leakage of net 10 addresses (routes, packets > > with net 10 src/dst, and DNS records), i don't feel confortable > > with "only if they leak". they will leak. > > At least now the scoped addressing architecture has rules that prevent > leakage (from the routing and forwarding perspective). yes, but not through apps performing referrals (including DNS as just one example). ambiguous addresses will leak. if we give apps alternatives to advertising ambiguous addresses, then we can credibly say to apps "don't use ambiguous addresses in referrals" but right now there are situations where the only addresses available might be ambiguous, and there's no way for a network to obtain an unambiguous address short of connecting to the global internet, which it might not want to do. we need to fix this, and we can't fix it by merely tweaking the address selection rules. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 28 06:50:25 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5SDoPk7011383; Fri, 28 Jun 2002 06:50:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5SDoPhV011382; Fri, 28 Jun 2002 06:50:25 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5SDoKk7011375 for ; Fri, 28 Jun 2002 06:50:20 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA23899 for ; Fri, 28 Jun 2002 06:50:25 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA03231 for ; Fri, 28 Jun 2002 07:50:24 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5SDla209463; Fri, 28 Jun 2002 09:47:36 -0400 (EDT) Message-Id: <200206281347.g5SDla209463@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Brian E Carpenter cc: itojun@iijlab.net, Keith Moore , Michael Thomas , Michel Py , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-reply-to: (Your message of "Fri, 28 Jun 2002 13:12:46 +0200.") <3D1C44AE.CDA9F359@hursley.ibm.com> Date: Fri, 28 Jun 2002 09:47:36 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > >> SLs without > > >> site-ids cause problems for distributed applications. > > >Only if they leak, which the scope rules prevent. > > > > given the common leakage of net 10 addresses (routes, packets > > with net 10 src/dst, and DNS records), i don't feel confortable > > with "only if they leak". they will leak. > > Is that any reason to make them meaningful once leaked? if a host or app can tell "this address doesn't belong on my net" by looking at it, then that's quite useful - the host or app knows to avoid trying to use that address merely by looking at it. or if that's not the case, if the local router can immediately tell "I have no way to route to this eaddress" and issue an ICMP message, then the host or app can immediately try another address - this is far better than having the network treat such addresses as local and forcing the host or app to wait for a timeout. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 28 06:54:14 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5SDsDk7011443; Fri, 28 Jun 2002 06:54:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5SDsD3G011440; Fri, 28 Jun 2002 06:54:13 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5SDs9k7011432 for ; Fri, 28 Jun 2002 06:54:09 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA06626 for ; Fri, 28 Jun 2002 06:54:14 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA05213 for ; Fri, 28 Jun 2002 07:54:13 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 39AEA4B2A; Fri, 28 Jun 2002 22:54:06 +0900 (JST) To: Brian E Carpenter Cc: Keith Moore , Michael Thomas , Michel Py , ipng@sunroof.eng.sun.com In-reply-to: brian's message of Fri, 28 Jun 2002 13:12:46 +0200. <3D1C44AE.CDA9F359@hursley.ibm.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols From: itojun@iijlab.net Date: Fri, 28 Jun 2002 22:54:06 +0900 Message-Id: <20020628135406.39AEA4B2A@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> >> SLs without >> >> site-ids cause problems for distributed applications. >> >Only if they leak, which the scope rules prevent. >> given the common leakage of net 10 addresses (routes, packets >> with net 10 src/dst, and DNS records), i don't feel confortable >> with "only if they leak". they will leak. >Is that any reason to make them meaningful once leaked? sorry for confusion, i vote for killing sitelocal entirely. 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 Jun 28 07:02:17 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5SE2Gk7011515; Fri, 28 Jun 2002 07:02:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5SE2G0S011514; Fri, 28 Jun 2002 07:02:16 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5SE2Bk7011507 for ; Fri, 28 Jun 2002 07:02:12 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA09090 for ; Fri, 28 Jun 2002 07:02:09 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA18240 for ; Fri, 28 Jun 2002 08:02:08 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5SE22212060; Fri, 28 Jun 2002 10:02:04 -0400 (EDT) Message-Id: <200206281402.g5SE22212060@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Vijay Amrit Agrawal" cc: ipng@sunroof.eng.sun.com Subject: Re: Maybe: IPv6 Scoped Addresses and Routing Protocols In-reply-to: (Your message of "Fri, 28 Jun 2002 10:17:18 +0530.") <006601c21e5e$e2383a10$9704120a@in.huawei.com> Date: Fri, 28 Jun 2002 10:02:02 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Why not try to make IPv6 such that, it can work well even when > technology like NAT is deployed i.e. the end address is different from the > transport address. the problem with NAT isn't just that the address changes in transit; it's also that NATs split up the network into multiple addressing realms and make addresses ambiguous. there's really no way to solve that problem. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 28 07:20:27 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5SEKRk7011557; Fri, 28 Jun 2002 07:20:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5SEKQZ0011556; Fri, 28 Jun 2002 07:20: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.12.4/8.12.4) with ESMTP id g5SEKNk7011549 for ; Fri, 28 Jun 2002 07:20:23 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA00306 for ; Fri, 28 Jun 2002 07:20:28 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.97.5]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA24896 for ; Fri, 28 Jun 2002 08:20:22 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g5SEJjV07252; Fri, 28 Jun 2002 21:19:45 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g5SEJ4f15752; Fri, 28 Jun 2002 21:19:04 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Keith Moore cc: "Tony Hain" , "Michel Py" , "Ralph Droms" , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-Reply-To: <200206281310.g5SDAK204059@astro.cs.utk.edu> References: <200206281310.g5SDAK204059@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 28 Jun 2002 21:19:04 +0700 Message-ID: <15750.1025273944@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 28 Jun 2002 09:10:20 -0400 From: Keith Moore Message-ID: <200206281310.g5SDAK204059@astro.cs.utk.edu> | I could agree with this *if* there were a mechanism to ensure that | sites always had a globally-scoped address available to them - | then we could say that limited-scope addresses should not be used | in referrals. Yes, I think we need to think a little more about what we do with disconnected federations (rather than disconnected sites) and partially connected federations. These might be areas where one of the geographic addressing schemes might prove useful (Tony's perhaps more than the one from the multi-homing group, as it defines the address that will be allocated to a particular spot on the planet's surface). | it's important *now*, it's just that you don't see the apps for which | it is important. That could be - but if it is important, the DNS can/should be fixed, as: | and the problems are inherent in DNS itself - I don't agree with that at all. Nothing requires a DNS lookup to take a long time, the vast majority of them don't. If one takes a long time, that indicates a configuration problem of some kind, which can and should be corrected. To the degree that isn't happening, the only explanation I can think of is that people simply don't care enough. The problem that does exist is that app designers (and app protocol designers) aren't the ones who get to fix the problems - and rather than simply insisting that things be fixed for the app to work properly, they're working around the problem by just not using DNS names. | the degree to which it is federated and distributed, none of that need cause excessive delays. | that and the names don't mean what you think they mean That indicates configuration problems too. | - and in a network that has differences | in link bandwidths (and delays) ranging several orders of magnitude - | to say nothing of varying load and packet loss rates. All that will affect all parts of an app's performance, not just the DNS part. If anything, the DNS can overcome those kinds of problems (I've been doing it for years) by simply making a local replicated copy any part of the DNS database where normal access causes problems. But even without that, the DNS isn't (or shouldn't) be causing more suffering (for its one occasional lookup every now and then before local caching works) than all of the normal packets that are being delayed, lost, ... | > The only requirement is that a global address actually exists to use. | | and that if provided there is a signal path available, then that address | serves to route the packet to the destination from that source. Oh, yes, of course, that's what I intended to mean. 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 Fri Jun 28 07:43:15 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5SEhEk7011579; Fri, 28 Jun 2002 07:43:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5SEhEOi011578; Fri, 28 Jun 2002 07:43:14 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5SEhBk7011571 for ; Fri, 28 Jun 2002 07:43:11 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA20285 for ; Fri, 28 Jun 2002 07:43:16 -0700 (PDT) Received: from roam.psg.com ([147.28.4.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA11064 for ; Fri, 28 Jun 2002 08:43:15 -0600 (MDT) Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17Nwxm-000A5J-00; Fri, 28 Jun 2002 07:43:06 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: Pekka Savola , itojun@iijlab.net, Thomas Narten , Subject: Re: IESG comments on draft-ietf-ipngwg-icmp-name-lookups-09.txt References: Message-Id: Date: Fri, 28 Jun 2002 07:43:06 -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > In my understanding, draft-ietf-dnsop-inaddr-required-03.txt is based > on some consensus in the dnsop group, i fear the draft does not have wg consensus, at least not yet, and it has been a while. randy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 28 08:43:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5SFhnk7011879; Fri, 28 Jun 2002 08:43:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5SFhnVY011878; Fri, 28 Jun 2002 08:43:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5SFhjk7011871 for ; Fri, 28 Jun 2002 08:43:45 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA10370 for ; Fri, 28 Jun 2002 08:43:47 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA23608 for ; Fri, 28 Jun 2002 09:43:46 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5SFcZ224602; Fri, 28 Jun 2002 11:38:35 -0400 (EDT) Message-Id: <200206281538.g5SFcZ224602@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Robert Elz cc: Keith Moore , "Tony Hain" , "Michel Py" , "Ralph Droms" , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-reply-to: (Your message of "Fri, 28 Jun 2002 21:19:04 +0700.") <15750.1025273944@munnari.OZ.AU> Date: Fri, 28 Jun 2002 11:38:34 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > | and the problems are inherent in DNS itself - > > I don't agree with that at all. Nothing requires a DNS lookup to take > a long time, the vast majority of them don't. If one takes a long time, > that indicates a configuration problem of some kind, which can and should > be corrected. I don't think that's true - at least, I don't know of any way to configure DNS so that a client knows to avoid querying zone servers that are unreachable due to network congestion or failed links. Granted, there are many DNS failures for which I've never found an explanation. But the lack of tracability in DNS means it's hard to track down such things - e.g. when an app gets a bogus "no such host" indication, who is responsible? That, and the lack of fate-sharing almost inherently means that an app that relies on DNS is less reliable than one that doesn't need DNS. > To the degree that isn't happening, the only explanation I > can think of is that people simply don't care enough. or peharps you're not thinking enough? :) > The problem that does exist is that app designers (and app protocol designers) > aren't the ones who get to fix the problems - and rather than simply > insisting that things be fixed for the app to work properly, they're > working around the problem by just not using DNS names. That's a bit like app designers insisting that NATs go away. App designers have to deal with whatever environment their customers have. It's our job as architects and engineers to encourage customers to set up reasonable environments and to give them mechanisms that allow them to do so. But it's NOT reasonable to insist that everything go through DNS. DNS is simply too slow and too inherently unreliable to be used for all purposes. The reliability can probably be improved somewhat, and we should certainly try to do that. But DNS names will never replace IP addresses for use in application referrals. And if anything is going to replace IP addresses for such purposes, it needs to be structured very differently from DNS, both in how translation is done and in how the mapping information is propagated. > > | the degree to which it is federated and distributed, > > none of that need cause excessive delays. > > | that and the names don't mean what you think they mean > > That indicates configuration problems too. No, it just means that not everybody shares the same idea as to how (or when) DNS should be used. > | - and in a network that has differences > | in link bandwidths (and delays) ranging several orders of magnitude - > | to say nothing of varying load and packet loss rates. > > All that will affect all parts of an app's performance, not just the > DNS part. If anything, the DNS can overcome those kinds of problems > (I've been doing it for years) by simply making a local replicated copy > any part of the DNS database where normal access causes problems. Expecting ordinary users to do this seems like a stretch > But even without that, the DNS isn't (or shouldn't) be causing more > suffering (for its one occasional lookup every now and then before > local caching works) than all of the normal packets that are being > delayed, lost, ... The reason this analysis fails is that the DNS lookups don't necessarily share the same links or servers as the ones that are critical to the app. DNS burdens the app with additional points of failure. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 28 09:15:43 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5SGFgk7011982; Fri, 28 Jun 2002 09:15:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5SGFgbN011981; Fri, 28 Jun 2002 09:15:42 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5SGFck7011974 for ; Fri, 28 Jun 2002 09:15:38 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA21656 for ; Fri, 28 Jun 2002 09:15:44 -0700 (PDT) Received: from tndh.net (evrtwa1-ar8-4-65-028-011.evrtwa1.dsl-verizon.net [4.65.28.11]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA28459 for ; Fri, 28 Jun 2002 10:15:43 -0600 (MDT) Received: from eagleswings (127.0.0.1) by localhost (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Fri, 28 Jun 2002 09:16:42 -0700 From: "Tony Hain" To: "Robert Elz" Cc: , "Michel Py" , "Ralph Droms" , Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols Date: Fri, 28 Jun 2002 09:13:27 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <13008.1025251454@munnari.OZ.AU> Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert Elz wrote: > ... > This all depends upon the frame of reference for "ambiouous". You're > agreeing that addresses should be unambiguous from a particular point > of reference. Keith wants addresses to be unambiguous from any point > of reference - in particular, so an app can send an address from one > node to another, without having to worry about whether it > will mean the > same thing when it arrives as it dopes when it was sent. and my point was that even if he sends an address that has a globally consistent meaning, if there is no route why bother? Lets use the following example: | | A -|-- B --|- C | | SL | SL&G | Global What Keith is asking for is that B should be able to tell C about the SL for A because A doesn't have a global address. If there is no global address for A, how will C get packets to it, even if the address it gets is unique? If the argument is that the network for B could leak the routes for A into the SP for C; 1) is the site policy for A being violated by advertising it? 2) more likely, is the SP policy for C being violated because A is not directly attached? 3) how does the app on B know that the route leak has occured and C has a route to A, particularly since it knows it doesn't have a SL address for C? 4) how does the app on B know that A has a route to C, particularly since it knows it doesn't have a global address for A? This is simply a broken model for an app. Yes it would be nicer for the app if the boundaries didn't exist, but A is not connected to the public net for a specific policy reason, and wishing that B could work around that is simply a waste of time. Global uniqueness in the SL space doesn't solve any of the above problems. It is more likely to cause people who don't understand routing to try it & fail, than actually help make apps work. As long as A & B have an unambiguous SL space between them, apps that stay in the SL context will work, and it will be clear to B that A can't possibly participate at the same time as C. If we confuse the world by making it so that it will *sometimes* be possible for A to talk to C, we will spend more time explaining why it almost never works than it was worth for the few cases where it does. > > My take on that is that limited scope addresses simply > shouldn't be used > that way - it may be true that using DNS names as a reference to ship > around isn't good enough (personally, I'm not convinced that if it > ever became important they wouldn't be good enough - most of > the reported > problems are due to laziness or poor knowledge, which affect anything > when there's no incentive to do better). > > But I see no reason not to ship around only known global addresses > (ones expected to be globally reachable), and then allow apps > that desire > to use more limited scope addresses to discover the limited > scope address > from the global. That will fail if one of the sites only has SL's. The result you are looking for is that an app will not ship around mixed scope addresses. If B ends up in the above example where it only has a SL for A and only a global for C, IT SHOULD NOT SEND ADDRESSES, period. If it has a SL for all the participants, it should use those because the app is more likely to stay intact if one of the participant sites is changing its public prefix. Outside of that I agree that if any of the participants doesn't have a SL, the app should only use globals. > > Incidentally - this also relates to your comment's on the > icmp-name-lookups > draft ... > > It > also doesn't make any sense to use a mechansim that is > clearly getting > packets to the dst node to ask it for other addresses > that might be used > to get packets to it. THe only possible use I can see > would be to allow > shifting to a different pair for route selection reasons, > > Another possible use is to shift to a different pair, of a > different scope > (not caring about the routing used in the slightest). That > is, you ask > the global addr to return you the site local addresses. I agree this could happen, but passing smaller scope addresses in a larger scope ICMP seems like a bad idea. I don't like the idea of equal or larger scope addresses being passed, but at least they should be able to deliver packets. The real problem is that smaller scope addresses will fail to work more often than not. Again, provide a name and let the resolution of that name in local context provide meaningful addresses. > > As long as it is obvious on the face of it what is a global address, > and what is limited scope (which matching fe80::/9 tells us > now), having > apps only tell others about global addresses, and never > passing off a SL > addr to another app looks real easy to me. > > The only requirement is that a global address actually exists to use. Since this is the problem for the disconnected site, the requirement needs to be that an app never passes around mixed scope addresses. Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 28 11:19:29 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5SIJTk7012619; Fri, 28 Jun 2002 11:19:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5SIJTFM012618; Fri, 28 Jun 2002 11:19:29 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5SIJPk7012611 for ; Fri, 28 Jun 2002 11:19:25 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA11565 for ; Fri, 28 Jun 2002 11:19:30 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA19979 for ; Fri, 28 Jun 2002 12:19:29 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5SIE8212054; Fri, 28 Jun 2002 14:14:09 -0400 (EDT) Message-Id: <200206281814.g5SIE8212054@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Tony Hain" cc: "Robert Elz" , moore@cs.utk.edu, "Michel Py" , "Ralph Droms" , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-reply-to: (Your message of "Fri, 28 Jun 2002 09:13:27 PDT.") Date: Fri, 28 Jun 2002 14:14:08 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > This all depends upon the frame of reference for "ambiouous". You're > > agreeing that addresses should be unambiguous from a particular point > > of reference. Keith wants addresses to be unambiguous from any point > > of reference - in particular, so an app can send an address from one > > node to another, without having to worry about whether it > > will mean the > > same thing when it arrives as it dopes when it was sent. > > and my point was that even if he sends an address that has a globally > consistent meaning, if there is no route why bother? if there's no route then it really doesn't matter, because the app couldn't function anyway. > Lets use the > following example: > | | > A -|-- B --|- C > | | > SL | SL&G | Global > > What Keith is asking for is that B should be able to tell C about the SL > for A because A doesn't have a global address. B has no way of knowing whether or not there is a route from A to C. But if there *is* a route from A to C, then there needs to be a an address for A that B can give to C, even if A is not connected to the public Internet. > If there is no global > address for A, how will C get packets to it, even if the address it gets > is unique? If A and C have a private interconnection, then the packets can get there. Not all interconnection is through the public Internet. > If the argument is that the network for B could leak the > routes for A into the SP for C; > 1) is the site policy for A being violated by advertising it? there's no way for the app to know the site policy, so it's a moot question. > 2) more likely, is the SP policy for C being violated because A is not > directly attached? also moot, for the same reason. > 3) how does the app on B know that the route leak has occured and C has > a route to A, particularly since it knows it doesn't have a SL address > for C? why do you assume a route leak? It's entirely possible for A and C to have a legitimate signal path between them even if one or neither is connected to the public internet. > 4) how does the app on B know that A has a route to C, particularly > since it knows it doesn't have a global address for A? A's SL might or might not be valid for C. B doesn't know whether or not A and C are part of the same 'site'. > This is simply a broken model for an app. well, duh. > Yes it would be nicer for the > app if the boundaries didn't exist, but A is not connected to the public > net for a specific policy reason, and wishing that B could work around > that is simply a waste of time. There's no presumption that B is routing traffic from A to C. Rather B is an app that is forced to live in a world where it is trying to communicate with multiple peers, or maybe even coordinate activities among multiple peers, where some of its peers are connected to the public Internet and some are not. B cannot be expected to have any idea which peers can talk to which other peers, or for that matter, which peers' addresses are valid in which other peers' addressing realms, because we've forced apps to deal with ambiguous addresses. At least if we make it possible for everyone to have unambiguous addresses then we can plausibly impose the contraint on apps that they should only use unambiguous addresses in referrals. B still won't be able to tell whether A and C can communicate directly, but at least it can give C an address for A which is unambiguous, and which allows C to *quickly* determine whether it can talk to A. > Global uniqueness in the SL space > doesn't solve any of the above problems. forget about SL space for the moment because it's confusing the issue. if you give A a globally unique address, then C can make some sense of it. if you force A to have an ambiguous address, then C can't tell whether A is unreachable, or whether A's address is simply not valid. > As long as A & B have an unambiguous SL space between > them, apps that stay in the SL context will work, and it will be clear > to B that A can't possibly participate at the same time as C. the notion of "SL context" is a network-centric view. apps don't have any idea about such contexts. apps and hosts have to cope with overlapping network contexts and interfaces on multiple networks that are in different contexts. app cannot be expected to stay within some invisible network context; actually quite often apps are expected to work across such boundaries. > If we > confuse the world by making it so that it will *sometimes* be possible > for A to talk to C, we will spend more time explaining why it almost > never works than it was worth for the few cases where it does. we're already in a world where it is *sometimes* possible for A to talk to C, and we have been ever since firewalls were invented. since firewalls aren't going to go away anytime soon, apps have to deal with the possibility that traffic is administratively prohibited. the only questions are whether we want to impose additional barriers by preventing private networks from having unambiguous addresses when they talk to other networks, and by making it difficult for apps to determine whether they actually talk to one another due to the fact that their addresses are ambiguous. > That will fail if one of the sites only has SL's. The result you are > looking for is that an app will not ship around mixed scope addresses. > If B ends up in the above example where it only has a SL for A and only > a global for C, IT SHOULD NOT SEND ADDRESSES, period. wrong. B has no idea whether A's SL address is valid for C. it might be obvious from looking at the drawing that C cannot use the SL address for A, but it's not obvious to B from the information available to it. now you could argue that A should never send out an SL address in a referral. and if we made it so that it were always possible for A to get an unambiguous address (or for A's network to provide A with an unambiguous address), I'd agree with you. however in the current architecture, such an argument is untenable. > If it has a SL for > all the participants, it should use those because the app is more likely > to stay intact if one of the participant sites is changing its public > prefix. no. B doesn't know whether A's SL is valid for C, even if both A and C have SL addresses. They could be from different realms. > Since this is the problem for the disconnected site, the requirement > needs to be that an app never passes around mixed scope addresses. I don't know what a "mixed scope" address is. But as long as we expect hosts to be able to use ambiguous addresses for anything other than very specific and limited purposes, apps *will* pass them around, and people *will* expect those apps to work. The requirement should be that every network can get globally-unique addresses for each of its hosts, and that it's free to interconnect using those addresses with any other network that will agree to connect to it. That way, every host and app that needs one can get a globally unique address, and apps can then be discouraged from using ambiguous addresses. It doesn't mean that every app can route traffic to any other potential peer that it knows about, but that's a given. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 28 11:26:06 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5SIQ6k7012678; Fri, 28 Jun 2002 11:26:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5SIQ6sG012677; Fri, 28 Jun 2002 11:26:06 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5SIQ2k7012670 for ; Fri, 28 Jun 2002 11:26:02 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA21466 for ; Fri, 28 Jun 2002 11:26:08 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA20645 for ; Fri, 28 Jun 2002 12:26:07 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA08149; Fri, 28 Jun 2002 11:25:51 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g5SIPpA28610; Fri, 28 Jun 2002 11:25:51 -0700 X-mProtect: <200206281825> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (4.22.78.78, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpd7bnZWN; Fri, 28 Jun 2002 11:25:49 PDT Message-Id: <4.3.2.7.2.20020628111514.02b814d8@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 28 Jun 2002 11:25:38 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: Request for Agenda Items for IETF 54 IPv6 Sessions Cc: hinden@iprg.nokia.com, deering@cisco.com, mrw@windriver.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IPv6 working group has been scheduled for two sessions at the Yokohama IETF. They are: THURSDAY, July 18, 2002, 0900-1130, Room 301/302 THURSDAY, July 18, 2002, 1300-1500, Room 301/302 Note that these date and times are subject to change by the IETF secretariat. Please send the chairs requests for agenda items. When we put together the agenda we plan to give priority to items that are urgent for IPv6 deployment, completing current work, longer term w.g. goals, new individual submissions, and last to status reports. Thanks, Bob Hinden / Steve Deering / Margaret Wasserman IPv6 Chairs -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 28 12:51:04 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5SJp4k7012971; Fri, 28 Jun 2002 12:51:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5SJp44p012970; Fri, 28 Jun 2002 12:51:04 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5SJp1k7012963 for ; Fri, 28 Jun 2002 12:51:01 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA25402 for ; Fri, 28 Jun 2002 12:51:07 -0700 (PDT) Received: from tndh.net (evrtwa1-ar8-4-65-028-011.evrtwa1.dsl-verizon.net [4.65.28.11]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA05731 for ; Fri, 28 Jun 2002 13:51:06 -0600 (MDT) Received: from eagleswings (127.0.0.1) by localhost (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Fri, 28 Jun 2002 12:52:09 -0700 From: "Tony Hain" To: Cc: "Robert Elz" , "Michel Py" , "Ralph Droms" , Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols Date: Fri, 28 Jun 2002 12:48:51 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <200206281814.g5SIE8212054@astro.cs.utk.edu> Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith Moore wrote: > ... > > Lets use the > > following example: > > | | > > A -|-- B --|- C > > | | > > SL | SL&G | Global > > > > What Keith is asking for is that B should be able to tell C > about the SL > > for A because A doesn't have a global address. > > B has no way of knowing whether or not there is a route from A to C. In this example B knows the scopes don't match. > > But if there *is* a route from A to C, then there needs to be a an > address for A that B can give to C, even if A is not connected to the > public Internet. This is where we fundamentally disagree. If A is not connected to the public Internet, there is no 'NEED' for B to be able to tell C about it. The number of places where by intent a node is disconnected from the public Internet, yet might be able to interact with nodes on the public Internet and not in its local routing domain, is so small that it is both not worth solving, and creates more confusion than solutions. > > > If there is no global > > address for A, how will C get packets to it, even if the > address it gets > > is unique? > > If A and C have a private interconnection, then the packets > can get there. > Not all interconnection is through the public Internet. > > > If the argument is that the network for B could leak the > > routes for A into the SP for C; > > 1) is the site policy for A being violated by advertising it? > > there's no way for the app to know the site policy, so it's a > moot question. Then why is it passing around addresses? > > > 2) more likely, is the SP policy for C being violated > because A is not > > directly attached? > > also moot, for the same reason. > > > 3) how does the app on B know that the route leak has > occured and C has > > a route to A, particularly since it knows it doesn't have a > SL address > > for C? > > why do you assume a route leak? It's entirely possible for A and C > to have a legitimate signal path between them even if one or > neither is > connected to the public internet. > > > 4) how does the app on B know that A has a route to C, particularly > > since it knows it doesn't have a global address for A? > > A's SL might or might not be valid for C. This only happens when NAT is involved. > B doesn't know whether or not A and C are part of the same 'site'. > > > This is simply a broken model for an app. > > well, duh. > > > Yes it would be nicer for the > > app if the boundaries didn't exist, but A is not connected > to the public > > net for a specific policy reason, and wishing that B could > work around > > that is simply a waste of time. > > There's no presumption that B is routing traffic from A to C. Rather > B is an app that is forced to live in a world where it is trying to > communicate with multiple peers, or maybe even coordinate activities > among multiple peers, where some of its peers are connected to the > public Internet and some are not. B cannot be expected to have any > idea which peers can talk to which other peers, or for that matter, > which peers' addresses are valid in which other peers' > addressing realms, > because we've forced apps to deal with ambiguous addresses. Globally unique addresses don't solve any of these issues. I agree that unambiguous addresses in the context of routability is required. In the example, B knows the scopes don't match, so without route leaking it knows the two sides can't see each other. > > At least if we make it possible for everyone to have > unambiguous addresses > then we can plausibly impose the contraint on apps that they > should only > use unambiguous addresses in referrals. B still won't be able to tell > whether A and C can communicate directly, but at least it can > give C an > address for A which is unambiguous, and which allows C to > *quickly* determine > whether it can talk to A. The time it takes to determine reachability is the same, and global uniqueness will not change that. > > > Global uniqueness in the SL space > > doesn't solve any of the above problems. > > forget about SL space for the moment because it's confusing the issue. > if you give A a globally unique address, then C can make some > sense of it. > if you force A to have an ambiguous address, then C can't > tell whether > A is unreachable, or whether A's address is simply not valid. and the practical difference is? > > > As long as A & B have an unambiguous SL space between > > them, apps that stay in the SL context will work, and it > will be clear > > to B that A can't possibly participate at the same time as C. > > the notion of "SL context" is a network-centric view. apps don't have > any idea about such contexts. and rather than figure out how to give them such knowledge you are arguing to remove the mechanism. There is no requirement that any app use SL, just as there is no requirement for a network manager to announce them. If an app wanted to stay within the bounds of the local routing administration, restricting itself to SL would be the first step to accomplishing that. > apps and hosts have to cope with > overlapping network contexts and interfaces on multiple networks that > are in different contexts. app cannot be expected to stay > within some > invisible network context; actually quite often apps are expected to > work across such boundaries. All of the administratively created boundaries are there explicitly to prevent apps from working across them. If we remove NAT from the set by moving to IPv6, we are left with the case where some administrator has decided that apps should not arbitrarily work, but you are insisting on making that possible despite the administrator. > > > If we > > confuse the world by making it so that it will *sometimes* > be possible > > for A to talk to C, we will spend more time explaining why it almost > > never works than it was worth for the few cases where it does. > > we're already in a world where it is *sometimes* possible for > A to talk > to C, and we have been ever since firewalls were invented. > since firewalls > aren't going to go away anytime soon, apps have to deal with > the possibility > that traffic is administratively prohibited. the only > questions are whether > we want to impose additional barriers by preventing private networks > from having unambiguous addresses when they talk to other > networks, and > by making it difficult for apps to determine whether they > actually talk > to one another due to the fact that their addresses are ambiguous. If an address is ambiguous outside its realm of routability, who cares? Either the routing system has a unique entry for the node, so all the participants can get there, or the address is outside this realm of routability, and they wouldn't get there even if the address is unique. > > > That will fail if one of the sites only has SL's. The result you are > > looking for is that an app will not ship around mixed scope > addresses. > > If B ends up in the above example where it only has a SL > for A and only > > a global for C, IT SHOULD NOT SEND ADDRESSES, period. > > wrong. B has no idea whether A's SL address is valid for C. > it might be obvious from looking at the drawing that C cannot use > the SL address for A, but it's not obvious to B from the information > available to it. B knows that it only has a global for C and a SL for A, so it can't refer one to the other with any hope that the connection will actually work. > > now you could argue that A should never send out an SL address in > a referral. and if we made it so that it were always possible for > A to get an unambiguous address (or for A's network to provide A > with an unambiguous address), I'd agree with you. however in > the current architecture, such an argument is untenable. > > > If it has a SL for > > all the participants, it should use those because the app > is more likely > > to stay intact if one of the participant sites is changing > its public > > prefix. > > no. B doesn't know whether A's SL is valid for C, even if > both A and C have SL addresses. They could be from different > realms. As long as there is no NAT in the path, there is no way that routing would work if the SL for A, B, & C are from different realms. Assuming we add the ability for local management of site-ids, if A & C have a private connection the prefix A tells B would have to be the same as the one it tells C, or routing within A would fail to deliver the packets. At the same time, there is no reason that the disconnected sites of Q, R, & S couldn't use the same set of site-ids. > > > Since this is the problem for the disconnected site, the requirement > > needs to be that an app never passes around mixed scope addresses. > > I don't know what a "mixed scope" address is. Not clearly stated... an app should not pass around an address set unless all the scopes match. > But as long as we expect > hosts to be able to use ambiguous addresses for anything other than > very specific and limited purposes, apps *will* pass them around, > and people *will* expect those apps to work. > > The requirement should be that every network can get globally-unique > addresses for each of its hosts, and that it's free to interconnect > using those addresses with any other network that will agree > to connect > to it. That is a nice idea, and if we had a mechanism for PI addresses this would be possible. Help promote the need for PI, and stop trying to turn SL into PI. There is a need for both. > That way, every host and app that needs one can get a globally > unique address, and apps can then be discouraged from using ambiguous > addresses. It doesn't mean that every app can route traffic to > any other potential peer that it knows about, but that's a given. There are apps that don't want arbitrary global accessability, and this requirement would force them to have it anyway. Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 28 17:35:05 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5T0Z4k7013842; Fri, 28 Jun 2002 17:35:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5T0Z4tn013841; Fri, 28 Jun 2002 17:35:04 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5T0Z0k7013834 for ; Fri, 28 Jun 2002 17:35:00 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA28089 for ; Fri, 28 Jun 2002 17:35:05 -0700 (PDT) Received: from esunmail ([129.147.58.122]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA23255 for ; Fri, 28 Jun 2002 18:35:05 -0600 (MDT) Received: from xpa-fe2 ([129.147.58.121]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 0.3 (built May 13 2002)) with ESMTP id <0GYF00M9JYYFYO@edgemail1.Central.Sun.COM> for ipng@sunroof.eng.sun.com; Fri, 28 Jun 2002 18:35:05 -0600 (MDT) Received: from localhost ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 0.2 (built Apr 26 2002)) with ESMTPSA id <0GYF00IZ6YYEKR@mail.sun.net> for ipng@sunroof.eng.sun.com; Fri, 28 Jun 2002 18:35:03 -0600 (MDT) Date: Fri, 28 Jun 2002 17:35:01 -0700 From: Alain Durand Subject: Re: I-D ACTION:draft-ietf-ipv6-default-addr-select-08.txt In-reply-to: <4.2.2.20020628002926.02399570@mail.windriver.com> To: Margaret Wasserman , hinden@iprg.nokia.com, deering@cisco.com, Keith Moore Cc: ipng@sunroof.eng.sun.com Message-id: <0C47439E-8AF8-11D6-A4F4-00039376A6AA@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.482) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thursday, June 27, 2002, at 09:41 PM, Margaret Wasserman wrote: > The Default Address Selection document has been out for months, has > been reviewed several times by the WG, has undergone a WG last call and > has been reviewed by the IESG. It doesn't seem right to delay this > draft indefinitely waiting for another draft, especially when we haven't > been told about any specific problems that this draft will cause. > > If there are specific, technical objections to this draft, please state > them clearly on the mailing list. It would also be helpful to suggest > specific text changes to the draft. This will give others and > opportunity > to agree or disagree about whether the issues should block the > publication > of this draft. Margaret, Publishing this draft will have the effect to stop any further discussion on who should be responsible to make the choice of SL vs GL when both are available: is it a kernel function by default or an well understood application choice. I'm not sure about which is best at this point of the discussion. Keith has arguments that I would like to understand better. Too bad he couldn't publish a draft before the cut-off date... In particular, I would like to understand what would be the impact on applications that are not SL aware the day the site admin decides to turn on SL by publishing them in the internal view of the DNS... I'm not a SIP expert, so I may be wrong, but I'm worried about what will happen to a SIP gateway when all the sudden it will receive a request originating from Site Local scope for an external address? I'm concerned that the only API required by the draft is about reversing the public vs temporary rule and that nothing is require to enable applications to reverse the other rules. I will have much less concern if the draft was to be published as BCP, as it is easy to change if proven wrong. I'm concerned it would be more difficult to change in the Standard Track. So I have 2 suggestions: a) leave the text as it is but publish it as BCP. As there are things we do not clearly understand now, it would be easier to change later. b) or reverse rule 2 by default and require an API to enable application to request SL when available. - 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 Jun 28 18:56:59 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5T1uxk7013973; Fri, 28 Jun 2002 18:56:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5T1uxnS013972; Fri, 28 Jun 2002 18:56:59 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5T1utk7013965 for ; Fri, 28 Jun 2002 18:56:56 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA09964 for ; Fri, 28 Jun 2002 18:57:01 -0700 (PDT) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA13296 for ; Fri, 28 Jun 2002 18:57:01 -0700 (PDT) Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 28 Jun 2002 18:56:57 -0700 Message-ID: <2B81403386729140A3A899A8B39B046405E170@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Fwd: IPv6 Scoped Addresses and Routing Protocols Thread-Index: AcIefMeQrt4rmd2bTw+oRo3Nn0S4UgANq7Sw From: "Michel Py" To: "Robert Elz" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5T1uuk7013966 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I am waiting to see how this is going to be achieved. That is, > all of what you're promising in this message. So far, from what > I have seen, I don't see how it can be done. One of the drafts is ready http://arneill-py.sacramento.ca.us/ipv6mh/draft-py-mhap-01a.txt > But maybe there's something out there that I just don't > understand yet. Feel free to ask any questions you wish on ipv6mh. I have heard a lot of "it does not work" and none explaining why. > The aim is a /48 for everyone (who requests one), right? At this point the aim is at multihomers only. If successful, the scheme could be extended to everyone and / or /64s but I'd rather have a slow-start. > Yes, there could be a protocol, with all kinds of things. And it > can be turned off, or replaced, if it gets in the way. With a lot of work if it is built into the core of the protocol. > It isn't possible to enforce anything by relying upon protocols, > we have to depend upon agreements, and when appropriate "it is > the only possible way". I have to disagree with this. If by _design_ these geo prefixes are not in the global routing table, the only leaks could be because of configuration snafus. > The way we enforce aggregation now, isn't because there's some magic > in BGP that requires it, it is because we know of no other way to > make routing work. Now. > As long as that remains true, we don't have to create protocols > to enforce aggregation in IPv6 - it will just naturally be enforced, > because no-one can figure out how to not enforce it (nb: it doesn't > really matter if a few stray /48's or even /128's "pollute" the > global tables - remember the aim is to keep routing working, not to > enforce the rule just because it is a rule). If the assumption ("we > know no way") ceases to be true, then there's no reason at all that > what we currently consider to be non-routable addresses shouldn't > appear in the routing tables. Ie: as soon as it is possible to put > them there, any policy aimed at keeping them out no longer has a > purpose, and should be scrapped. I agree for the most part. However, what you are talking about more or less requires replacing BGP. Given the time it will take, we do need a solution in-between though. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 29 07:13:26 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5TEDPk7014880; Sat, 29 Jun 2002 07:13:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5TEDP9I014879; Sat, 29 Jun 2002 07:13:25 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5TEDMk7014872 for ; Sat, 29 Jun 2002 07:13:22 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA17204 for ; Sat, 29 Jun 2002 07:13:27 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA24017 for ; Sat, 29 Jun 2002 07:13:22 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g5TEDCa02627; Sat, 29 Jun 2002 16:13:12 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id QAA17277; Sat, 29 Jun 2002 16:13:12 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id g5TEDAGF094440; Sat, 29 Jun 2002 16:13:11 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200206291413.g5TEDAGF094440@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Bob Hinden cc: ipng@sunroof.eng.sun.com, deering@cisco.com, mrw@windriver.com Subject: Re: Request for Agenda Items for IETF 54 IPv6 Sessions In-reply-to: Your message of Fri, 28 Jun 2002 11:25:38 PDT. <4.3.2.7.2.20020628111514.02b814d8@mailhost.iprg.nokia.com> Date: Sat, 29 Jun 2002 16:13:10 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Please send the chairs requests for agenda items. => I'd really like to see a session about the DAD vs. DIIDD stuff. I don't believe we need a long discussion so I propose: - an introduction (5mn) by an impartial and good presenter (i.e., not me (:-), I propose a chairperson). - an as short as possible discussion (5mn) (we should accept only new arguments) finishing by a *decision*. - an action plan (5mn): how to confirm the decision, how to update the involved standard track documents, etc. This should *not* take more than 15mn! => I've submitted a new version of the IMEI-based IID draft. I believe we wasted our time at the last meeting so I have only one question: should be this document a WG one? (1mn in the status session to look at a consensus on yes/no/...). When we put together the agenda we plan to give priority to items that are urgent for IPv6 deployment, completing current work, longer term w.g. goals, new individual submissions, and last to status reports. => I strongly encourage items about prefix delegation for home sites because these are *urgent* for IPv6 deployment. Thanks Francis.Dupont@enst-bretagne.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 Jun 29 09:07:21 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5TG7Lk7015103; Sat, 29 Jun 2002 09:07:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5TG7LBH015102; Sat, 29 Jun 2002 09:07:21 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5TG7Hk7015095 for ; Sat, 29 Jun 2002 09:07:18 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA22511 for ; Sat, 29 Jun 2002 09:07:19 -0700 (PDT) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA22311 for ; Sat, 29 Jun 2002 10:07:18 -0600 (MDT) Subject: RE: Request for Agenda Items for IETF 54 IPv6 Sessions MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 29 Jun 2002 09:07:14 -0700 Message-ID: <2B81403386729140A3A899A8B39B046406C8C1@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Request for Agenda Items for IETF 54 IPv6 Sessions Thread-Index: AcIfd5P4gYXLXygxRd6NFWaYOLNlIgADzlEw From: "Michel Py" To: "Francis Dupont" , "Bob Hinden" Cc: , , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5TG7Ik7015096 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Francis, => Francis Dupont wrote: => I strongly encourage items about prefix delegation for => home sites because these are *urgent* for IPv6 deployment. I must have missed something. Can you develop this / post links? Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 29 09:17:58 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5TGHwk7015134; Sat, 29 Jun 2002 09:17:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5TGHvVx015133; Sat, 29 Jun 2002 09:17:57 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5TGHsk7015126 for ; Sat, 29 Jun 2002 09:17:54 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA03210 for ; Sat, 29 Jun 2002 09:18:00 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA24820 for ; Sat, 29 Jun 2002 10:17:59 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g5TGHma06778; Sat, 29 Jun 2002 18:17:48 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id SAA17814; Sat, 29 Jun 2002 18:17:48 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id g5TGHlGF095042; Sat, 29 Jun 2002 18:17:47 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200206291617.g5TGHlGF095042@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Michel Py" cc: "Bob Hinden" , ipng@sunroof.eng.sun.com, deering@cisco.com, mrw@windriver.com Subject: Re: Request for Agenda Items for IETF 54 IPv6 Sessions In-reply-to: Your message of Sat, 29 Jun 2002 09:07:14 PDT. <2B81403386729140A3A899A8B39B046406C8C1@server2000.arneill-py.sacramento.ca.us> Date: Sat, 29 Jun 2002 18:17:47 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: => Francis Dupont wrote: => I strongly encourage items about prefix delegation for => home sites because these are *urgent* for IPv6 deployment. I must have missed something. Can you develop this / post links? => today ISP which manages an IPv6 dialup service (i.e., its customers run "home sites") should allocate a /48 per connection but there is no available protocol to do this. It seems the only way is static delegation/configuration and this is very heavy and not scalable at all. So if you believe the "home site" case is important for IPv6 deployment, we have to solve many problems and the prefix delegation is the first one (and as this is a problem for both the ISP and its customers, its value/cost doubles :-). Regards Francis.Dupont@enst-bretagne.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 Jun 29 09:34:38 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5TGYck7015189; Sat, 29 Jun 2002 09:34:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5TGYbA9015188; Sat, 29 Jun 2002 09:34:37 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5TGYYk7015181 for ; Sat, 29 Jun 2002 09:34:34 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA27648 for ; Sat, 29 Jun 2002 09:34:41 -0700 (PDT) Received: from mail5.nc.rr.com (fe5.southeast.rr.com [24.93.67.52]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA14800 for ; Sat, 29 Jun 2002 10:34:40 -0600 (MDT) Received: from nc.rr.com ([24.162.252.183]) by mail5.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Sat, 29 Jun 2002 12:33:14 -0400 Message-ID: <3D1DE095.893959A0@nc.rr.com> Date: Sat, 29 Jun 2002 12:30:13 -0400 From: Brian Haberman X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Francis Dupont CC: Michel Py , Bob Hinden , ipng@sunroof.eng.sun.com, deering@cisco.com, mrw@windriver.com Subject: Re: Request for Agenda Items for IETF 54 IPv6 Sessions References: <200206291617.g5TGHlGF095042@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Francis, I agree that prefix delegation is important for the home sites. Unfortunately, I will not be at IETF 54 to discuss my prefix delegation work. If it becomes an agenda item, I will see about getting someone to participate for me. Regards, Brian Francis Dupont wrote: > > In your previous mail you wrote: > > => Francis Dupont wrote: > => I strongly encourage items about prefix delegation for > => home sites because these are *urgent* for IPv6 deployment. > > I must have missed something. Can you develop this / post links? > > => today ISP which manages an IPv6 dialup service (i.e., its customers > run "home sites") should allocate a /48 per connection but there is > no available protocol to do this. It seems the only way is static > delegation/configuration and this is very heavy and not scalable at all. > So if you believe the "home site" case is important for IPv6 deployment, > we have to solve many problems and the prefix delegation is the first one > (and as this is a problem for both the ISP and its customers, its value/cost > doubles :-). > > Regards > > Francis.Dupont@enst-bretagne.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 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 29 10:10:12 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5THACk7015258; Sat, 29 Jun 2002 10:10:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5THABoH015257; Sat, 29 Jun 2002 10:10:11 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5THA8k7015250 for ; Sat, 29 Jun 2002 10:10:08 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA09174 for ; Sat, 29 Jun 2002 10:10:15 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA06279 for ; Sat, 29 Jun 2002 10:10:14 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g5TH9xa08715; Sat, 29 Jun 2002 19:09:59 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id TAA18041; Sat, 29 Jun 2002 19:09:59 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id g5TH9wGF095382; Sat, 29 Jun 2002 19:09:58 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200206291709.g5TH9wGF095382@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Brian Haberman cc: Michel Py , Bob Hinden , ipng@sunroof.eng.sun.com, deering@cisco.com, mrw@windriver.com Subject: Re: Request for Agenda Items for IETF 54 IPv6 Sessions In-reply-to: Your message of Sat, 29 Jun 2002 12:30:13 EDT. <3D1DE095.893959A0@nc.rr.com> Date: Sat, 29 Jun 2002 19:09:58 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: I agree that prefix delegation is important for the home sites. Unfortunately, I will not be at IETF 54 to discuss my prefix delegation work. If it becomes an agenda item, I will see about getting someone to participate for me. => we had already the same problem for the extended RA solution. IMHO all ready proposals have to be defended even if the author is not available. The only really needed thing is a good minute taker, nobody else should be indispensable (:-)... So please ask for a slot and let the chairs to find some people to participate for you. Thanks Francis.Dupont@enst-bretagne.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 Sun Jun 30 07:43:19 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5UEhJk7016324; Sun, 30 Jun 2002 07:43:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5UEhIkb016323; Sun, 30 Jun 2002 07:43:18 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5UEhFk7016316 for ; Sun, 30 Jun 2002 07:43:15 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA01773 for ; Sun, 30 Jun 2002 07:43:21 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA15683 for ; Sun, 30 Jun 2002 08:43:16 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g5UEhBa18797; Sun, 30 Jun 2002 16:43:11 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id QAA21976; Sun, 30 Jun 2002 16:43:12 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id g5UEhBGF098779; Sun, 30 Jun 2002 16:43:11 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200206301443.g5UEhBGF098779@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Bob Hinden cc: ipng@sunroof.eng.sun.com Subject: Re: Consensus on Site-Local Discussion In-reply-to: Your message of Fri, 21 Jun 2002 08:29:02 PDT. <4.3.2.7.2.20020621082643.0261f930@mailhost.iprg.nokia.com> Date: Sun, 30 Jun 2002 16:43:11 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: The IPv6 working group chairs reading of the mailing list discussion regarding removing site-local addresses from the IPv6 architecture is that there is not a consensus to make this change. From the email discussion we also believe there is a consensus to not require IPv6 implementations to support connectivity to multiple sites. The suggestion made by Tim Hartrick on the list is a reasonable way to resolve the requirement level of site-local. Specifically: >What I would like to see come out of this long discussion is simply some text >in the in progress "Node Requirements" document that specifies how much of the >scoped address architecture MUST be implemented and that that text would say >that the rules specified in Draves' draft are the only MUST implement portion >of the architecture. There should be no requirement that a node be able to be >part of more than one zone. We believe the resulting actions from this discussion are: - No change to the IPv6 address architecture regarding site local - No change to the "Default Address Selection for IPv6" draft - Text to be added to the "IPv6 Node Requirements" draft as outlined by Tim Hartrick text (above). - The working group should complete the Scoped Address Architecture draft. Bob Hinden, Steve Deering, Margaret Wasserman IPv6 working group chairs => I officially support this consensus (modulo the default address selection document, I believe my opinion about it is already well-known). I congratulate the chairs on this attempt to clarify the site-local discussion. Thanks Francis.Dupont@enst-bretagne.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 Sun Jun 30 08:30:23 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5UFUMk7016381; Sun, 30 Jun 2002 08:30:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5UFUMuB016380; Sun, 30 Jun 2002 08:30:22 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5UFUJk7016373 for ; Sun, 30 Jun 2002 08:30:19 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA10465 for ; Sun, 30 Jun 2002 08:30:25 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA19309 for ; Sun, 30 Jun 2002 09:30:24 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g5UFTPa20018; Sun, 30 Jun 2002 17:29:25 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id RAA22110; Sun, 30 Jun 2002 17:29:25 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id g5UFTNGF099283; Sun, 30 Jun 2002 17:29:23 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200206301529.g5UFTNGF099283@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Alberto Escudero-Pascual cc: "Bound, Jim" , Erik Nordmark , Keith Moore , Thomas Narten , ipng@sunroof.eng.sun.com Subject: Re: IESG comments on draft-ietf-ipngwg-default-addr-select-06.txt In-reply-to: Your message of Thu, 13 Jun 2002 21:44:46 +0200. Date: Sun, 30 Jun 2002 17:29:23 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: If only the users that have concerns about privacy will end up using temp addresses (RFC3041) we will end up with a minority group of techno-geeks or as you call us 'paranoids' highly observable and easy to identify from the crowd. => as a hot defender of protocol 50 I don't follow you... I firmly beleive that RFC3041 should be the default option and only the nodes that require a fixed address should enable that option. 'Privacy' should be the default option. I don't want to be sorrounded by boxes with EUI-64 based addresses and be myself the only one running RFC3041. => in fact we have the choice between to keep the u/g bit stuff with consequences like RFC 3041 or just to throw this heritage of 8+8 (because now we know how to do a secure two-space system: HIP) and: - forget the universal bit - rely on DAD in order to avoid IID collisions - reduce IID size (32 bits are enough for common links) - weaken the IID to a host part etc. Perhaps this is too late but I'd like to see a sound opinion, i.e., not in the same time dreaming over adding some semantics to bits in IIDs and reject our IMEI based IID draft with spurious arguments (perhaps in Japan where there are tens of millions of phones with data services, i.e., a need for an universal IID registry, things will be a bit different :-). Regards Francis.Dupont@enst-bretagne.fr PS: my very personnal opinion is 64 bit IIDs are a huge waste of address space. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 30 08:37:23 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5UFbNk7016406; Sun, 30 Jun 2002 08:37:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5UFbMnl016405; Sun, 30 Jun 2002 08:37:22 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5UFbJk7016398 for ; Sun, 30 Jun 2002 08:37:19 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA21754 for ; Sun, 30 Jun 2002 08:37:26 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA15786 for ; Sun, 30 Jun 2002 09:37:25 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g5UFbFa20585; Sun, 30 Jun 2002 17:37:15 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id RAA22187; Sun, 30 Jun 2002 17:37:16 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id g5UFbFGF099315; Sun, 30 Jun 2002 17:37:15 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200206301537.g5UFbFGF099315@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Thomas Narten cc: ipng@sunroof.eng.sun.com Subject: Re: IESG followup on draft-ietf-ipv6-default-addr-select-07.txt In-reply-to: Your message of Thu, 13 Jun 2002 15:19:53 EDT. <200206131919.g5DJJri10087@rotala.raleigh.ibm.com> Date: Sun, 30 Jun 2002 17:37:15 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: The IESG had a telechat today and discussed the WG feedback on its request regarding draft-ietf-ipv6-default-addr-select-07.txt. Based on the feedback, the request to prefer temporary addresses over public addresses is withdrawn; leaving the default to prefer public addresses is OK. The IESG would still, however, like to see the following change made: An implementation MUST support a per-connection configuration mechanism (for example, an API extension) to reverse the sense of this preference and prefer temporary addresses over public addresses. => two concerns: - this is not the only point where one should get a way to change/reverse a preference. - the proposed way "per-connection configuration mechanism (for example, an API extension)" is not enough defined because: * nobody wants to change every applications in order to use this API if this API needs it (for instance, to add a set/getsockopt() doesn't come up to user expectations). * of course this API should be a bit standardized... More in another message because I can see a lot of answers to last draft announce in my not-yet-read mbox. Regards Francis.Dupont@enst-bretagne.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 Sun Jun 30 08:39:25 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5UFdPk7016435; Sun, 30 Jun 2002 08:39:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5UFdOTA016434; Sun, 30 Jun 2002 08:39:24 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5UFdLk7016427 for ; Sun, 30 Jun 2002 08:39:21 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA12325 for ; Sun, 30 Jun 2002 08:39:28 -0700 (PDT) Received: from byd.ocn.ad.jp (byd.ocn.ad.jp [203.139.162.147]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA03195 for ; Sun, 30 Jun 2002 09:39:27 -0600 (MDT) Received: from ty (byd.ocn.ad.jp [203.139.162.147]) by byd.ocn.ad.jp (8.8.8/3.6W) with SMTP id AAA18107; Mon, 1 Jul 2002 00:39:05 +0900 (JST) Message-ID: <014901c2204c$41cdb9c0$b4b57e3d@ty> From: "Toshi Yamasaki" To: "Francis Dupont" , "Bob Hinden" Cc: , , , , "Ole Troan" , References: <200206291413.g5TEDAGF094440@givry.rennes.enst-bretagne.fr> Subject: Re: Request for Agenda Items for IETF 54 IPv6 Sessions Date: Mon, 1 Jul 2002 00:25:23 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Yes, please! Shin has submitted the "requirements for ipv6 prefix delegation" draft, as his homework given by WG chairs at Minneapolis. http://www.ietf.org/internet-drafts/draft-miyakawa-ipv6-prefix-delegation-re quirement-00.txt This document is very simple, but describes very well minimum and urgent requirements of ISPs who want to start IPv6 access (DSL/FTTH) services tomorrow. ---Toshi Yamasaki / NTT Communications > I agree that prefix delegation is important for the home sites. > Unfortunately, I will not be at IETF 54 to discuss my prefix delegation > work. If it becomes an agenda item, I will see about getting someone > to participate for me. > > => we had already the same problem for the extended RA solution. > IMHO all ready proposals have to be defended even if the author is > not available. The only really needed thing is a good minute taker, > nobody else should be indispensable (:-)... > So please ask for a slot and let the chairs to find some people to > participate for you. > Title : Requirements for IPv6 prefix delegation > Author(s) : S. Miyakawa > Filename : draft-miyakawa-ipv6-prefix-delegation- > requirement-00.txt > Pages : 5 > Date : 25-Jun-02 > > This document describes requirements about how an IPv6 address prefix > should be delegated to an IPv6 subscriber's network (or 'site'). > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-miyakawa-ipv6-prefix-delegation-re quirement-00.txt > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jun 30 08:51:43 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5UFphk7016468; Sun, 30 Jun 2002 08:51:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5UFpgFO016467; Sun, 30 Jun 2002 08:51:42 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5UFpdk7016460 for ; Sun, 30 Jun 2002 08:51:39 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA17262 for ; Sun, 30 Jun 2002 08:51:45 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA02289 for ; Sun, 30 Jun 2002 08:51:45 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g5UFpMa20980; Sun, 30 Jun 2002 17:51:22 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id RAA22256; Sun, 30 Jun 2002 17:51:22 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id g5UFpKGF099490; Sun, 30 Jun 2002 17:51:20 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200206301551.g5UFpKGF099490@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Margaret Wasserman cc: ipng@sunroof.eng.sun.com, Robert Elz , Keith Moore , "Richard Draves" , Brian Carpenter Subject: Re: I-D ACTION:draft-ietf-ipv6-default-addr-select-08.txt In-reply-to: Your message of Tue, 25 Jun 2002 11:02:15 EDT. <4.2.2.20020625105324.021f7e50@mail.windriver.com> Date: Sun, 30 Jun 2002 17:51:20 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: The Default Address Selection draft is currently with IESG, waiting for approval for PS. There was clear consensus in the WG to send this document to the IESG, we held a WG last call, and it has since been updated based on IESG feedback. I have followed this discussion, and it is clear that one or two people object to the changes made based on IESG review. However, I don't see any WG consensus that there are problems with this document that should block its publication as a PS. Thoughts? => I repeat my strong objection: this document should not be on the standard track. I already explained why and the fact it was some years and versions ago should be a good proof I was right... I have some precise concerns about the last draft I'll develop in another message ASAP. Regards Francis.Dupont@enst-bretagne.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 Sun Jun 30 09:08:12 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5UG8Ck7016487; Sun, 30 Jun 2002 09:08:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5UG8Cau016486; Sun, 30 Jun 2002 09:08:12 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5UG88k7016479 for ; Sun, 30 Jun 2002 09:08:08 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA19674 for ; Sun, 30 Jun 2002 09:08:15 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA08010; Sun, 30 Jun 2002 09:08:14 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g5UG82a21481; Sun, 30 Jun 2002 18:08:02 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id SAA22316; Sun, 30 Jun 2002 18:08:03 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id g5UG82GF099549; Sun, 30 Jun 2002 18:08:02 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200206301608.g5UG82GF099549@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Brian E Carpenter cc: Margaret Wasserman , Alain Durand , Bob Hinden , Keith Moore , ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-ietf-ipv6-default-addr-select-08.txt In-reply-to: Your message of Fri, 28 Jun 2002 12:07:42 +0200. <3D1C356E.CDCDE1BD@hursley.ibm.com> Date: Sun, 30 Jun 2002 18:08:02 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: I think that at this point we should advance the document as it is. => this could be interpreted as an "in force" way to push the document... While I'm sympathetic to Keith's concerns, I think we have needed address selection *defaults* for a long time, and the default behaviour recommended for SLs is consistent and logical. => these problems are a direct consequence of the idea to put the whole stuff in the standard track. I was against this idea not because I disagree about some details but because of what has happened: a document reduced to the "MUSTs" had been a PS for years, and I don't want to imagine how the draft could reach the DS status... Defaults are made to be overridden, so the behaviour can always be adjusted. => to apply this argument you need a specification of an API (with a consensus), or (easier) just make a part of the document informational: Richard tries to get a near perfect document for a moving target, of course he failed. To make a PS which should be obsolete before to be published is not the proper solution. Regards Francis.Dupont@enst-bretagne.fr PS: last minute idea: s/informational/BCP/ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 30 09:18:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5UGIck7016510; Sun, 30 Jun 2002 09:18:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5UGIchQ016509; Sun, 30 Jun 2002 09:18:38 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5UGIZk7016502 for ; Sun, 30 Jun 2002 09:18:35 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA28095 for ; Sun, 30 Jun 2002 09:18:42 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA05369 for ; Sun, 30 Jun 2002 10:18:41 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g5UGHwa21700; Sun, 30 Jun 2002 18:17:58 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id SAA22364; Sun, 30 Jun 2002 18:17:58 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id g5UGHvGF099601; Sun, 30 Jun 2002 18:17:57 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200206301617.g5UGHvGF099601@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Alain Durand cc: Margaret Wasserman , hinden@iprg.nokia.com, deering@cisco.com, Keith Moore , ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-ietf-ipv6-default-addr-select-08.txt In-reply-to: Your message of Fri, 28 Jun 2002 17:35:01 PDT. <0C47439E-8AF8-11D6-A4F4-00039376A6AA@sun.com> Date: Sun, 30 Jun 2002 18:17:57 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Publishing this draft will have the effect to stop any further discussion on who should be responsible to make the choice of SL vs GL when both are available: is it a kernel function by default or an well understood application choice. => I don't think so: the effect will that the document will become obsolete at the first well argumented message about the SL vs GL or any other open questions... I'm concerned that the only API required by the draft is about reversing the public vs temporary rule and that nothing is require to enable applications to reverse the other rules. => this is in fact a bad idea because it makes the value of the draft relied on a vague API idea, something not well suited for a standard track document. I will have much less concern if the draft was to be published as BCP, as it is easy to change if proven wrong. I'm concerned it would be more difficult to change in the Standard Track. => I've said the same thing for years. IT IS TIME TO STOP THIS INFERNAL LOOP! So I have 2 suggestions: a) leave the text as it is but publish it as BCP. As there are things we do not clearly understand now, it would be easier to change later. => MUSTs, i.e., things which must be done this way because all other ways don't work, can stay in a standard track document. All other things should be moved to a BCP, and both published ASAP. b) or reverse rule 2 by default and require an API to enable application to request SL when available. => this is not enough because there are other arguable points. Worse, I believe there will be new arguable points, as IPv6 is not fixed. Thanks Francis.Dupont@enst-bretagne.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 Sun Jun 30 10:29:06 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5UHT6k7016593; Sun, 30 Jun 2002 10:29:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5UHT5BM016592; Sun, 30 Jun 2002 10:29:05 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5UHT2k7016585 for ; Sun, 30 Jun 2002 10:29:02 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA01450 for ; Sun, 30 Jun 2002 10:29:08 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA00504 for ; Sun, 30 Jun 2002 10:29:07 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g5UHSxa23294; Sun, 30 Jun 2002 19:28:59 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id TAA22635; Sun, 30 Jun 2002 19:29:00 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id g5UHSxGF099731; Sun, 30 Jun 2002 19:28:59 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200206301728.g5UHSxGF099731@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Richard Draves" cc: ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-ietf-ipv6-default-addr-select-08.txt In-reply-to: Your message of Thu, 20 Jun 2002 16:22:26 PDT. <7695E2F6903F7A41961F8CF888D87EA8063CED6A@red-msg-06.redmond.corp.microsoft.com> Date: Sun, 30 Jun 2002 19:28:59 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: => I already explained my opinion about this draft (spit it: MUSTs in standard track, anything else in a BCP), site-locals, RFC 3041 addresses (cf draft-dupont-ipv6-rfc3041harmful-xx.txt), etc. 2. I changed the requirement for an API to control temporary vs public address usage, from "may" to "MUST". The new text reads An implementation MUST support a per-connection configuration mechanism (for example, a socket option) to reverse the sense of this preference and prefer temporary addresses over public addresses. The default is still to use public addresses not temporary addresses, although implementations MAY reverse this default if they want to emphasize privacy over application compatibility. => this doesn't work as explained in this list. Comments over draft-ietf-ipv6-default-addr-select-08.txt: This document also specifies policy hooks to allow administrative override of the default behavior. For example, using these hooks an administrator can specify a preferred source prefix for use with a destination prefix, or prefer destination addresses with one prefix over addresses with another prefix. These hooks give an administrator flexibility in dealing with some multi-homing and transition scenarios, but they are certainly not a panacea. => this is not enough because some rules should be reversed/modulated too (for instance the rules S4, S7 and D8). Another problem is you give only the choice between a global policy and a setsockopt() when we need on a multi-user box: - a global policy/swith - a setsockopt() (i.e., explicit and per-application) - an environment based way to change a policy or a switch. IMHO the last option is enough because: - the environment is inherited from a default - an application can manipulate its own environment. For multicast and link-local destination addresses, the set of candidate source addresses MUST only include addresses assigned to interfaces belonging to the same link as the outgoing interface. In any case, anycast addresses, multicast addresses, and the unspecified address MUST NOT be included in a candidate set. If an application or upper-layer specifies a source address that is not in the candidate set for the destination, then the network layer MUST treat this as an error. => please change the MUST NOT in a SHOULD NOT for the unspecified source address or RFC 2462 doesn't work (:: is the only fallback when the candidate source address set is empty). IMHO some words about tentative addresses (not valid candidates) should be added. Rule 4: Prefer home addresses. If SA is simultaneously a home address and care-of address and SB is not, then prefer SA. Similarly, if SB is simultaneously a home address and care-of address and SA is not, then prefer SB. If SA is just a home address and SB is just a care-of address, then prefer SA. Similarly, if SB is just a home address and SA is just a care-of address, then prefer SB. => this is the right thing only for a common case, i.e., things are not so simple. For instance if mobile IPv6 is used in a nomadic context (i.e., the mobile will never move), source home address should be prefered only for destination addresses in the home site. The order of the rules S4 and S5 is arguable, and the fact a home address is not really bound to a physical interface (in fact this is an open question) doesn't make things easier. An implementation may support a per-connection configuration mechanism (for example, a socket option) to reverse the sense of this preference and prefer care-of addresses over home addresses. => this is clearly inadequate, at least because this assumes that all involved applications are upgraded... Rule 6: Prefer matching label. If Label(SA) = Label(D) and Label(SB) <> Label(D), then prefer SA. Similarly, if Label(SB) = Label(D) and Label(SA) <> Label(D), then prefer SB. => as this is the only rule I can play with on my KAME box, I'd like to see what happen if it is moved just after the rule S3? In fact, I don't know what is the best order for rule S4, S5 and S6. Same for D4 vs. D5+D6. Rule 7: Prefer public addresses. If SA is a public address and SB is a temporary address, then prefer SA. Similarly, if SB is a public address and SA is a temporary address, then prefer SB. => even if I believe this is the right choice I don't know there is a strong consensus. An implementation MUST support a per-connection configuration mechanism (for example, a socket option) to reverse the sense of this preference and prefer temporary addresses over public addresses. => again this is inadequate and stresses the previous issue. This MUST must not move to the standard track part. Note my environment suggestion works well for this case because daemons (which want the public address) run with another userID than applications of physical users (which want a temporary address). We really need soemthing tunable from the outside, not a new switch in every applications... Rule 8: Use longest matching prefix. If CommonPrefixLen(SA, D) > CommonPrefixLen(SB, D), then prefer SA. Similarly, if CommonPrefixLen(SB, D) > CommonPrefixLen(SA, D), then prefer SB. => this rule has no meaning when CommonPrefixLen is not bound to 0..64. Rule 4: Prefer home addresses. If Source(DA) is simultaneously a home address and care-of address and Source(DB) is not, then prefer DA. Similarly, if Source(DB) is simultaneously a home address and care-of address and Source(DA) is not, then prefer DB. If Source(DA) is just a home address and Source(DB) is just a care- of address, then prefer DA. Similarly, if Source(DA) is just a care- of address and Source(DB) is just a home address, then prefer DB. => same comment than for S4. Rule 8: Prefer smaller scope. If Scope(DA) < Scope(DB), then prefer DA. Similarly, if Scope(DA) > Scope(DB), then prefer DB. => this is the typical rule I'd like to reverse! (BTW are there common cases where D8 is not overruled by D6 for not twisted policy tables?) Rule 9: Use longest matching prefix. When DA and DB belong to the same address family (both are IPv6 or both are IPv4): If CommonPrefixLen(DA, Source(DA)) > CommonPrefixLen(DB, Source(DB)), then prefer DA. Similarly, if CommonPrefixLen(DA, Source(DA)) < CommonPrefixLen(DB, Source(DB)), then prefer DB. => same comment than for S8. Of course, as they are specified today D9 and S7 have funny interactions. Regards Francis.Dupont@enst-bretagne.fr PS: about KAME implementation, what about: - move the policy table rules just after the common sense rules - put the policy table in a per-process space (u-area)? - limit in6_matchlen() to 64 for address selection. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 30 16:33:54 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5UNXrk7016977; Sun, 30 Jun 2002 16:33:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5UNXr6x016976; Sun, 30 Jun 2002 16:33:53 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5UNXnk7016969 for ; Sun, 30 Jun 2002 16:33:49 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA25193 for ; Sun, 30 Jun 2002 16:33:53 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA24598 for ; Sun, 30 Jun 2002 16:33:52 -0700 (PDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5UNSU221519; Sun, 30 Jun 2002 19:28:33 -0400 (EDT) Message-Id: <200206302328.g5UNSU221519@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Tony Hain" cc: moore@cs.utk.edu, "Robert Elz" , "Michel Py" , "Ralph Droms" , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-reply-to: (Your message of "Fri, 28 Jun 2002 12:48:51 PDT.") Date: Sun, 30 Jun 2002 19:28:30 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Keith Moore wrote: > > ... > > > Lets use the > > > following example: > > > | | > > > A -|-- B --|- C > > > | | > > > SL | SL&G | Global > > > > > > What Keith is asking for is that B should be able to tell C > > about the SL > > > for A because A doesn't have a global address. > > > > B has no way of knowing whether or not there is a route from A to C. > > In this example B knows the scopes don't match. so what? the fact that A used a limited-scope address to talk to B doesn't doesn't tell B anything about whether A and C can communicate directly. B knows nothing, absolutely nothing, about the network connectivity between A and C and there's absolutely no way B can make *any* inferences about connectivity by looking at any set of A's and C's addresses. furthermore, there's nothing that any address selection rule can do to change this situation. > > But if there *is* a route from A to C, then there needs to be a an > > address for A that B can give to C, even if A is not connected to the > > public Internet. > > This is where we fundamentally disagree. If A is not connected to the > public Internet, there is no 'NEED' for B to be able to tell C about it. that's insane. what you're saying is that we don't need to care about whether applications can interoperate if their hosts aren't all connected to the public internet. the bottom line is that people need apps that work even when all of their hosts aren't connected to the public internet, and the burden is going to be on apps to make this work whether you think it's reasonable or not. our only choice is to decide whether we're going to force those apps to be less reliable by burdening them with ambiguous addresses. > The number of places where by intent a node is disconnected from the > public Internet, yet might be able to interact with nodes on the public > Internet and not in its local routing domain, is so small that it is > both not worth solving, and creates more confusion than solutions. try again. there are lots of private enterprise networks today that are interconnected by NATs whether or not there is any connection (via a NAT) to the public Internet, and there are lots of apps that have to run on spaces where public and private networks overlap - essentially every enterprise network today has apps that run in an environment like this. are you saying you're going to make it as difficult (or worse) for those apps to use v6 as v4+NAT? I don't think that's a viable option. > > > If the argument is that the network for B could leak the > > > routes for A into the SP for C; > > > 1) is the site policy for A being violated by advertising it? > > > > there's no way for the app to know the site policy, so it's a > > moot question. > > Then why is it passing around addresses? you may as well ask why DNS passes around addresses. DNS isn't aware of the policy either, and even though 2-faced DNS attempts to limit exposure of addresses that aren't usable there's no way the DNS server can know who gets those addresses and whether they're authorized to talk to ports on those hosts. bottom line is just because you get an address from DNS or anywhere else doesn't mean for certain that you can actually send traffic to it. > > > 4) how does the app on B know that A has a route to C, particularly > > > since it knows it doesn't have a global address for A? > > > > A's SL might or might not be valid for C. > > This only happens when NAT is involved. NO, Tony. It's possible for A and C to be in different sites, even though B can talk to both of them. It's also possible for them to be in the same site, even though B has a SL address for one and a global addres for the other. > > There's no presumption that B is routing traffic from A to C. Rather > > B is an app that is forced to live in a world where it is trying to > > communicate with multiple peers, or maybe even coordinate activities > > among multiple peers, where some of its peers are connected to the > > public Internet and some are not. B cannot be expected to have any > > idea which peers can talk to which other peers, or for that matter, > > which peers' addresses are valid in which other peers' > > addressing realms, > > because we've forced apps to deal with ambiguous addresses. > > Globally unique addresses don't solve any of these issues. globally unique addresses are not a complete solution - there is no complete solution. but they minimize the potential for some errors and make it easier to quickly detect other conditions that prevent an address pair from being used, and thus make it easier for applications to recover quickly from those conditions. e.g. it's much better to get an ICMP unreachable when trying to send to an address than to have to wait for a timeout. > I agree that > unambiguous addresses in the context of routability is required. In the > example, B knows the scopes don't match, so without route leaking it > knows the two sides can't see each other. no it doesn't because B has no way of knowing whether it has *all* of the addresses for both A and C, and nothing can be inferred from the fact that A chose a SL address for B and C chose a global address for B. especially when different connections (sometimes even within the same app) have different needs that quite reasonably affect address selection, and when network connectivity can vary from one time to the next and at different places in the network at the same time. > > At least if we make it possible for everyone to have > > unambiguous addresses > > then we can plausibly impose the contraint on apps that they > > should only > > use unambiguous addresses in referrals. B still won't be able to tell > > whether A and C can communicate directly, but at least it can > > give C an > > address for A which is unambiguous, and which allows C to > > *quickly* determine > > whether it can talk to A. > > The time it takes to determine reachability is the same, and global > uniqueness will not change that. I don't think so. with an unambiguous/global address the router knows whether or not it has a route to the destination, and can issue an unreachable ICMP immediately if this is not the case. with an ambiguous address there may be a need to do routing (in the case of SL) and ND for a host that might not even be at that site, and the only indication that you can't reach that host is an ND timeout, which might or might not result in an ICMP message being sent back across routers after the timeout has expired. (often we don't get them in IPv4, so I don't expect we'll get them in IPv6 either...) of course if the destination is down you'll get the timeout in any case, but we assume that's a rare situation. the difference is that when trying to use SLs from a remote network you'll have to wait for a timeout anytime you're using a nonlocal SL - and the timeout tells the sender *no* information about whether the host is up or down. how often this happens is highly dependent on how your network is interconnected with others' and where your apps live relative to that topology. > > > > > Global uniqueness in the SL space > > > doesn't solve any of the above problems. > > > > forget about SL space for the moment because it's confusing the issue. > > if you give A a globally unique address, then C can make some > > sense of it. > > if you force A to have an ambiguous address, then C can't > > tell whether > > A is unreachable, or whether A's address is simply not valid. > > and the practical difference is? response time, overall reliability, and the effort/complexity that apps need to expend in trying to deal with multiple addresses, detecting errors, and recovering from errors. > > the notion of "SL context" is a network-centric view. apps don't have > > any idea about such contexts. > > and rather than figure out how to give them such knowledge you are > arguing to remove the mechanism. even asuming you can resonably teach apps about network topology (going against 20+ years of internet architecture), please explain how you are going to teach apps about network topology without giving them any way to determine which addresses are in which part of the network. it simply can't be done. you can beat your head against the wall as long as you want, but you won't get anywhere except a bruised head. this is what the NAT/RSIP/MIDCOM people have been trying to do and it's basically accomplished zilch except to serve as a demonstration on how utterly fruitless and futile that line of investigation is. > There is no requirement that any app > use SL, just as there is no requirement for a network manager to > announce them. If an app wanted to stay within the bounds of the local > routing administration, restricting itself to SL would be the first step > to accomplishing that. an app could restrict itself to SL, or it could restrict itself to not using SL. but users that try to use SL are going to wonder why they have to force their apps to live in one world or another. what this basically means is that SL has very limited utility, and that we need a mechanism that allows sites to have globally unique addresses whether or not they're connected to the public Internet. And once we have the better mechanism then SL should probably be discouraged so that apps don't have the burden of dealing with them. that doesn't mean that we have to try to eradicate SL from the face of the Earth, but it's certainly not clear why we should bother to support SL and the complexity that comes with it if we can solve the same problem via simpler and more reliable means. > > apps and hosts have to cope with > > overlapping network contexts and interfaces on multiple networks that > > are in different contexts. app cannot be expected to stay > > within some > > invisible network context; actually quite often apps are expected to > > work across such boundaries. > > All of the administratively created boundaries are there explicitly to > prevent apps from working across them. perhaps, but the boundaries aren't as clean as you want to pretend. the fact that B can talk to both A and C does not mean that direct communication between A and C is permitted. nor would the inability of either A or C to talk to B mean that communicaiton between A and C were forbidden. the only way to know if there's a boundary between A and C is for one of them to try to talk to the other. > If we remove NAT from the set by > moving to IPv6, we are left with the case where some administrator has > decided that apps should not arbitrarily work, but you are insisting on > making that possible despite the administrator. No. if the administrator doesn't want A and C to talk to each other then the administrator sets up a filter that blocks traffic between A and C (it could be either at A or at C or in between). the administrator doesn't necessarily tell B about it, B might not even been in that administrator's control, and there's no way for B to know that such a filter exists from looking at information it has about A and C. > If an address is ambiguous outside its realm of routability, who cares? not being on the public internet is not the same thing as "outside the realm of routability". > Either the routing system has a unique entry for the node, so all the > participants can get there, or the address is outside this realm of > routability, and they wouldn't get there even if the address is unique. No. The routing system is not monolithic, routing policy domains and addressing domains can overlap, and hosts may exist in multiple domains or at the intersection of multiple domains. It's not as if all of the interconnections between a set of communicating hosts are either permitted or forbidden at the same time. > > wrong. B has no idea whether A's SL address is valid for C. > > it might be obvious from looking at the drawing that C cannot use > > the SL address for A, but it's not obvious to B from the information > > available to it. > > B knows that it only has a global for C and a SL for A, so it can't > refer one to the other with any hope that the connection will actually > work. basically true, but B has no way of knowing whether this will work even if both A and C have SLs, or if both A and C have globals. the best B can do under any circumstances is to say "A, here is the set of addresses I have for C" (or "C, here is the set of addresses I have for A") and let A (or C) sort it out as best it can. B cannot make a reliable decision on A or C's behalf as to whether they can connect or, if there are multiple addresses, which address is the one to use. > As long as there is no NAT in the path, there is no way that routing > would work if the SL for A, B, & C are from different realms. that's simply incorrect. any of A, B and C can exist in multiple realms, and B doesn't know which realms A and C (or for that matter B) are in. > Assuming > we add the ability for local management of site-ids, if A & C have a > private connection the prefix A tells B would have to be the same as the > one it tells C, so given that multiple prefixes are available to A and C, how are A and C going to arrange to choose the same prefix when talking to B? don't say that they should use the same address selection algorithm, after all they may have different needs, or their current network connectivity at the time they each started talking to B might have been different. > or routing within A would fail to deliver the packets. > At the same time, there is no reason that the disconnected sites of Q, > R, & S couldn't use the same set of site-ids. presuming that {Q R S } and {A B C} always stayed disjoint, which is a difficult condition to enforce. here's the question - given that there could well be a good reason for such private networks to merge (e.g. say that company Q merged with company A) do you really want to force NATv6s on them? or massive renumbering of all of the sites involved, even those not involved in the merger? ambiguous addresses are just a nightmare. > > > Since this is the problem for the disconnected site, the requirement > > > needs to be that an app never passes around mixed scope addresses. > > > > I don't know what a "mixed scope" address is. > > Not clearly stated... an app should not pass around an address set > unless all the scopes match. that's a truly bizarre idea. nobody would adhere to such a rule unless (maybe) we made it easy for all hosts to have global addresses. and the rule wouldn't solve the problem anyway. you're trying to get apps to enforce arbitrary restrictions on interconnection which are not dictated by site policies, and which would actually prevent many kinds of distributed apps from serving their purposes. what is a proxy, after all, if not an app component that lives in the intersection of policy domains that mediates communication between peers in those various domains? are you going to say that proxies can't exist because you're refusing to allow them to mediate between apps that choose different addressing scopes? > > The requirement should be that every network can get globally-unique > > addresses for each of its hosts, and that it's free to interconnect > > using those addresses with any other network that will agree > > to connect > > to it. > > That is a nice idea, and if we had a mechanism for PI addresses this > would be possible. Help promote the need for PI, and stop trying to turn > SL into PI. There is a need for both. As I've said before, I'm all for having PI addresses. I don't personally care whether SL is the mechanism or there is some other mechanism, as long as we get PI addresses that sites can use to interconnect between themselves. I don't even care if they're aggregatable (though others might). On the other hand, if we have PI addresses, I'm unconvinced of the need for SLs in that case. Perhaps someone can cite a use case for SLs that would not be met by PIs. Until I see that use case then my presumption is that we'd be better off with PIs and without SLs. > > That way, every host and app that needs one can get a globally > > unique address, and apps can then be discouraged from using ambiguous > > addresses. It doesn't mean that every app can route traffic to > > any other potential peer that it knows about, but that's a given. > > There are apps that don't want arbitrary global accessability, and this > requirement would force them to have it anyway. No. Nothing stops an app from refusing any connection (or ignoring any input) it wants to refuse (ignore), and nothing stops a site from blocking traffic on any source/dest pair it wants. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jun 30 22:35:18 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g615ZIk7017378; Sun, 30 Jun 2002 22:35:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g615ZHgN017377; Sun, 30 Jun 2002 22:35:17 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g615ZEk7017370 for ; Sun, 30 Jun 2002 22:35:14 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA08327 for ; Sun, 30 Jun 2002 22:35:21 -0700 (PDT) Received: from smtp.huawei.com ([61.144.161.21]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA28522 for ; Sun, 30 Jun 2002 23:35:19 -0600 (MDT) Received: from mailin.huawei.com ([172.17.1.113]) by smtp.huawei.com (Netscape Messaging Server 4.15) with ESMTP id GYK23T00.R73 for ; Mon, 1 Jul 2002 13:33:29 +0800 Received: from CL5002VJAMRIT ([10.18.4.151]) by mailin.huawei.com (Netscape Messaging Server 4.15) with ESMTP id GYK28M00.S0K; Mon, 1 Jul 2002 13:36:22 +0800 Message-ID: <002201c220c2$95179490$9704120a@in.huawei.com> From: "Vijay Amrit Agrawal" To: "Keith Moore" Cc: References: <200206281402.g5SE22212060@astro.cs.utk.edu> Subject: Re: Maybe: IPv6 Scoped Addresses and Routing Protocols Date: Mon, 1 Jul 2002 11:16:01 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, The disadvantages of NAT is pretty well known but I was trying to see if I can extract any feature of NAT that is useful. I am not saying that use NAT as it is, but see if we can learn any thing positive from it, beside saying it has problems. These are the two things which I think we can learn from NAT: i) I see discussion here of the application trying to decide the address. I don't think it is a good idea to couple application with addresses, (Nat being one example, though some may say invalid example, it is a real life example.). For example in IPv4 world if we had decided that the application had to use mac address if the peer is in same subnet else use the IP address. I think it is better to avoid such concepts unless we see some other big advantage out of it.(Perhaps you also don't like the idea of application dealing with addresses). ii)If you can model NAT in a different way, you can see that it gives a different way of route aggregation. An enterprise might be using lots of private address but so many private address are aggregated into few public address. This is a different way of address aggregation at least very different from what I am aware of. This address aggregation as existing currently in NAT is certainly a problem as the private addresses overlap but this architecture can be modified I think if we can modify the applications and IP stacks (as we have to do for IPv6), the problems of NAT can be solved too. I also think not many people will like to modify there system for NAT. (An example for solving NAT problem: To make the address unique, the application passes both the private address and the public address to the peer. The peer uses both the address in the packet and on the receiving side the gateway changes the public IP address to the private. If you consider this two address in pair it will be unique. I am aware there are other issues, but they can be solved too.) Vijay ----- Original Message ----- From: "Keith Moore" To: "Vijay Amrit Agrawal" Cc: Sent: Friday, June 28, 2002 7:32 PM Subject: Re: Maybe: IPv6 Scoped Addresses and Routing Protocols > > Why not try to make IPv6 such that, it can work well even when > > technology like NAT is deployed i.e. the end address is different from the > > transport address. > > the problem with NAT isn't just that the address changes in transit; > it's also that NATs split up the network into multiple addressing > realms and make addresses ambiguous. there's really no way to solve > that problem. > > Keith > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 30 22:44:34 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g615iYk7017410; Sun, 30 Jun 2002 22:44:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g615iXnX017409; Sun, 30 Jun 2002 22:44:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g615iTk7017402 for ; Sun, 30 Jun 2002 22:44:29 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA09635 for ; Sun, 30 Jun 2002 22:44:36 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA05567 for ; Sun, 30 Jun 2002 22:44:36 -0700 (PDT) Received: from localhost ([3ffe:501:100f:1041::6]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g615iDA21433; Mon, 1 Jul 2002 14:44:14 +0900 (JST) Date: Mon, 01 Jul 2002 14:44:14 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Francis Dupont Cc: ipng@sunroof.eng.sun.com Subject: Re: Request for Agenda Items for IETF 54 IPv6 Sessions In-Reply-To: <200206291617.g5TGHlGF095042@givry.rennes.enst-bretagne.fr> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. References: <200206291617.g5TGHlGF095042@givry.rennes.enst-bretagne.fr> MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 21 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Sat, 29 Jun 2002 18:17:47 +0200, >>>>> Francis Dupont said: > In your previous mail you wrote: > => Francis Dupont wrote: > => I strongly encourage items about prefix delegation for > => home sites because these are *urgent* for IPv6 deployment. > I must have missed something. Can you develop this / post links? > => today ISP which manages an IPv6 dialup service (i.e., its customers > run "home sites") should allocate a /48 per connection but there is > no available protocol to do this. Just FYI: in the forthcoming Networld + Interop Tokyo we'll present IPv6 prefix delegation using DHCPv6 in a multi-vendor environment. 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 Sun Jun 30 23:01:30 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6161Uk7017458; Sun, 30 Jun 2002 23:01:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6161UnS017457; Sun, 30 Jun 2002 23:01:30 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6161Rk7017450 for ; Sun, 30 Jun 2002 23:01:27 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA20113 for ; Sun, 30 Jun 2002 23:01:34 -0700 (PDT) Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA11022 for ; Sun, 30 Jun 2002 23:01:33 -0700 (PDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g6161C2F024916; Mon, 1 Jul 2002 08:01:13 +0200 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with SMTP id g6161Bu141132; Mon, 1 Jul 2002 08:01:11 +0200 Received: from dhcp23-199.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA38722 from ; Mon, 1 Jul 2002 07:59:49 +0200 Message-Id: <3D1F36A8.1A55339D@hursley.ibm.com> Date: Sun, 30 Jun 2002 18:49:44 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: itojun@iijlab.net Cc: Keith Moore , Michael Thomas , Michel Py , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols References: <20020628135406.39AEA4B2A@coconut.itojun.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk itojun@iijlab.net wrote: > > >> >> SLs without > >> >> site-ids cause problems for distributed applications. > >> >Only if they leak, which the scope rules prevent. > >> given the common leakage of net 10 addresses (routes, packets > >> with net 10 src/dst, and DNS records), i don't feel confortable > >> with "only if they leak". they will leak. > >Is that any reason to make them meaningful once leaked? > > sorry for confusion, i vote for killing sitelocal entirely. This (if it's still possible) would certainly resolve the problem, but would leave open Keith's question about how to allocate a prefix for disconnected sites (especially those which don't have even a single IPv4 address and therefore an implied 6to4 prefix). 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 Sun Jun 30 23:02:51 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6162pk7017488; Sun, 30 Jun 2002 23:02:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6162oYW017487; Sun, 30 Jun 2002 23:02:50 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6162kk7017480 for ; Sun, 30 Jun 2002 23:02:46 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA12259 for ; Sun, 30 Jun 2002 23:02:53 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA07274 for ; Mon, 1 Jul 2002 00:02:52 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 19AB44B2B; Mon, 1 Jul 2002 15:02:47 +0900 (JST) To: Brian E Carpenter Cc: Keith Moore , Michael Thomas , Michel Py , ipng@sunroof.eng.sun.com In-reply-to: brian's message of Sun, 30 Jun 2002 18:49:44 +0200. <3D1F36A8.1A55339D@hursley.ibm.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols From: itojun@iijlab.net Date: Mon, 01 Jul 2002 15:02:47 +0900 Message-Id: <20020701060247.19AB44B2B@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >This (if it's still possible) would certainly resolve the problem, but >would leave open Keith's question about how to allocate a prefix for >disconnected sites (especially those which don't have even a single >IPv4 address and therefore an implied 6to4 prefix). it think i have already answered that question in the past: draft-itojun-ipv6-local-experiment-02.txt 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 --------------------------------------------------------------------