From owner-multi6@ops.ietf.org Mon Mar 1 03:56:25 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03336 for ; Mon, 1 Mar 2004 03:56:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AxjBd-000MUJ-KH for multi6-data@psg.com; Mon, 01 Mar 2004 08:54:05 +0000 Received: from [195.212.29.151] (helo=mtagate2.de.ibm.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AxjBS-000MTq-Jj for multi6@ops.ietf.org; Mon, 01 Mar 2004 08:53:54 +0000 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id i218rDRT017076; Mon, 1 Mar 2004 08:53:14 GMT Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay01.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i218rGaO256044; Mon, 1 Mar 2004 09:53:17 +0100 Received: from zurich.ibm.com (sig-9-145-138-203.de.ibm.com [9.145.138.203]) by collon.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id JAA34326; Mon, 1 Mar 2004 09:53:11 +0100 Message-ID: <4042FA17.1A9670DC@zurich.ibm.com> Date: Mon, 01 Mar 2004 09:53:43 +0100 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: Masataka Ohta CC: Multi6 List Subject: Re: List of IDs required to read? References: <4042988E.7050506@necom830.hpcl.titech.ac.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I believe the list is the drafts mentioned in the agenda at http://www.ietf.org/ietf/04mar/multi6.txt plus draft-toyama-multi6-operational-site-multihoming-00.txt Brian Masataka Ohta wrote: > > Since chairs worked hard to make ID deadline on proposals > completely fuzzy, it is not clear what are the valid > proposals and what are not. > > Can chairs provide list of IDs required to read for the > next session? > > Can Geoff provide list of IDs considered in his > presentation? > > Masataka Ohta -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM From owner-multi6@ops.ietf.org Mon Mar 1 04:27:12 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04745 for ; Mon, 1 Mar 2004 04:27:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Axjg4-0000Af-0p for multi6-data@psg.com; Mon, 01 Mar 2004 09:25:32 +0000 Received: from [195.212.29.155] (helo=mtagate6.de.ibm.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Axjg2-0000AQ-A7 for multi6@ops.ietf.org; Mon, 01 Mar 2004 09:25:30 +0000 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by mtagate6.de.ibm.com (8.12.10/8.12.10) with ESMTP id i219PRJW077772; Mon, 1 Mar 2004 09:25:27 GMT Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay02.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i219PSV3245732; Mon, 1 Mar 2004 10:25:28 +0100 Received: from zurich.ibm.com (sig-9-145-138-203.de.ibm.com [9.145.138.203]) by collon.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA40172; Mon, 1 Mar 2004 10:25:24 +0100 Message-ID: <404301A7.3AD2B3CE@zurich.ibm.com> Date: Mon, 01 Mar 2004 10:25:59 +0100 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: Noel Chiappa CC: multi6@ops.ietf.org Subject: Re: draft-savola-multi6-asn-pi-01.txt References: <20040225152839.D37D3872E3@mercury.lcs.mit.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Noel Chiappa wrote: > > > From: Pekka Savola > > > every branch which connects to ISPs has different addresses. This will > > be pure hell for network admins if they have offices in e.g. 100 or 200 > > countries, but such is life, I guess... :) > > And those 100-200 branches also have different street/mailing addresses, > right? Which causes all sorts of grief in having to have 200 different kinds > of pre-printed stationery with street/mailing addresses on it, etc, etc, etc. > But people don't piss/moan/whine about it, because that's a fundamental > aspect of street/mailing addresses. > > The routing has to have "names" which are topologically significant. If > people want a namespace which *doesn't* have those properties, because they > find those properties *inconvenient*, then they can get off their tailbones > and add one. > > Harumph. As a matter of fact, this is today's practice. The trouble is, that in order to preserve a rational and uniform *internal* addressing plan, it is achieved by using NAT at each ISP access point. The tricky bit is to achieve the same effect without NAT and without horrendous address administration busy-work. Harumph also. Brian From owner-multi6@ops.ietf.org Mon Mar 1 08:34:07 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18077 for ; Mon, 1 Mar 2004 08:34:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AxnW9-0008lz-Gd for multi6-data@psg.com; Mon, 01 Mar 2004 13:31:33 +0000 Received: from [218.37.226.186] (helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AxnW7-0008lP-UJ for multi6@ops.ietf.org; Mon, 01 Mar 2004 13:31:32 +0000 Received: from localhost (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id 02D4A2FD2E0 for ; Mon, 1 Mar 2004 14:31:48 +0100 (CET) Date: Mon, 1 Mar 2004 14:31:44 +0100 (CET) From: Kurtis Lindqvist To: multi6@ops.ietf.org Subject: BOUNCE multi6@ops.ietf.org: Non-member submission from ["Randall R. Stewart (home)" ] (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Approved: dual-stack From randall@stewart.chicago.il.us Wed Feb 25 13:25:27 2004 Received: from [66.93.186.36] (helo=stewart.chicago.il.us) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Avz2U-000Pxe-U8 for multi6@ops.ietf.org; Wed, 25 Feb 2004 13:25:27 +0000 Received: from stewart.chicago.il.us (stewart.chicago.il.us [127.0.0.1]) by stewart.chicago.il.us (8.12.8p1/8.12.8) with ESMTP id i1PDPHMC064744; Wed, 25 Feb 2004 07:25:19 -0600 (CST) (envelope-from randall@stewart.chicago.il.us) Message-ID: <403CA23D.90401@stewart.chicago.il.us> Date: Wed, 25 Feb 2004 07:25:17 -0600 From: "Randall R. Stewart (home)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20031008 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Tuexen CC: multi6@ops.ietf.org, Coene Lode , "'Barany, Pete'" Subject: Re: I-D ACTION:draft-coene-multi6-sctp-00.txt References: <57FD2C3A246F76438CA6FDAD8FE9F195A7F4C2@hrtades7.atea.be> <4B9D73E0-66C6-11D8-AF58-000A95C37894@micmac.franken.de> <403B9E51.1040902@stewart.chicago.il.us> <49AD8793-6700-11D8-A77D-000A95DC192A@micmac.franken.de> In-Reply-To: <49AD8793-6700-11D8-A77D-000A95DC192A@micmac.franken.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Level: Michael Tuexen wrote: > Randy, > see my comments below. > Best regards > Michael > > On Feb 24, 2004, at 7:56 PM, Randall R. Stewart (home) wrote: > >> Michael: >> >> I agree, the way Lode describes it is generally correct... but an >> implementation MAY not follow this .. one never knows :-> >> > That's why I wrote 'there is room for implementations'. > >> I believe KAME does as Lode describes.. however I can't >> rememeber how I coded the "Unconfirmed" address case. Either >> I thus consider it "confirmed" or refuse to send to it :-D... its >> the CRS syndrom ... I will look into this when I get a few cycles >> to see how I did it :-D > > I remember that you said that you would handle this as an > implicit 'confirmation', like using connect_x and then send it. > But I do not know if this is what the code does... Well.. I looked at the code... and basically You get a confirmed address by: 1) Using connect_x() - all addresses 2) Using connect() - the single address 3) Having a HB return to you with correct magic numbers (random stuff). 4) Getting a data chunk acknowledged that was sent to a unconfirmed address and WAS NOT retransmitted. The primary can NEVER be set to an UNCONFIRMED address. However if you send to an address that is UNCONFIRMED with the message override.. I will send the data. ... this does NOT however mark the address as CONFIRMED... you don't get that to happen until that data gets acknowledged. R > >> >> R >> >> Michael Tuexen wrote: >> >>> Dear all, >>> >>> the way Lode describes it is OK. However, there is some >>> room for implementations... >>> >>> Best regards >>> Michael >>> >>> On 24. Feb 2004, at 10:28 Uhr, Coene Lode wrote: >>> >>>> I am not a specialist on socket issues.. But Michael & Randall >>>> might know a >>>> bit more on that... >>>> >>>>> -----Original Message----- >>>>> From: Barany, Pete [mailto:pbarany@qualcomm.com] >>>>> Sent: zaterdag 21 februari 2004 19:29 >>>>> To: multi6@ops.ietf.org >>>>> Subject: RE: I-D ACTION:draft-coene-multi6-sctp-00.txt >>>>> >>>>> >>>>> In the SCTP sockets API Internet draft >>>>> (draft-ietf-tsvwg-sctpsocket-07.txt), there is a sendmsg() flag >>>>> (MSG_ADDR_OVER) for the one-to-many style that allows the >>>>> application to >>>>> request that the SCTP stack override the primary destination >>>>> address. Do >>>>> implementations honor (mandatory) this request, or can the SCTP stack >>>>> override it? Thanks. >>>> >>>> >>>> >>>> My take is: >>>> The implementation must send the msg on the IP address provided >>>> instead of the primary destination address. >>>> But if the address provided by the application is not reachable at >>>> that >>>> particular moment, then the SCTP implementation will try any of the >>>> alternative addresses of the association(including the primary >>>> destination >>>> address) >>>> >>>>> >>>>> Pete >>>>> >>>> >>>> Yours sincerely, >>>> Lode >>>> >>> >>> >>> >> >> >> -- >> Randall R. Stewart >> 815-477-2127 (office) >> 815-342-5222 (cell phone) >> >> >> > > > -- Randall R. Stewart 815-477-2127 (office) 815-342-5222 (cell phone) From owner-multi6@ops.ietf.org Mon Mar 1 09:10:39 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20625 for ; Mon, 1 Mar 2004 09:10:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Axo6R-000Frx-Ac for multi6-data@psg.com; Mon, 01 Mar 2004 14:09:03 +0000 Received: from [218.37.226.186] (helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Axo6O-000Frc-Qk for multi6@ops.ietf.org; Mon, 01 Mar 2004 14:09:01 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id 92AF02FD94D; Mon, 1 Mar 2004 15:09:18 +0100 (CET) In-Reply-To: <6DF65BFE-6ACE-11D8-9DA7-000A95CD987A@muada.com> References: <6DF65BFE-6ACE-11D8-9DA7-000A95CD987A@muada.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=fixed Message-Id: <04563E32-6B8A-11D8-B4D0-000A95928574@kurtis.pp.se> Content-Transfer-Encoding: 7bit Cc: Multi6 List From: Kurt Erik Lindqvist Subject: Re: Ad-hoc streaming Date: Mon, 1 Mar 2004 15:09:12 +0100 To: Iljitsch van Beijnum X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-02-29, at 16.46, Iljitsch van Beijnum wrote: > In response to my message a while ago, Kurtis has graciously offered > to do some ad-hoc streaming for those of us who won't be participating > in person. > > If you're interested, please have a look at > http://www.muada.com/multi6streaming.php and send me a message if you > want to participate, so I can make sure there are no bandwidth > problems with the streaming server. Expect 300 kbps or less for video, > or just 32 kbps audio. > > Also note that when the wednesday morning session starts it's still > tuesday evening and night in the US and Europe, respectively. :-) As for this part, I am all for trying it. However, I do realize that there is somewhat more to this. If someone opposes that we will attempt to broadcast the session, please let me know. > > And if anyone has information on the jabber situation, please send it > my way... It's up an running. We are still trying to find volunteer scribes though... Best regards, - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQENEDKarNKXTPFCVEQK+9ACgqe5x5YNnoNUpRwHa7ye/oXmcxskAoIEt 2m5CTScILWa7z/SDzV3JL01Z =vszd -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Mon Mar 1 09:12:22 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20689 for ; Mon, 1 Mar 2004 09:12:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Axo8N-000GBv-UN for multi6-data@psg.com; Mon, 01 Mar 2004 14:11:03 +0000 Received: from [218.37.226.186] (helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Axo8K-000GAB-Ah for multi6@ops.ietf.org; Mon, 01 Mar 2004 14:11:00 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id 218C62FD960 for ; Mon, 1 Mar 2004 15:11:18 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v612) In-Reply-To: <4042FA17.1A9670DC@zurich.ibm.com> References: <4042988E.7050506@necom830.hpcl.titech.ac.jp> <4042FA17.1A9670DC@zurich.ibm.com> Content-Type: text/plain; charset=US-ASCII; format=fixed Message-Id: <4BE733B3-6B8A-11D8-B4D0-000A95928574@kurtis.pp.se> Content-Transfer-Encoding: 7bit From: Kurt Erik Lindqvist Subject: Re: List of IDs required to read? Date: Mon, 1 Mar 2004 15:11:13 +0100 To: Multi6 List X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 There is also a list at http://ops.ietf.org/multi6/draft-list.html. However, when I tried to update it with the drafts on the agenda (the latest -00 drafts) there was a problem. I will resolve this ASAP. That list is meant to be the source of drafts that are part of Geoffs review. If someone feels that something is missing, you can address that with me and Brian. Best regards, - - kurtis - On 2004-03-01, at 09.53, Brian E Carpenter wrote: > I believe the list is the drafts mentioned in the agenda at > http://www.ietf.org/ietf/04mar/multi6.txt > plus draft-toyama-multi6-operational-site-multihoming-00.txt > > Brian > > Masataka Ohta wrote: >> >> Since chairs worked hard to make ID deadline on proposals >> completely fuzzy, it is not clear what are the valid >> proposals and what are not. >> >> Can chairs provide list of IDs required to read for the >> next session? >> >> Can Geoff provide list of IDs considered in his >> presentation? >> >> Masataka Ohta > > -- > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > Brian E Carpenter > Distinguished Engineer, Internet Standards & Technology, IBM > -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQENEhKarNKXTPFCVEQJZCACbBKrwRIKgvIuowGgDkS7XqNLhOVMAoMd0 1G5sZfBRs75e/Yr2/mpnUYez =ROzo -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Mon Mar 1 09:14:39 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20844 for ; Mon, 1 Mar 2004 09:14:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Axo9p-000GOU-T3 for multi6-data@psg.com; Mon, 01 Mar 2004 14:12:33 +0000 Received: from [218.37.226.186] (helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Axo9m-000GNy-OV for multi6@ops.ietf.org; Mon, 01 Mar 2004 14:12:30 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id 683512FD973; Mon, 1 Mar 2004 15:12:48 +0100 (CET) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=fixed Message-Id: <8194CDC1-6B8A-11D8-B4D0-000A95928574@kurtis.pp.se> Content-Transfer-Encoding: 7bit Cc: Multi6 List , mbagnulo@ing.uc3m.es, Iljitsch van Beijnum From: Kurt Erik Lindqvist Subject: Re: host-centric draft Date: Mon, 1 Mar 2004 15:12:43 +0100 To: Erik Nordmark X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-02-25, at 18.06, Erik Nordmark wrote: >> So the question is: can we detect the actual reachability using probes >> fast enough that we don't feel we also need to look in the routing >> tables? If end-to-end is 30 seconds while routing table is 30 >> microseconds, then sure, I agree that the latter is useful. If >> end-to-end is 3 seconds, maybe having to wait this long some of the >> time is better than importing all this BGP complexity. If it's 300 >> milliseconds I'm sure it is. > > That's on the benefit side, but also have too look at the cost side > in terms of scaling. > If all hosts perform e2e probing of all the local/peer locator pairs > this might add up to a lot of packets; might be more than the amount of > data packets that are exchanged in some cases (imagine hosts being > sensors > which only send a data packet every 30 seconds and now you add probing > 4 or > so local/peer locator pairs!). > > If we care about *site* (and not *host*) multihoming one could try to > have hosts share the information they learn from probing with their > neighboring hosts. But that leads more or less to reinventing > a routing protocol. Or piggybacking on one of the existing ones? Best regards, - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQENE3aarNKXTPFCVEQLo9wCgxJXvj6AoOj0amAdMhyv4DbgTriUAn0KZ B6kh+G0ZLWNYD23xLc95horC =AqgB -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Mon Mar 1 09:17:09 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20990 for ; Mon, 1 Mar 2004 09:17:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AxoCz-000HBA-Rv for multi6-data@psg.com; Mon, 01 Mar 2004 14:15:49 +0000 Received: from [218.37.226.186] (helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AxoCy-000HAj-Qt for multi6@ops.ietf.org; Mon, 01 Mar 2004 14:15:49 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id B0C052FD9A0; Mon, 1 Mar 2004 15:16:05 +0100 (CET) In-Reply-To: <2C4F5D6C-67BA-11D8-997E-000A95CD987A@muada.com> References: <2C4F5D6C-67BA-11D8-997E-000A95CD987A@muada.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=fixed Message-Id: Content-Transfer-Encoding: 7bit Cc: Multi6 List , Erik Nordmark From: Kurt Erik Lindqvist Subject: Re: host-centric draft Date: Mon, 1 Mar 2004 15:16:00 +0100 To: Iljitsch van Beijnum X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-02-25, at 18.43, Iljitsch van Beijnum wrote: > >> might be more than the amount of >> data packets that are exchanged in some cases (imagine hosts being >> sensors >> which only send a data packet every 30 seconds and now you add >> probing 4 or >> so local/peer locator pairs!). > > That's why I think we should only perform reachability checks when we > already know or at least have a strong suspicion that something is > wrong. > > One possible exception is session establishment: it might be useful to > try several setup attempts in parallel, as the one that completes the > fastest is probably also the one that offers best peformance during > the session. > Don't this open up for a new DDoS? Interrupt the transport on both sides, or at a (or multiple) site exit router, enough to cause a storm of setup attempts? Best regards, - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQENFo6arNKXTPFCVEQKQ4QCeNjZJSU67X+M0pny070pE6Qx7Ka8AniPF /A1HDbIvFCETTPY+4t7zYA7Q =gnKu -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Mon Mar 1 14:30:24 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29611 for ; Mon, 1 Mar 2004 14:30:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Axt62-000HoL-5m for multi6-data@psg.com; Mon, 01 Mar 2004 19:28:58 +0000 Received: from [18.26.0.122] (helo=mercury.lcs.mit.edu) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Axt5y-000Hnx-Se for multi6@ops.ietf.org; Mon, 01 Mar 2004 19:28:54 +0000 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 8CF2186AF0; Mon, 1 Mar 2004 14:28:54 -0500 (EST) To: multi6@ops.ietf.org Subject: Re: draft-savola-multi6-asn-pi-01.txt Cc: jnc@mercury.lcs.mit.edu Message-Id: <20040301192854.8CF2186AF0@mercury.lcs.mit.edu> Date: Mon, 1 Mar 2004 14:28:54 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: Brian E Carpenter >> If people want a namespace which *doesn't* have those properties, >> because they find those properties *inconvenient*, then they can get >> off their tailbones and add one. > As a matter of fact, this is today's practice. The trouble is, that in > order to preserve a rational and uniform *internal* addressing plan, it > is achieved by using NAT at each ISP access point. In light of my immediately preceeding comment, this seems to me to be an obvious sign that we have too few namespaces *in the current system*. > The tricky bit is to achieve the same effect without NAT and without > horrendous address administration busy-work. Were such another namespace (e.g of host ID's) available, so that the routing-names of these machines would be less "interesting" (and possibly assigned automatically, e.g. by concatenating an "interface ID" with the routing-name of the physical network they connect to - and yes, I know there's lots of other needed springs and gears, like getting those addresses into something like the DNS), do you think we would not see this focus on the routing-names? In other words, is the situation you describe (where people have one addressing scheme internally, and another externally, with NAT to map between them) caused precisely by having too few name-spaces - or would the same thing happen even if we also have an additional namespace of host identifiers? If the latter, that's something I'd like to understand - because clearly, unless the system as a whole somehow provides whatever it is that people think they need here, they will continue to use NAT boxes... Noel From owner-multi6@ops.ietf.org Mon Mar 1 18:45:39 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13501 for ; Mon, 1 Mar 2004 18:45:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Axx3W-0006oP-OX for multi6-data@psg.com; Mon, 01 Mar 2004 23:42:38 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Axx3V-0006np-B7 for multi6@ops.ietf.org; Mon, 01 Mar 2004 23:42:37 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i21Nfdrq013617; Tue, 2 Mar 2004 00:41:39 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: References: <2C4F5D6C-67BA-11D8-997E-000A95CD987A@muada.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Multi6 List From: Iljitsch van Beijnum Subject: Re: host-centric draft Date: Tue, 2 Mar 2004 00:41:17 +0100 To: Kurt Erik Lindqvist X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 1-mrt-04, at 15:16, Kurt Erik Lindqvist wrote: >> That's why I think we should only perform reachability checks when we >> already know or at least have a strong suspicion that something is >> wrong. >> One possible exception is session establishment: it might be useful to >> try several setup attempts in parallel, as the one that completes the >> fastest is probably also the one that offers best peformance during >> the session. > Don't this open up for a new DDoS? Interrupt the transport on both > sides, or at a (or multiple) site exit router, enough to cause a storm > of setup attempts? Would the interruption of the transport in and of itself be a DoS you need to worry about?? :-( I think having two, three or four SYNs at the same time is ok as long as we only do this once every X seconds rather than several times a second which could happen with HTTP. Also, we may want to include a TCP option that lets the server know different SYNs are part of the same session setup attempt so the server can react in a smarter way. (For instance, delay SYN+ACKs a bit for less-preferred addresses and throw away the remaining half open TCP sessions when one completes.) From owner-multi6@ops.ietf.org Mon Mar 1 19:48:06 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16820 for ; Mon, 1 Mar 2004 19:48:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Axy2q-000Gid-PO for multi6-data@psg.com; Tue, 02 Mar 2004 00:46:00 +0000 Received: from [218.37.226.186] (helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Axy2p-000Gi8-6h for multi6@ops.ietf.org; Tue, 02 Mar 2004 00:45:59 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id BC21030045B for ; Tue, 2 Mar 2004 01:46:16 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v612) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=fixed To: Multi6 List From: Kurt Erik Lindqvist Subject: Scribes Date: Tue, 2 Mar 2004 01:46:05 +0100 X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00,UPPERCASE_25_50 autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I am still looking for volunteers as note taker and jabber scribe.... - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQEPZU6arNKXTPFCVEQKHcwCgjoZzhGAvv2uXuaOOYGelhf2LFr4AoNH0 YinzOUdW77fA4nFkj6jmPVdN =Vi/k -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Mon Mar 1 19:49:11 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16858 for ; Mon, 1 Mar 2004 19:49:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Axy4k-000H2s-Ei for multi6-data@psg.com; Tue, 02 Mar 2004 00:47:58 +0000 Received: from [218.37.226.186] (helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Axy4j-000H2a-I9 for multi6@ops.ietf.org; Tue, 02 Mar 2004 00:47:57 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id 4BEAE300476 for ; Tue, 2 Mar 2004 01:48:15 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v612) Content-Transfer-Encoding: 7bit Message-Id: <47690FF1-6BE3-11D8-B4D0-000A95928574@kurtis.pp.se> Content-Type: text/plain; charset=US-ASCII; format=fixed To: Multi6 List From: Kurt Erik Lindqvist Subject: Draft list Date: Tue, 2 Mar 2004 01:48:10 +0100 X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00,UPPERCASE_25_50 autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have now updated http://ops.ietf.org/multi6/draft-list.html wiht the - -00 submissions and changed some errors that was submitted to me. Best regards, - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQEPZzqarNKXTPFCVEQK3VACfZOJpPN0eWnDWE/CdVO93JsfM/7MAoODe 8kAj85a8qddY2VbQrL9lH5Wq =WFvv -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Mon Mar 1 20:33:54 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20153 for ; Mon, 1 Mar 2004 20:33:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AxymE-000PWp-2i for multi6-data@psg.com; Tue, 02 Mar 2004 01:32:54 +0000 Received: from [203.50.0.6] (helo=kahuna.telstra.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Axym9-000PW4-8E for multi6@ops.ietf.org; Tue, 02 Mar 2004 01:32:49 +0000 Received: from gih505.telstra.net (kahuna.telstra.net [203.50.0.6]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id i221WduX044314 for ; Tue, 2 Mar 2004 12:32:46 +1100 (EST) (envelope-from gih@telstra.net) Message-Id: <6.0.1.1.2.20040302122144.01c94d38@localhost> X-Sender: gih@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Tue, 02 Mar 2004 12:32:29 +1100 To: Multi6 List From: Geoff Huston Subject: DRAFT of the architecture presentation for the WG session this week In-Reply-To: References: <2C4F5D6C-67BA-11D8-997E-000A95CD987A@muada.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_4420235==_" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk --=====================_4420235==_ Content-Type: text/plain; charset="us-ascii"; format=flowed In the interests of allowing everyone to come armed with the appropriate weapons for this agenda topic, I've attached a PDF of the current version of the draft. I may (will) change the presentation between now depending on the response from this list,, but I would obviously prefer a little shaking out in the wg on the more generic topic of "is this architectural taxonomy on the right track" and "have I missed an architectural taxonomy element?" But of course any comment is helpful - but saying that I want comments on this list is perhaps just adding more jet fuel to the inferno - I don't see this as a reticent group! Geoff --=====================_4420235==_ Content-Type: application/pdf; name="2004-02-17-multi6-arch.pdf" Content-Disposition: attachment; filename="2004-02-17-multi6-arch.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjQNJeLjz9MNCjQ1NiAwIG9iaiA8PC9MaW5lYXJpemVkIDEvTCAxMTU4OTMvTyA0NjAv RSAyNjQzMS9OIDIxL1QgMTA2NzI1L0ggWyA4MTIgNjQ4XT4+DWVuZG9iag0gICAgICAgICAgICAg DQp4cmVmDQo0NTYgMjUNCjAwMDAwMDAwMTYgMDAwMDAgbg0KMDAwMDAwMTY0NSAwMDAwMCBuDQow MDAwMDAwODEyIDAwMDAwIG4NCjAwMDAwMDE5NTQgMDAwMDAgbg0KMDAwMDAwMjA5OSAwMDAwMCBu DQowMDAwMDAyNDg4IDAwMDAwIG4NCjAwMDAwMDI1MzUgMDAwMDAgbg0KMDAwMDAwMjU3MSAwMDAw MCBuDQowMDAwMDAyNjE4IDAwMDAwIG4NCjAwMDAwMDI2NjUgMDAwMDAgbg0KMDAwMDAwMjcxMiAw MDAwMCBuDQowMDAwMDAyNzg5IDAwMDAwIG4NCjAwMDAwMDM1NDUgMDAwMDAgbg0KMDAwMDAwNDA3 NiAwMDAwMCBuDQowMDAwMDA0MzM1IDAwMDAwIG4NCjAwMDAwMDcwMDUgMDAwMDAgbg0KMDAwMDAw NzgwNiAwMDAwMCBuDQowMDAwMDE5ODk1IDAwMDAwIG4NCjAwMDAwMjA1NjAgMDAwMDAgbg0KMDAw MDAyMTI3MCAwMDAwMCBuDQowMDAwMDIxOTY2IDAwMDAwIG4NCjAwMDAwMjI1NTggMDAwMDAgbg0K MDAwMDAyNTIxMyAwMDAwMCBuDQowMDAwMDI1ODc3IDAwMDAwIG4NCjAwMDAwMDE0NjAgMDAwMDAg bg0KdHJhaWxlcg0KPDwvU2l6ZSA0ODEvUHJldiAxMDY3MTMvWFJlZlN0bSAxNDYwL1Jvb3QgNDU3 IDAgUi9JbmZvIDk1IDAgUi9JRFs8MDYwOTE3MDMyZDI2NDgyZTM2NzBiNjAyYzk3OTAwNzM+PDEz ZTRhYTQ1ODFmMTlmNGFhZTlkZTVjZDliY2FiMWY0Pl0+Pg0Kc3RhcnR4cmVmDQowDQolJUVPRg0K ICAgICAgICAgICAgDQo0NTggMCBvYmo8PC9MZW5ndGggNTU0L0ZpbHRlci9GbGF0ZURlY29kZS9D IDg5My9MIDg3Ny9PIDg2MS9TIDc1OT4+c3RyZWFtDQp42mJgYGBiYGCVYmBlYGDZxsDPgAD8QDE2 BhYGjhlMSKIMW88xxtrO0L4g6/CqSZz1EOczZg/2BtuEzgMnG++11jCeApr2gq+AhSH1bfVzy73v 5zw3v/q1ugGunSfxQOcLLtXW2YXXomLDH5ocOtz5QEEmyasvUiz3uK9h+EMdhuOdL9gSJk0DccOi Yn94Mxg+qmKcobJ0duFln9Bp0+uEDvBUzGtI49SyDEOoKfKSYm/u7EwuPXZNt2xmy/UzIYwnNTLk +DSTE69LR2y9lSYcbxjAnjCprfFFc+R22ZDD8alLoXapLANa7WMafjOzgly7oG5ePDXtTsll0dSl 91s2MMupL5Bs8uoLRRgl2wTUuIg37U5pMG/ttOktGx5VcLBLTJoxqzwmN0s8c7JPKNSznZrA8LnM G/otKg7igCSvpEpggGTELsMTRCi6gEHN4tEBJJmUy8s7gAAcBWnp5RUQpqA4iNUBVqGEUCEo4g4X Z2B0QdIqaI6QYEDSoE6aOcgSjILIFrAjDFI2hoiDOMwmCDVKxlBHgDkIm+FqiE2cQKDFwCglDaRF gVgT7CkVBj7GLWICTMCw02HYwHRAk9tB7oP5KS/ubx8D5jot4gpQOtR3qIRDQtOgzWEuY+TMA0an dDkfKCQwOWUzqGgVMDkcYI4R/RDe8M75CTy52zEwpoOsE2Ng4HYC0hEMjL1LGcCZjsEaiEMYGIvc QHHFwCAdD9ECEGAAb9UsMQ0KZW5kc3RyZWFtDWVuZG9iag00ODAgMCBvYmo8PC9TaXplIDQ1Ni9M ZW5ndGggMzUvRmlsdGVyL0ZsYXRlRGVjb2RlL0RlY29kZVBhcm1zPDwvQ29sdW1ucyAzL1ByZWRp Y3RvciAxMj4+L1dbMSAxIDFdL1R5cGUvWFJlZi9JbmRleFs5NiAzNjBdPj5zdHJlYW0NCnjaYmIK YWBiYGAcxYMFM84dDYPR+BjFo/EBwgABBgBZ3QZlDQplbmRzdHJlYW0NZW5kb2JqDTQ1NyAwIG9i ajw8L1BhZ2VzIDkwIDAgUi9PdXRsaW5lcyA2MiAwIFIvVHlwZS9DYXRhbG9nL1BhZ2VMYWJlbHMg ODggMCBSL1N0cnVjdFRyZWVSb290IDk2IDAgUi9NZXRhZGF0YSA5NCAwIFIvT0NQcm9wZXJ0aWVz PDwvRDw8L09yZGVyW10vUkJHcm91cHNbXT4+L09DR3NbNDU5IDAgUl0+Pi9QaWVjZUluZm88PC9N YXJrZWRQREY8PC9MYXN0TW9kaWZpZWQoRDoyMDA0MDMwMjEyMjAwMik+Pj4+L0xhc3RNb2RpZmll ZChEOjIwMDQwMzAyMTIyMDAyKS9NYXJrSW5mbzw8L01hcmtlZCB0cnVlL0xldHRlcnNwYWNlRmxh Z3MgMD4+Pj4NZW5kb2JqDTQ1OSAwIG9iajw8L1R5cGUvT0NHL05hbWUoQmFja2dyb3VuZCkvVXNh Z2U8PC9DcmVhdG9ySW5mbzw8L0NyZWF0b3IoQWNyb2JhdCBQREZNYWtlciA2LjAgZm9yIFBvd2Vy UG9pbnQpPj4vUGFnZUVsZW1lbnQ8PC9TdWJUeXBlL0JHPj4+Pj4+DWVuZG9iag00NjAgMCBvYmo8 PC9Db250ZW50cyA0NjcgMCBSL1R5cGUvUGFnZS9QYXJlbnQgOTEgMCBSL1JvdGF0ZSA5MC9NZWRp YUJveFswIDAgNTk1IDg0Ml0vQ3JvcEJveFsyOSA2MiA1NjYgNzgwXS9SZXNvdXJjZXM8PC9Db2xv clNwYWNlPDwvQ1MyIDQ2MSAwIFIvQ1MwIDQ2MiAwIFIvQ1MxIDQ2MyAwIFIvQ1MzIDQ2NCAwIFIv Q1M0IDQ2NSAwIFI+Pi9Gb250PDwvVFQwIDQ2OCAwIFI+Pi9YT2JqZWN0PDwvSW0xIDQ3NiAwIFIv SW0yIDQ3NyAwIFIvSW0zIDQ3OCAwIFIvSW0wIDQ3OSAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4dC9J bWFnZUMvSW1hZ2VJXS9FeHRHU3RhdGU8PC9HUzAgNDY2IDAgUj4+L1Byb3BlcnRpZXM8PC9NQzAg NDU5IDAgUj4+Pj4vU3RydWN0UGFyZW50cyAwPj4NZW5kb2JqDTQ2MSAwIG9ialsvSW5kZXhlZCA0 NjIgMCBSIDI1NSA0NzMgMCBSXQ1lbmRvYmoNNDYyIDAgb2JqWy9JQ0NCYXNlZCA0NzAgMCBSXQ1l bmRvYmoNNDYzIDAgb2JqWy9JbmRleGVkIDQ2MiAwIFIgMjU1IDQ3NCAwIFJdDWVuZG9iag00NjQg MCBvYmpbL0luZGV4ZWQgNDYyIDAgUiAyMzggNDc1IDAgUl0NZW5kb2JqDTQ2NSAwIG9ialsvSW5k ZXhlZCA0NjIgMCBSIDI1NSA0NzEgMCBSXQ1lbmRvYmoNNDY2IDAgb2JqPDwvVHlwZS9FeHRHU3Rh dGUvU0EgZmFsc2UvT1AgZmFsc2UvU00gMC4wMi9vcCBmYWxzZS9PUE0gMT4+DWVuZG9iag00Njcg MCBvYmo8PC9MZW5ndGggNjg2L0ZpbHRlci9GbGF0ZURlY29kZT4+c3RyZWFtDQpIiXSUb0/bMBDG 3+dT3MttEs75/F9CSG1BjGndYETbC8SLKLQQRJuuCWLbp9/ZSaDdQFXq1L7z8/Nz5+aTbVcvy6qD w8O8+L1ZQH5e3tbrsqubNeTTafMLrkgGQQosCh/QGFBIwgRwDoWRaOA6n3RdWd0tbuAqL5oN5zVd 16wg/7xYdpB/q2/vOrg+OpoezyDLv84gn88Q+l+zS4SqBRQ0PB6grdaZhJpXT3n1ts2IPHglvJOg nFAelBYGtotsmf3MyJo4JaUSIUiUcNDHkBGBYtCPD7DmOASyQtq0bFkJYqJJed6h0VCtsvxshXDc ZBf8kRFGSud4RFS8VwIjK9mNEAIEJax5JlKCNLL6SBV8VJFEwpldqiAwZe+BscF+B4xzHQfZlG5V NL2HkyMcC3gOImAalHH3UV9rIXEAGQSMdUK7EPxztNEIjnAPghONsiptpX3EYAWvX+reI9CIcJEh K/Gm+0NvEreMjjXBoSaehLfAfUPPBvHuNoF6LpRMFunokPV6oN2li7NOhuBiVO9SNCDN8AYuvFRQ 9YQnc+6v9JWfx/aez86OOW1ow0g/tpzliqgePPXj7BL+W7ycfeEM7+EJJMx5n3t+PsHVNcINZNMi y4sCealYZrFd0EJRwUF6VTz7xNFQtMCl4fEPEBRbntLcs1z4fuAjmSC8id0htRXkUAcoVtm7yWaz beINa6FrYP740NX2fXGfnRT/HVCOB+SLs4/Vw7jQwyR58gIJDvoBuZOdcKkk5Ezsu1F+DZNtdVd3 i6p73JYP8L1ePEGzHEiA4TZNWz60bzDRyPQKD0Wf4pukwSZunehJP0SLXLwclrg9A2qTiE4XzXIJ Hx/brlm/IapeFU1K/qU2ox3/ilrLFyXEfz1lhTLIfRt15yX7AISod1X/CjAAgoIrWQ0KZW5kc3Ry ZWFtDWVuZG9iag00NjggMCBvYmo8PC9UeXBlL0ZvbnQvRW5jb2RpbmcvV2luQW5zaUVuY29kaW5n L0Jhc2VGb250L0RITUtCTCtIYXJtb255RGlzcGxheS9GaXJzdENoYXIgMzIvTGFzdENoYXIgMTQ4 L1N1YnR5cGUvVHJ1ZVR5cGUvRm9udERlc2NyaXB0b3IgNDY5IDAgUi9XaWR0aHNbMjAwIDAgMCAw IDAgMCAwIDAgMjQ1IDI0NSAwIDQ1NCAyMjAgMzA0IDIyMCAyNTYgNDU0IDQ1NCA0NTQgNDU0IDQ1 NCA0NTQgNDU0IDAgNDU0IDAgMjIwIDAgMCAwIDAgMzgwIDAgNTQwIDUyMSA0ODYgNTgzIDQ2NSA0 MzcgNTgxIDYxMSAyNDAgMCAwIDQyMCA3NjggNjMyIDYwNiA0ODYgNjA2IDUyMCA0NzcgNTAwIDYy MiA1NDAgNzc5IDAgMCAwIDAgMCAwIDAgMCAwIDQ5OCA0OTAgNDEwIDUwMSA0NTMgMjc4IDQ5MSA1 MjUgMjA4IDIxMyA0MjIgMjM3IDc4MyA1MjYgNTAzIDQ5NSA0OTIgMzExIDM3NSAzMjIgNTA3IDQ0 MCA3MDEgNDQ1IDUwNSAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMjI2IDIyMCAzODMgMzgzXT4+DWVuZG9iag00NjkgMCBvYmo8PC9UeXBlL0ZvbnREZXNjcmlw dG9yL0ZvbnRGaWxlMiA0NzIgMCBSL0ZvbnRCQm94Wy02NyAtMjQxIDg5MyA4MzldL0ZvbnROYW1l L0RITUtCTCtIYXJtb255RGlzcGxheS9GbGFncyAzMi9TdGVtViA2OC9DYXBIZWlnaHQgNjI1L1hI ZWlnaHQgMC9Bc2NlbnQgODM4L0Rlc2NlbnQgLTI0MC9JdGFsaWNBbmdsZSAwL0ZvbnRGYW1pbHko SGFybW9ueSBEaXNwbGF5KS9Gb250U3RyZXRjaC9Ob3JtYWwvRm9udFdlaWdodCA0MDA+Pg1lbmRv YmoNNDcwIDAgb2JqPDwvTGVuZ3RoIDI1NzUvRmlsdGVyL0ZsYXRlRGVjb2RlL04gMy9BbHRlcm5h dGUvRGV2aWNlUkdCPj5zdHJlYW0NCkiJnJZ5VFN3Fsd/b8mekJWww2MNW4CwBpA1bGGRHQRRCEkI ARJCSNgFQUQFFEVEhKqVMtZtdEZPRZ0urmOtDtZ96tID9TDq6Di0FteOnRc4R51OZ6bT7x/v9zn3 d+/v3d+9953zAKAnpaq11TALAI3WoM9KjMUWFRRipAkAAwogAhEAMnmtLi07IQfgksZLsFrcCfyL nl4HkGm9IkzKwDDw/4kt1+kNAEAZOAcolLVynDtxrqo36Ez2GZx5pZUmhlET6/EEcbY0sWqeved8 5jnaxAqNVoGzKWedQqMw8WmcV9cZlTgjqTh31amV9ThfxdmlyqhR4/zcFKtRymoBQOkmu0EpL8fZ D2e6PidLgvMCAMh01Ttc+g4blA0G06Uk1bpGvVpVbsDc5R6YKDRUjCUp66uUBoMwQyavlOkVmKRa o5NpGwGYv/OcOKbaYniRg0WhwcFCfx/RO4X6r5u/UKbeztOTzLmeQfwLb20/51c9CoB4Fq/N+re2 0i0AjK8EwPLmW5vL+wAw8b4dvvjOffimeSk3GHRhvr719fU+aqXcx1TQN/qfDr9A77zPx3Tcm/Jg ccoymbHKgJnqJq+uqjbqsVqdTK7EhD8d4l8d+PN5eGcpy5R6pRaPyMOnTK1V4e3WKtQGdbUWU2v/ UxN/ZdhPND/XuLhjrwGv2AewLvIA8rcLAOXSAFK0Dd+B3vQtlZIHMvA13+He/NzPCfr3U+E+06NW rZqLk2TlYHKjvm5+z/RZAgKgAibgAStgD5yBOxACfxACwkE0iAfJIB3kgAKwFMhBOdAAPagHLaAd dIEesB5sAsNgOxgDu8F+cBCMg4/BCfBHcB58Ca6BW2ASTIOHYAY8Ba8gCCJBDIgLWUEOkCvkBflD YigSiodSoSyoACqBVJAWMkIt0AqoB+qHhqEd0G7o99BR6AR0DroEfQVNQQ+g76CXMALTYR5sB7vB vrAYjoFT4Bx4CayCa+AmuBNeBw/Bo/A++DB8Aj4PX4Mn4YfwLAIQGsJHHBEhIkYkSDpSiJQheqQV 6UYGkVFkP3IMOYtcQSaRR8gLlIhyUQwVouFoEpqLytEatBXtRYfRXehh9DR6BZ1CZ9DXBAbBluBF CCNICYsIKkI9oYswSNhJ+IhwhnCNME14SiQS+UQBMYSYRCwgVhCbib3ErcQDxOPES8S7xFkSiWRF 8iJFkNJJMpKB1EXaQtpH+ox0mTRNek6mkR3I/uQEciFZS+4gD5L3kD8lXybfI7+isCiulDBKOkVB aaT0UcYoxygXKdOUV1Q2VUCNoOZQK6jt1CHqfuoZ6m3qExqN5kQLpWXS1LTltCHa72if06ZoL+gc uiddQi+iG+nr6B/Sj9O/oj9hMBhujGhGIcPAWMfYzTjF+Jrx3Ixr5mMmNVOYtZmNmB02u2z2mElh ujJjmEuZTcxB5iHmReYjFoXlxpKwZKxW1gjrKOsGa5bNZYvY6WwNu5e9h32OfZ9D4rhx4jkKTifn A84pzl0uwnXmSrhy7gruGPcMd5pH5Al4Ul4Fr4f3W94Eb8acYx5onmfeYD5i/on5JB/hu/Gl/Cp+ H/8g/zr/pYWdRYyF0mKNxX6LyxbPLG0soy2Vlt2WByyvWb60wqzirSqtNliNW92xRq09rTOt6623 WZ+xfmTDswm3kdt02xy0uWkL23raZtk2235ge8F21s7eLtFOZ7fF7pTdI3u+fbR9hf2A/af2Dxy4 DpEOaocBh88c/oqZYzFYFTaEncZmHG0dkxyNjjscJxxfOQmccp06nA443XGmOoudy5wHnE86z7g4 uKS5tLjsdbnpSnEVu5a7bnY96/rMTeCW77bKbdztvsBSIBU0CfYKbrsz3KPca9xH3a96ED3EHpUe Wz2+9IQ9gzzLPUc8L3rBXsFeaq+tXpe8Cd6h3lrvUe8bQrowRlgn3Cuc8uH7pPp0+Iz7PPZ18S30 3eB71ve1X5Bfld+Y3y0RR5Qs6hAdE33n7+kv9x/xvxrACEgIaAs4EvBtoFegMnBb4J+DuEFpQauC Tgb9IzgkWB+8P/hBiEtISch7ITfEPHGGuFf8eSghNDa0LfTj0BdhwWGGsINhfw8XhleG7wm/v0Cw QLlgbMHdCKcIWcSOiMlILLIk8v3IySjHKFnUaNQ30c7Riuid0fdiPGIqYvbFPI71i9XHfhT7TBIm WSY5HofEJcZ1x03Ec+Jz44fjv05wSlAl7E2YSQxKbE48nkRISknakHRDaieVS3dLZ5JDkpcln06h p2SnDKd8k+qZqk89lganJadtTLu90HWhduF4OkiXpm9Mv5MhyKjJ+EMmMTMjcyTzL1mirJass9nc 7OLsPdlPc2Jz+nJu5brnGnNP5jHzivJ25z3Lj8vvz59c5Lto2aLzBdYF6oIjhaTCvMKdhbOL4xdv WjxdFFTUVXR9iWBJw5JzS62XVi39pJhZLCs+VEIoyS/ZU/KDLF02KpstlZa+Vzojl8g3yx8qohUD igfKCGW/8l5ZRFl/2X1VhGqj6kF5VPlg+SO1RD2s/rYiqWJ7xbPK9MoPK3+syq86oCFrSjRHtRxt pfZ0tX11Q/UlnZeuSzdZE1azqWZGn6LfWQvVLqk9YuDhP1MXjO7Glcapusi6kbrn9Xn1hxrYDdqG C42ejWsa7zUlNP2mGW2WN59scWxpb5laFrNsRyvUWtp6ss25rbNtenni8l3t1PbK9j91+HX0d3y/ In/FsU67zuWdd1cmrtzbZdal77qxKnzV9tXoavXqiTUBa7ased2t6P6ix69nsOeHXnnvF2tFa4fW /riubN1EX3DftvXE9dr11zdEbdjVz+5v6r+7MW3j4QFsoHvg+03Fm84NBg5u30zdbNw8OZT6TwCk AVv+mLiZJJmQmfyaaJrVm0Kbr5wcnImc951kndKeQJ6unx2fi5/6oGmg2KFHobaiJqKWowajdqPm pFakx6U4pammGqaLpv2nbqfgqFKoxKk3qamqHKqPqwKrdavprFys0K1ErbiuLa6hrxavi7AAsHWw 6rFgsdayS7LCszizrrQltJy1E7WKtgG2ebbwt2i34LhZuNG5SrnCuju6tbsuu6e8IbybvRW9j74K voS+/796v/XAcMDswWfB48JfwtvDWMPUxFHEzsVLxcjGRsbDx0HHv8g9yLzJOsm5yjjKt8s2y7bM Ncy1zTXNtc42zrbPN8+40DnQutE80b7SP9LB00TTxtRJ1MvVTtXR1lXW2Ndc1+DYZNjo2WzZ8dp2 2vvbgNwF3IrdEN2W3hzeot8p36/gNuC94UThzOJT4tvjY+Pr5HPk/OWE5g3mlucf56noMui86Ubp 0Opb6uXrcOv77IbtEe2c7ijutO9A78zwWPDl8XLx//KM8xnzp/Q09ML1UPXe9m32+/eK+Bn4qPk4 +cf6V/rn+3f8B/yY/Sn9uv5L/tz/bf//AgwA94Tz+woNCmVuZHN0cmVhbQ1lbmRvYmoNNDcxIDAg b2JqPDwvTGVuZ3RoIDczMS9GaWx0ZXIvRmxhdGVEZWNvZGU+PnN0cmVhbQ0KSIm0wYNCIwAAAND7 kJa1rIXFZWtL26otG8u23drisrls23bLWlir1eJaX3HvsbCwAAAAVlZWNjY2dnZ2Dg4OTk5OLi4u bm5uHh4eXl5ePj4+fn5+IBAoICAgKCgoJCQkLCwsIiIiKioqJiYmLi4uISEhKSkpJSUFAoGkpaVl ZGRkZWXl5OTAYLC8vLyCgoKioqKSkpKysrKKigoEAlFVVVVTU1NXV9fQ0NDU1NTS0tLW1tbR0dHV 1dXT09PX1zcwMDA0NDQyMjI2NjYxMTE1NYVCoTAYzMzMzNzc3MLCwtLS0srKCg6HIxAIJBJpbW1t Y2Nja2uLQqHQaLSdnZ29vb2Dg4Ojo6OTk5Ozs7OLi4urq6ubm5u7u7uHh4enp6eXl5e3t7ePj4+v ry8Gg/Hz8/P39w8ICAgMDAwKCgoODg4JCQkNDQ0LCwsPD4+IiIiMjIyKioqOjo6JiYmNjY2Li4uP j09ISEhMTExKSkpOTk5JSUlNTU1LS0tPT8/IyMjMzMzKysrOzs7JycnNzcVisXl5eTgcDo/H5+fn FxQUFBYWFhUVFRcXl5SUEAiE0tLSsrKy8vLyioqKysrKqqqq6urqmpqa2traurq6+vr6hoaGxsbG pqam5ubmlpaW1tbWtrY2IpHY3t7e0dHR2dnZ1dXV3d3d09PT29vb19fX398/MDAwODg4NDQ0PDw8 MjIyOjo6NjY2Pj4+MTExOTk5NTU1PT09MzMzOzs7Nzc3Pz+/sLCwuLi4tLS0vLy8srKyurq6tra2 vr6+sbGxubm5tbW1vb29s7Ozu7u7t7e3v79/cHBweHh4dHREIpGOj49PTk5OT0/Pzs7Oz88vLi4u Ly+vrq6ur69vbm5ub2/JZPLd3d39/f3Dw8Pj4yOFQnl6eqJSqc/Pzy8vLzQa7fX19e3tjU6nv7+/ f3x8fH5+fn19fX9///z8MBiM399fJpP57z/4E2AAW+p6IgoNCmVuZHN0cmVhbQ1lbmRvYmoNNDcy IDAgb2JqPDwvTGVuZ3RoIDEyMDAzL0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGgxIDE3NTU2Pj5z dHJlYW0NCkiJvFZ9bFPXFT/3vWfn1eHDsECzucl75uGQKIF0AxpCHGIcP89gPuIksOc0ap/zYUJH wOVrtAwlqKJjDox1SGhCaGKsQh1C0XXHaLpVa6t1q7qNTdW6qR+rWgmYBAJUbS2qEMP73Wc7Srp2 +2/P/vmer3vuueec53uJEdFMGiWZOjZ2NX7txLU7z0HyN2Bz/3Aqc33PnUaitgYidr5/727durTq KuhlwJ10Zsvw0d4dG4nkB4lco1u2PZHeu3H1y0SzhoiWXB8aTA1cKk/8nijSC38PDUEws9utEKkc /MKh4d37mtYnzoF/Cz6e27ajPzU741pI1NoN/38dTu3LSA+7j2F+EPb69tTw4M6lp9YShT6F/erM jl27ETee0NtCn9k5mLm9K9VKNOPbmH+NmLyAfZ9ciO2k66uQBAqjfJreVFpVSSpXSJEwUx4lWkRT nscyu3dTiPSPJFfzvblE7ovsJsSsoHU10xyXSvOUNM2Tn6EvEeWvl3CvJn+T/l8PMkMngP3AE0W+ 8IwBPwAyRc3YpOZlfIiOFPU7gW8V+f/1vEQjhVGO4vexSbmYv6NIP8pspGmXoL7YEXuWviwvkUy2 TTogPSVtYUfoLI1Tml5lryHrRP+kd2m75KOn6DBtp93Ux06yRXSPLZf+QvsoLZ0lm92hYXaavkl9 8i/pCv1OstjT7HV5B37D0iVWzX6FmH4sPQAfu2iIbPnP8mX6mE7S+2wj81AvnWcj9AbGPdB2skr6 F73G2qRqaTNtkP5IndRDp9hqyrIT0h56hDqVg6wCvijU0pno2Lhh/br42jWxr0fNSHt4dahtVWuw ZWXziqaHljcuWdxQWxNYaCzQKivmeGfPLPfcp5a5XYosMWowjait8xqbKzVGLLZY8EYKgtQUgc11 iKLTbbhuO2b6dMsQLNOfsQwVLEOTlsyrBym4uEE3DZ1fihj6BOtJWKCPRoykzm869HqHVmocZiYY vx8zdLNyKKJzZusmj+4dypp2BP5y5Z52o33Qs7iBcp5ykOWgeK2RybHaVcwhpFpzZU4idaZYlssB MzXAOxKWGfH5/UlHRu2OL+5u52WOL32riJnG9FzDK9kjE17qs+tnDBgDqV6LyylMyspmNvsdPqee 1xkRXvfklUpseZA3GBGT1xtwFu+cXIBxV8Br6NlPCMEbN29Ml6SKEnfA+wkJUmxxMk3Ql2hCbIgQ +/P7RSxjEyHqA8NHE1aB16nP9zyFGuuTXLKF5pWSZt4moRktaSan24ZflMq0i9+9Q5V8tE9f3IDs O98AvtDrXK6x+/qHxJgazBqRSCFv3RYPRUCEUsW9mrkHG2GfsrGJrSINCYs3GhleYYQLBhDoogZb uyxnSnEar2jnZPcXZ/FGMyLi0s2sHSkEKHwZCetFWpr/MLdM9/1sKS2jpIiDz29HUWrMrDWQ5prt G0B/pnXL5+ehJNKXNKzBpKiS4eV1H2I5v7OiMwt7+4x1yVjsvCyg6pbkk5OiWhDoUfwY4SAUXpTL YUVFw0HdYj4qmWGVooWgpvkBIwfaY0Ili6ntMZ8/6S88/yUkXzEmV4CrU3x5IZiMqbDOF4ZWsBYB 1enmYGRKgNOcuooBFr19fpySyEVxYcxQRTljJZUcwJsLmQQ3jkhUsVLn1KFbxqCRNNBDoQ5L7E3k 2qlvvMuIJ3osp9rFLumexhX0KyZ1Rar00bOqEe/KChujqCI9u4YTmi+E12zF3GXFNzGKP6psNmro 0aydTU3kR/sM3Wtkc6FQNmPaIkoLGZ/I/2LMx6NHktxrD7GVYgFjzUDW6LKCPieCTuuA78nkYnEG uy/ew5lb1pPfmz9fFiidypPPdVwwBpxz5mQBUh1dZLepSW6hZvkM7VIuU51iUIS5qQlyA6iXXqVW 6FrYr/H/v4NiGA9KM0iFrBfYA6SLdBtgAxawvyjbLOzFXOFjEh5qdXfj7OikCqWexnECpZVzGCeA ERpXzoK/TOPsBniiekXB2Evj7gCNu2ZB/w7WvFwYlTro3qRh7K1CuUPPCp/uFsevV/FShfwpbcA+ ehCzB6NYf0jG3UBK0xn5LvzcoONyDH4k0KdxhjaTX75FQ8pSnHPnaA+7kN8r26Cv0gl3hEaU5YAb trdpRP4I9gcwEsWk48jdLDomHyKP6xR55GPkUTzgm6kN6w7QPyiMsQ/rr5XGKIrxh8BR3Bkelzvo pHwP8Z4mP+L6EaC5G7GHW9CdoSbpfeQecL1BG7CnNPIXE7WTz+T/Lg/QQeCQq4UOupvpcXeHU48W N24espcOABvYn+iAU4N12HcT6tdEh0QMk7WBTVkP1WG/R7H2DEAFOqWXKIPxKrBHvsWOS+l8HvR3 hY1TO0DUTtStVBdRAyevn4dYIcdTgTUHgRA7l78AvFDK738AuZ0K6TT6Zy2ddi2lmPIBajalv5w6 iJ5Fj5fidHpG6FAT0RdO7Ii7NAqg3w6yG/k/AO+B7nD2U5hnlfZWAmT3Y+9+xQecgz9Rl15ahD5Z JPpR9ISzjugB9Kr8MT0jelH0A3q7Q0Bqc0Zb6i5A9Ih4D0Mf0G3vbf22nLnCZr/O6CeM7nrv6nfl 69eqtXfeNrR336vQ3urya7/9TZX2woV67SLwc+D8fr/205GoNrI/qu2PBLStYVXbMhjUBlPVWn8q qKXAJ4FvbApqmxLVWlciqCXAP5owtEfArwO9NhbUYpFqLRoJahHw7atVLQwYs8wFM0y/x9RVU3Ob 1YpZJZkPkPkVtVKdr1aoc1WvOkudoXpUVXWriiqppDJijO5juO9QbS3+eObOUaVQ0+y2CUa5+Sw+ UZbvjHO142Erx9j3knxunOLd4RcxKX/oaJhVxXlVl8XtqmScj4Kgqtx8CifrcX8KP3//HHZY5wsS WWMfD3Xuy3n0w7gabdqXk1iYyw/4/QzHutHe2xNm8Q4rp2Jie29hnO/NrMKFQ+cLzX4u4T6Bq4N/ wk3JPv5vzqs1uInrCt9z7+5KsmRJq4f1st6WHxJG1htsjIQhtnmURzHGgME2wlbMI8W4UIyhQHkN MFASKIN5tEmMCc8OUxxCkikkvArNOJkMbRiKKc3kT8KgTjtNUmjtpXcloDTtr95Z7e7sSDrn+853 vrNXM77BcgGj5gsMWuh+dnNW7nPPOSunAybHXYXicaNPPQb8nOIsRx9J3FW+/2d1iks0Yyx6MtlM 900ESZAhIWMx9V8JcFIUH7g3AH56CpRpeScfo58buGHR0J+Yo//8gEks+scj+itAbmEPfMRakQyF Eg6vDG5yd7jHHLnJ3GEeM8QLQCRH0VpWsoFu53KQevDhQ/CnTQ+DgbL5dGnVrATxajAwb0LJGGEf LB0j3Ibbw48f1YIRl+ICKKh9RKP4aJRbmSiBhN0jg+vcZ9y3HLnOfMZ8yxAPgIQcZdeiTBTkF2MM P48Bak9MjFFUAHXC7QpYJuytgBK4jblHtcLg8ODwLeFLGoRGqaAdMJdsQ3JUkNBgtFu+S7Kblcpl e6SvMXswi/yh9HA6BNlLoAz0Tt7NOyNOPsSTucLrC4RfQMsCrGsWdsOKZugUdtH/nCp8CdXoNFKh 0ndRzpMPzsn0tbILT/6S0ChUtSDjZU4ZkZxGsjP4hBqph0R2aNo+XywcCtqwXicpikbCRYVbpptK bPyVyPJ868JJ5tJy+y9XjZ0xx1VSLOZdC6dxEbbSGir76dydRZA/TUtHC+fUO2vhvuDE1g76vY1P HkAl3dWpkOYd0i3n1qNMzHQmZiyYp9dxbtdIHAmPxfe94bBX6zKrVGbXsbC3KKYyuXR6l0kpxpMK 5+CrjGb8ibwf0S4DTBCBi5joMAGCCcbIH6cZoA+3sT61eF6nvkoJmw/gBvhKONAF7az08SluFlVg 45MHpJrpFvWHpiSiq/Rb9bhLu12Lu3K35+JV8q1yPEfSLsH1bBuL60kbwXOgHbA0iZikGqd0LJdS 5KJ4Oi7iGExni54tvNvFq0NBrVpCcRUV8upYNBQ05OH+L+h6rSl57tyiBQuS/f0Lm3AAbgmlQgA+ ER4d7u09AhKQHzp6VHxVoXtRROxMB+LRhIR3B4F20kVwNQcWxsfg9wHGA8iRBWGsUivkLTK1XNWq VMhY2qvpINXK8IB6gCoRdWRSogdHSxqN0SPEh/TOSIiH99a87osuiY6aYmi6M3z8b+S9Kd7FSp/V GjMN4c5OUiNm0Uaz8FGWHGhborHVAXUO6DPBXhO0mlaa8EwT7DfCIiN83wgRIzBGmGUAzgAeLei0 wGrhrgZYBKeMMKCA9xVwUgGHFPBb6R+k2KxPckqb3dRqzFfIU2pWZHJ0JvPBtJj3Uy7n/9eCDIpI eCR2uyikrFw5CVDNuSLhGExqWO222vNDtSNerW9v+6Zm9ezAy0uEu9gyfHxhHJa1HR5dNs9XUDnC tHPch0WTloyfemOdcLxjUnEtRStqQkfRlqCmRPykFQ5Zocd8wozP88Co+9X4mgL6FXBdCgzbz15l yTUGzjOQn1RKku5ivczRarcXGlPa3MIUzgBKa0b706NFTMO/e0EhogM9TVyizzPQBlBSMEWxvFAw RpF5iiLipVDE13jw+LSNjcFLyyr8scU9LQe2WLesW1E9XRiaNOGvHcs3bChlDIt801bUXBrHmKbX zJu6dvbIys5R4Wj7DRn+AZb9et7ihiViHeO0jp1UTRqUSHje5H/FX+ZJlwrmKNuVWM3iFpVUoyFy hKQqFmtaWalEgeL3gulgnCKgHTXaHwqlg1lnA1FAbr07IvIdjUEInNi3/ubNnUJbtUwKN/cKERiL rwi9K77+OiQ3K4lh6BuaQTPlVs20oTyUTIxbqod9cvDIIU8OjBz6cmBfDvRJYat0vxSvpPxKwctQ twQDgK6FyFRsC2Jb6ZuNJpWby7QC85xd2nzXB69Scjs6Ol7kV/QgEhS5zXShyG1E7TxQiicK/vz7 G3/6yuIzR3Zbd3YPCZ24ChesEC7WLbhwsmkWZe8eEOoPDTTfONWCFsXQssTk6jBEwtAbhL4SeKkY wsWw3dXjOuEiG22v2t6wEc4Gm8x7zb1mwplhjQa6FEBxlOYnVTo26TGmEHKUpbxsTsqRNQ0+m3sw o/bvKNylpMqguggFx2JR6Gw06yBZLIXUUsLZJ5JCKhJOwnGSEPw+UFfptjuqmgMzKhzO8mnCXddL 35u/p6m5rfXQjJ+EuivHbP57Iq43xuwTV4dGjWEZXO+qrA9Hm4qnuhPzy2ONVR57fKS/vfWNY0tf jkY3g3zXF/M+4l+RcuXlVWeWU9cVu6OKMmJGxSiCLie2nwrDjvDBMD4ReDeAj/nP+3HvCNg3AraO gFMF0FMAfQ7Y74A1+fAzEzAGnaHAQHJ4M+/lySEl7JTDWjnckVE/gItSyJGapV4puZppKYbRMQUM OU+gEzYBNlu8FmzEyWDRSGtSlZOLyixlWpeFK0lpWVeKe8YorxEPsd/SQfEj2sj/cJB/E/1MHYXU OCLiiZKa6UeJhNPrbDhbAJKphyEzEHH9w2T7W6dTzX/+pHHekakbyuoHtn1ur5gZDs+ssH9eOjFo uXI5EMMT6j7d1DB3bt22T+uYmks/nt3gK535w4+ry2sOl04OW63hyaWHcWV+oMrTM2pUz5RAjOot MyVJgPq9E9kSSqLvzrUa12tOuNB6qQup/5jOTMwMKm3wqWVkh6b2uyNUaXTrnw5R7QsDlQSe32rF mTq88j8nLEaVTx7gK7TCKlrhxYmag274uR122KHd3mXHrElvwn3Gt43XjKRP/7b+mp5w+jw9fkv3 ju43OmKx2YoNSUcx6VbYLBZPSb4450s8KY3ohDT3j2lp/PTVLu0fFBv3X3SXfVAU9xnH9/nt6+0d 7O69ctwed3Acp6ABOQFPpF6dy7lBkibpRGtVxqhBsRTCKG9edZoYrJI2BLwjvDhORonimZpMUhFq Z5qJIiq1ra2ZTDrTZlrzR9JW67TTqYq39rd3BwqTMLPcwtz+Zp/n+zzf5/Nce6zqvXMCIGeskWFZ D5mPjdCXtEIwF5aVzQRwsf3gxp5tZU21R60bsqHBVxD+QWObfQ4ykEcCi57btXrghTXCBLjIv/nX ZBcvacZRmrGPVNFGgiZEYn9w9TIRLmPbIqEchREKwFOALhFg0PO0gdbX8LSZp/Wg46dokWFpkWZq WNrM0gyH2CkaFJ2OpzMRy2Ny9a+8lnQke/GDQECjj6xZCAG7mJj/Pw1MUmVI5pI+D3jwhwe0toY7 UfjZ4SUUkg/3qc7DXXDBUVHmJD9QX4Kh/ulROKJuo6ZW4/lMEmfwrwuYiUyEk8gnNgVXHMqDPVbo M0JMeEc4K5CMYBXQiUyIZUIfC6+xkO8M8blhiQ7b+LiXyFGcTj5f0SOzooWQNqYAiOoNPLLEOeYE OWSyX3Kl3JRA4HdrPVHg8ZRpd7keNFa1Next2quqn4Bz+3Dziim1Mw7hUMHuNZNvg6T+/hU0mFH+ 9NblR2ubaa5o7b7vXl+d+PO/tlZ5PJGbnyd5A3vMKCZuB/F8cFmH7ZBtwEaOm6HLNGhCERMsNMEl HiZ0wOpsOnSSARsNDA2EwIYsp2VSsZN6RdKlqExUb12c662g2aXW2Zq1llfYHscz8vXAy+Xn2/e2 tV9Y1eaXO7vVt4+OHL/3ajvVZrNG+xP/7e11OluqzrwPObD84/OLcR3h3FMhnHs9kYUnRE2fFTqt UGCFSxY4awGf5ScW5MUSTAhkXyZ0ZkJHBkQYqGcgm4E9CHYgcCCIAKZKMIQpPiTF7TrFiHhF4mYj mIcNsw1TkXQjj0fyA8bMXE0SbFxWuH57X3Pz3ntdUbSrf0S9rn4GuUf++cKapyMDXf/46kBs+jYS 1S/fxxVTW7vuLzjfWv2sSsawOGjjEWL0ZIiNGwiFJFm9wiFKYR+VhfZCpROlkraE4PEqpS+oQnRi Gl8NKIo/P42orgjNRR47XUcUBE0UF2JJIs7TCscRlAKI4DRYTR98sVSrNf/MmdKZ5Fn4XHySWh1J DKerg2qhtUrvDW4fyIWrbhh3Q9wNr7uH3GjcBREXHHLCZRl+KcO7MhTJlfKQTJ53QNwBQw6odkCR o9KBjmRAfYbG+WQrBRYKGArMIVEAgQ3nnPaaJUUQvEjJIw2KXTcbvT+px6avFSRVXZ7Zwe2WyjAf YUqandjpKjvxo59uGWoI+P0vxoC4Drff2NIw2fzeqq5jQ/eO/pjaHKrpvXEw8pHSCeUvRyJ115r3 PP/cCOag1b8eD6bySZUl1SoMWnQhlqcghOIGWsHmzZKIR0kX8htntLpRit8W8LaI84ovjwRV3d2o Hl8bE8M0l/gdWnL/LtqYOhmqkruVOajTDqXwNqXpo52TOgM/S3P37+IvpZVdiW9pwh40ABEi4wyN cNUki0V7ZmJJiVfT0Y+rAyWauiO4JFLP0W3Ye2XiF8EdfQIcEqBdgAE9HNBDGwE7CNARAWI9QUZl iDqgXoRTApzSQz0PdjnTaDdm1sh2s2zPlA0cyAYZajiDmTMAJ8ucMWShQ5wl7uSMcoYxQzbivTAL MeZ0UmwBe3FWcbHWMapmbVKgqlica8nifIeev4Zo9mzBuajwsKC5B/g8NvznUs20/dT1Ir/ypo56 Rh11+Aoc6tizFNddXeaHcxR14Tu10zVkwZ+OJcZLS1HlmckHk9ToxtoHt7WcPPwftRnnxIKretN2 8aR4TiT3C/CSAGEBAgJYhQIBLWNgnIZ+GippGKCgnYIKCrIo0FEwIcI4A4KRYgSGqjEKZqNAWUKE EYxsiI9bGdaoyzAjpOMYojhVHhiRUrWsBTo33Pm85DXPC9Pm90l+avOT/kWJTzdSfHe4dBFaqN08 uz5Ifmv4wweD1Nj3v/3g4+MfkHUaU2g9uwv3rIC55q1gE+7aAfcpNyp0L3ejyy7ATdvugoWugAt1 OMYdVxxkPBsvXVCYvTwbDdohZoMTVohZId+61IrOWSYtqNUCkyYYNUGLCQ+6E0bkNZYZUZ8E5jBh AAMVdp7O45QsHaGI5CMj/ebG1Yh7ZiqkfNWHYVsSU2hYoC055eiHJ+u2bas7OVyHf4Zv9vT29tz8 okeprlZ6qOFo7/R0bzQau3s3Fu04d1b9g/rH0dHRDXf6++9sOEekJgWJm4fIxBpXBzM/M8GrTC9z jCF3M0COPfzyQ9GkoLGHd4I2fEOHjRY+ZIhbBYXnDRYlAxkeN0rc1TiSoiLttdOclOvB4uSSqRkM UztHWqp27lPvbe0G5xstoKgXX6G5kk0H1o1sbkl8jts+qv4npYwurUwxVqZheBHEFkFr0WjRpSKy dcHogksLyHd80OeDfN9SH4oVaEQ/4DnlQZUeKPTAlTwYy4OOPBjPuZKD9uTAKScMOqHIWelE38uC 9TbYaYInqIVpUdynSwjFSz7BKRYHNtXf3ArMCiMFvlGa+cqAFaMilsXLPCaOthtJGIhZ2xyZACTx SZtV/aveLqW1+gIrV/hMc/i3c0W7/3e9U6qRPkHkjGqaik0fHWn1dif1e3iP/Arrt5AoIY4Hmzu9 MS9qzYfX3FE3asE7jgtaXJ0u1GWFDitctcC7ZthrhikTHDRBvQl+boSrErwnQUSCRgmqJaiUYLEE v8LuJkKMhLMI6hDkhReXkPaQI75kQaFitztKFBk5OFbJTJrqIzK7VVr69VjwKGsaC8xAThKscaqS uOBJs1tyabT40thWvLbCWmiuWCflGMSspXJJzcoKOa9UCjc6u6GsYWR3VWGhv+fFf/fBSnViEK11 7K9oXNZI000cm7Viy1NrG//PdtkHNXHmcXx/z74km83mZbObQMJLwpKAwUjNkiBWIG0hAiI2IgR8 AaWKoKPiUFCK3tXaHiI4HpqrVbGlit6pM/bmtIpO613nnPNlenpzb7VzN3Z6vT+uPekfNzedzgjx nk2CetYwWRZmdvZ5fr/v8/1+fukd0xgpfE27llVu8SnzGartP1+pKbEJ01w/VpiXOB/awXpgpQy8 nCkjzgm0GZYaIGyAgAEEA8Q8sNsDb7tPudFG+ayMTudAswvmO6EmG85mQacVDgswLMAZM4yaYa8Z YgmkesUAA/whHrXz0IBjyBgmMiHTpg3nni3g8h1OkazKJx1VIvt4QFTr97s/r5p+bO5P1+6JQE8l eqKYyYnLk1dstaawNy81MdrIgpJdVaH11XljNbFFY6Vb31sTObdGbDqxBOzvLTq4aGxn7weHdqkc mRFYPHfPYrkip/3jhoFVc/M8u32+fw7X51TIr3ww3royT60Znk7I+1hrGiIDT4FjdAUxxjBaSqMC U/mkvxwKv53+Fs+AATVdZbNI3o2v/Cm1r7//QTe1Dz8/jv22ET9vJRaFioJiWGwUyaApbGo0kRvZ fhZ1avu0aCPVT6FOso9EUKG+lMd+YyN4JFQxiVo9Zp2ZBFTM4owfYpKYOZHk9f2DP/rjnR9Xhvev bh6JNayhtVOxz7d2tJeMbSB7pkbfj9bWNh5Xd4VXpfIFT7SFnruhg+saDL0cC6y+lmNFjtVzt1mS ZliSpWsZVmRYmrnNsiziGBxc2P1UplEHqx+OVc8YqtyJaFbAoljwFXXbFMUWD8SgsJFqBN9gPJhX Wkp9OXUx/h3oyJoH2cn1MXm0iciA7lDVpYzrGeidDOjMgOIMmEi7kYYOpcFgGrA2aBY6BVQnACvA dQM0G0BngEv8dR6xPFzWAaODWyyso6GRBnri4aeh2Xx1kIYBAsqsm62I3CCBVGWorpMALZAgUwK9 BFYRFgiQJQA/8XAitENX/bIe/PoX9cithwgHRVwFh2QOSFIHiKdhEwB08NWlAJsJaMVrx3/MIcqw TVXpqg0EhlmSYAiqFqMcSVDkHYzZZosomSVLrSiJomQR70hGaQl+UCKkrExCkkSTncSspDGxCVLC /cXVVgBfMTIVrjIrT1cZzEq6aeqHsFSwSo0l/G3FP4lPQfJXK75pVY9WwTPPnFsptigJoCLzZA2Z ah/+p3q6qCbqxfhQvMfqD5g/8lFzPzaWFknxXmxGdGDCWFJk/GQaN9FV/gKampycpl6opD5/cHma 5CsXJumDPEiO463mE1tDi3tdsN4FQQdcsEO12CzeFMmjJhg0Qb4Jawl0mKSMcMYIR40wbAR3iDNU 6dWLjoxYT2XVC7PkKM9pdCSTHsUHVHVlNcTuTU5N4pmIKCh4ip4AD2X4rMj40MgJG1YNg05OoTjW spDiL0MB1FY2WJs1wHHU8s+W7Wr27R2ELufC/HMts71Z8xuCobWVbnKcN0z/67t+Z33g6vwto233 R94e0DLbgoMNNb1LZwda3qjDez2I97qfLiEEPB+tCb3U6ICoHd60xWzIagONDTq5Pg6dZi4z6BYN p+nLNKqhYR4NNym4QkF6vfbnFiLizCGcOjKayfFRKbFDvEconPRPPZ04bmvCAnAqq8mi+mQyiGdG HqwiBbLtpbnja30FDntZd3BFKJdqunC8ZfWxfXfLdpYPU+003RccjIS3+to8L7UUf7Nv2/Zffz+y W6+jS6bvpeY9Uou7l0WUh2ZdSb+VroIFzoLlVtggvSahFRKEOQjTQJi19TYy6tDwUQuXZL7CyU/9 j5f8yMvVmqupqFpZ0r6tNvS1t8FXs71hTsHLmytK1vnSNrz10Y7+n7z5+3krZVIw8IG2PUsXv77C n2HvKdm+/Q+fjRzgDSltDeB6Gwg3MRJat961zYUuOqDK2mRFGAKqpWYJHRVgUIB8AdIF0Alw2awm 2FEzDJthlhnsOMpMsE0L7VoopuEilZQcp17kjIidOKWpt3icOgdBRm0aNmrkZjqias7/bNE9uWMM T6aExuCJ7Sb8O6lJ9LVc7T7XsuwrVWTxu2eXN+7Z+01mhWdYGKBpajmZqWV6Ok7Fr6gKi7tf7frt 5IEYo4UTU/Nunyio915NVWEZ7hFPeIhNoao8V7ELXXPCh07otMONNDhihWErcFboMcL6xEhzSQ8f cnBNB4Sh3mbJrieY5xjE2PJQQ26upMVNNEUlLpXYKvLe+/uqSb9p0v808lhSVCjnJGgGufxqX53m osdCVJUYb6iMRSqOzFsz2+s3kTDnnQ55/7vxJX2v/7Wvrqn9+dNdvqVI1BcXhrflezzrfhn/TWhL Nfzqbmy0uLR3R52vgFaV6MIYuIWuIdKI/JBVp63RIiktQiOU1kBLjBDlgNCpjF6uTPqhUEmsVaXy gJICVKtNo/ZDkhRJhprhY8e83oWveiN5FjnsHPziC9LVdaCu2xPiDf0G/vhoF65rR9xC7sZ1NRAK sSe0+jVlr4J+5j3pRYzX6kXN2TezEWaj5iw44jjjuOIghxwwywF2B7AOGLKftaNeLayfkVXaI1nl RqzEqUJNfWaRP+oz5jJk1IWFlT4jrISbKVhaz1bW/4vKUpRgoIS3PSEvUUiVHrOS4kT3c2ckFnYL CCHsckmdYdfTry35xaYL3cLhLihJiK3zZEpsrKDkyBmZtqtYdP+OxbD9fVIe/77p4sYFz8/rL8Md GcWcNI5Pn0TUhYTDutM6dI2C8xQEKaAoNUrvntcZq2Di4Y2QhG8Ic0TQRLQnBZHQmnVcFCXMTcHe NjWZ0Naj7UJSPeq8m/RpfKfg49r0t3eblg79o2exJ39oiNSONtW/MT2Iar6scTcHp/+ELesO7loP FkuAFgkzXldmyEi28O9bIqLEiDptK0EQKTf9Ly6vxZ9CSjUVypAFv+Uv3qAxXZYkOd1ossvRYVoM ei05dqPRnmORZLshvnNqCzlCoIe98f9RXq3BTVxX+J67q93VSrJWWr3Wsi1jIRtZuMJeP6LU2MIY Y8AGywbkBybB5WVCXCY8HUMILZSH3VIIgYSQGVooNC5pA7jUmNckkAAmaX4wU5JOaKY/Ms0E6GTS Px2w1713ZRsb0pl29Lh37/44j3vO+b5PJuhHrUxA6VEbtZIe8/m4lLjbOmLnwX8zpO/p1eRRJvdl dmFS8mObkypbnl1QZa8o29X5pPWHjvIVFRO9Hd4j7IpHh+gNEFXUQm4gBXVF69+xw+c2KnMu2aDV Bn+V4GMJrkh0vnVIsFqCoATJEhxk4RoD5xi4BnACAHmTFaR4G5IVR7JC9owj5krmHIri9CCnKMST RD1l9ohN1VEoL0zZRkiC93eyI2zvqRp1jVU/tDLJJ3GHKsCvCdnOLpYLSqjWyXx2W63ruRlzOzth 53taOXyXNK90zmJbmEgba3PKbzZN0GoMkYG/wcvaEhLvwaFv4BaJ14wcUSMfYzlkjGO9cYhruVMM xJbOjalhuFVS2ttZa8twgLOHfevRxlpeoHNkK0KGHtLVIfRKdL4rlBkqDDFsCN7Phj4X9JnhKg+Z XCGHnRx8YIBWDGWTaie1TGLKlFqlRWE+MkBmaiwNkZoyxsRjjmNpky1xlnXHg7yfM8pyKskXwV3S x6pEW3mAFnckUd/NY7UNqfKisXVOoHHcJjNLJTlUdXUzN72ucdWh2MzODwsapwW6PihoKsvslKy7 BTPDLr3yaQH+dmZhUX3NDr0bJs1YVDB4+/FGWXthtqc850jPcPTMCRJ98mjPfvg/9ayb4///nh2O AfxL7zxu3ITbT3XviJvDeNZNfJQJi6qKqkv96/y4zg+tvnYfbvRBYypsVuAFBZoVWO7a4MJ1LnDU IbHOGzCQUWqNu4f5B5mjX4zjTJD/A/yYg5TgIgdOjE1yE7r7jDKx/Pmp01tnZU2cTtfZWfu+u3h6 zfqpxcVvLe55cT3cqd7SkJvfsmcBXQuW7Gn6TPtqU8ftttOVMys2vkJ836plMoeJ7xIKoqboVM7h cuDZYqOIW4IvBfHHbuhzw0EH7JBfl/HLVmi1Qgt+CWNXneVkVioX803k0pKEeLIJxW1juZ9O/tBo HOSrl4lLB4F80l15aXiU9o0pHmzPW1DqL141a21NqGBaU+325rz9HefUhYGR6qlnQpT4acuLCpf9 snFP/cr20nXHlw92rZNtmof513DpIHorJLL1Ohr60NrovH43zHE3ufF5F7zjgN/JcFiGThmyZTDK iozP26HTTkjVBgEn8K9KWiThalOzCafErJRVOdPTklII+CkE/GxPsCo91ieZ/DjgY8YDnt82jkex VZ+NAlzXeAr1eU+CQ1mSHr6NNyU6Am9kziAvUqJm2RgzsYToSZxI2YROYkmVAzH9PY1JSobHq8xm s2Xashl6So1mzC6+Sg6SLIwPZ5Y1qMOV7Z2nXsb7aAdWDn2De0kes9DqaGUwI5KBxYzkDLzIB8E0 yLeA0xKwYNYC28UD4nGRqRXBL8InPrjog76U/hSMTHVeO1uXzgdcqRKOB3hXXBrhakQvEofVL75v 2lDu49DHsnMEf0bkQxbNZAlpCTdun7/+VnvbGqZ9Sv3mql/st1duL67LS89ov9ue17S1qu1HjODf Ni8vJ4Sr95QsqwhEtqRn+OSirPqCReU/LV5SHkglEQZJhAvZg1TxRZ2WdItc6cQxu9WKFxBewhni Zt1d9ZNRooZC4PQnprab02c4oW1kjuPcu+3OqVnSlJqMe0ePdjL71gxe3GYUXzRZ7uLGNWDQHhFr e8m02EowWUYLo9N+Jh+UsWhJtmRbui19ln4L123uM/ebmeNCj3CNCBm+h79G5C3v4jN5Zje8CZiN MSdtMYmxcSguJjwjORwjtgJ5Noopw/hNthIW7neqz3fVN3QtUbsWA4dzBs8S2Th5csO2+bh68Lb2 kPglEr86iF8iaohmI6PAI97YIPAOgTcKfTxr4HiWNzRwvIPjDVwfz/NY4DgKZqWqPRIGJTxIgdYT kuhCkBYU6YmT3CkB2gUUU1UShxIOe7TXD0AAgnu13YEfTmVWDTrxvYEDKOGNYR/zBmHPd6Lzdnr+ 5MHtHtjl6HXg6zK8Id2Q8G4JPjLDTvMhM75ugptG2C28KdwUmOss9JIvhl64AfiYfFbGm2WQ003W yjoRZogg9g6tPCPOIsuuaMQ46wyCYwg2I5iDmtALiClGEEJAcOSCZJYvikwMXxBYdNHjEJEs25Nc GNs5LonErVLcJBUcVknwquoZzMtTBj0PpOF1dP6FQuT31HhoDhTJKtB8MFk8k8iLLNOpzuK5Z/Zq Z135BcqR6RXHnc8UOLXLBwb+4YwUuU99hdHA/shMuPr3u1puaYRpG/Ti7rIymjGClDvI/ZkI968+ Z4LzAqwW4KYB+gyw0kD1U5sJzgnQYjhjwIjnAAHfwIGDA567BILByDKiUWQbGNHBiCw2iZcY4BiO 5EsPFcJ/uR+JJLjUyA1HIh5pYNzRcNDDsap+SFw2+OG9E9Cq/eoPkARJJ7TDsPz32n24Dv3afmjT SrRcWEtvfS9RMLQGfagyGl7mhH4OLnDQzYGJ83L4lgGyDd2GPgMjx5D9pEeMGb1xl9UucpY4k+gE fQAmxMhImqnUGO4DXfzRzYQEmyVPeICd/WX1hppg16ebK6KdWvj0KnnN8T9Wl//2crjx1ZjeHdpz 9T+HewM/1mSiI1Ys+jNFly1MCB9lHyIr8bUtak99xuisTKF/Rq/iDXoZd+/Qt1Gnkl5poYdm/Y1J MQVNDE/enCUvUnuHvj5LjgmH+TpqJxvmlJUkWz6VbHC+ayZzs1S9TwbOAyJlE7QlRCqJ/hCdiAlu TsaPkx3/iCP5ak1qftDTUV6uXVHVmhS6nz6d+XdOOFiZXjQr+JPtOU0zCifnhEaeGmbSiOYyQfwa +089orrzSBm6Qb3z0DhMZkKxPDbPBA9j7E2cC/RcoeeCTZggMK5TVh/4uFNWj/CuDcY736y7bVcT mJ9FB3hmwcTxjztqlGCa7T/cV0tMU0EUva8tr0Br6Q+pKGE0foBqFb+08VctWqD4gSr+oj7sA194 /eS9Um3ib2FMjDERNW5c6MKNGiKJxmiiG3Rh4krjyhXRuNCoCw1+orHemY6I+MFE3Tg3r3PunTt3 7jt3pp3empeaUCGsWuNB3E+x6WX5jEDlpcyi1rbJVdWVjVTr614UXU81umOwDsJWVofAUudPuWYc FzOOiwt6rZjec3YBhzyrzm8pfDeMtbcjeBIoT8IKxpP3OhQNY8PxlQ3kobBXGFrm+7cf9rojXhFo Iz+UVjiE0geP4I1QLgSFHuGBoclwzfDeuNb40PjQdBjl7hcpWIxyTrSK7eJt8bV5vPm0+Y55gMnH wkOFg0W7ivqL24pfW45aei3vrOExc38gF2wuW7vtScmGkh77RLtqP2N/5Njk2OP44Gx2XnR5XAdd N9wz3DF3n/tt6bHSV2NX/qH0lVnKQmXd/6Owuhpw/9DmBiNFQjk+IozajLy3WMFWYnc4Xe7SsWWe cXgFrKDmSTB5ytRpVdU13ukAM2fVzp4zd978BXX+wFCAUP2KleGGxqZI86rVa9a2tEbXrW/bsHHT 5i0/WXDf/j17R0/r7zUTHIP8rjexvhrmQx0EYAk0QBtk4TicJB4yjkwgFbkc86gCL/cIQgQk6IET Xz1yj7+TF7mnAx0o2we28xr8uhlH9bDCqaFIEgDHRrxFShybEGc4FhEf4dgMtXCW7gBTEWr9cI9j AWqEExwbwCbc5NiI9rscmxAPcixCjaGSYzO0GxrOk0ZZk+NZEpUSXZIWI7V+v99HQrKudCbkGKnf vUPt1pWMrGZJR1IjUVnV05pElie1VFKT0koyQSJKXEnLMR8JqippUTp3pnXSIuuylkFjKNzctCzi DUtaPJnIhhQ9pUrZ3zdyjXCVKDqRCCYQk+OS1kWSHSPy98F5LHUjyKDhE8eNQCCK9CbwniahLYZ6 LfiZ+BCH0EsHBTrRQ2aj9bAbdoAK3cyeQavKonRAEufTaNSiQxo1CfXlzJ5inxJaFUQJtEcQxfFJ s7h0rSDOU7FvYevtxBGdaTQDmm+Ge4YgDM3QBMswhhcxzTvOomZxTEHvFMaRUKNzOzFTlfn8/rx/ 4fntGBkxSphGGGN55mKsPnROF9qSyO+v6+YDfmKe4aAZDSLueDvMxN84gE8FB9g3pZD3ORsK3tpW snAQ/5Ow43M5MOk+7a94ntTlMp9c5iniVXbyDPnD+FmAAQA99pbXCg0KZW5kc3RyZWFtDWVuZG9i ag00NzMgMCBvYmo8PC9MZW5ndGggNTk1L0ZpbHRlci9GbGF0ZURlY29kZT4+c3RyZWFtDQpIiXTC 43PbcQDA4e3Fbi92u912s3Wzbdu2b9bNtm62bdu29f0pbpw0Tdq0adM29Wf5B/bcgyiIyI8ogCiE KIwogiiKKIYojiiBKIkohSiNKIMoiyiHKI+ogKiIqISojFQFqSpSNaTqSDWQaiLVQqqNVAepLlI9 pPpIDZAaIjVCbozcBLkpcjPk5sgtkFsit0JujdwGuS1yO+T2yB1QOqJ0QumM0gWlK0o3lO4oPVB6 ovRC7Y3aB7Uvaj/U/qgDUAeiDkIdjDYEbSjaMLThaCPQRqKNQhuNNgbdWHTj0I1HNwHdRHST0E1G PwX9VPTT0E9HPwP9TAyzMMzGMAfDXAzzMMzHuADjQoyLMC7GuATTUkzLMC3HtALTSsyrMK/GvAbz WszrMK/HsgHLRiybsGzGsoWYrcRsI2Y71h1Yd2LdhXU31j3Y9mLbh20/tgPYDmI/hP0w9iPYj+I4 huM4jhM4TuI8hfM0zjM4z+I8h+s8rgu4LuK6hPsy7iu4r+K5huc6nht4buK5hfc23jt47+K9R+x9 Yh8Q+xDfI3yP8T3B95S4Z8Q9J+4F/pf4X+F/jf8NgbcE3hF4T+AD8R+J/0T8ZxK+kPCVhG8EvxP8 QfAnwV8k/ibxD4l/SRIkSSTJhBRCKiGNkI5kPckGUoykmEgxE7YQjiFsJWwjNdpOqoNUJ2nRLtLc pHlI95IeS8RHJI6In0iAjOh4MhLICJIZnUhmEpkhsqKTyUohO0x2Ktlp5ESnkxMhJ4PcTHKzyM0m LzqHvFzy8iCafP/xT4ABALeLVcIKDQplbmRzdHJlYW0NZW5kb2JqDTQ3NCAwIG9iajw8L0xlbmd0 aCA2NDAvRmlsdGVyL0ZsYXRlRGVjb2RlPj5zdHJlYW0NCkiJzMIFU1MBAABg/xMlCEhKi4C0hKSA IimSR4c0yCENkgdKSCklnS/23lt3s411j23oO3+F332OjoCDA+DkBDg7Ay4uwOPHgKsr4OYGPnkC uruDHh6gpyf49Cno5QV6e4M+PqCvL+jnB/r7Q8+eQQEBUGAgFBQEBQdDISFQaCgUFgY/fw6Hh8Mv XsAREXBkJBwVBb98CUdHE2JiCLGxhLg4Qnw8ISGBkJiIR169QpKSkORkJCUFSU1FXr9G0tLQ9HQ0 IwPNzESzstDsbPTNGywnB8vNxfLysLdvsXfvsPx84vv3xIICYmEhsaiIWFxMKikhlZaSPnwglZWR Pn4kl5eTKyrIlZXkqipydTWlpoZSW0upq6PU11MbGqiNjdSmJmpzM7WlhdbaSmtro336RG9vp3d0 0Ds76V1d9O5uRk8Po7eX0dfH6O9nfv7MHBhgDg6yvnxhDQ2xhodZIyPs0VH22Bh7fJw9McGZnORM TXG+fuVMT3NnZrizs9y5Od78PG9hgbe4yF9a4n/7xv/+XbC8LFhZEayuCtfWhD9+CNfXhRsbos1N 0daWaHtb/POn+Ncv8c6OeHf3dm/vdn9fcnAg+f1bcngoOTqSHh9LT06kp6eyszPZ+bns4kJ2eXl3 dXV3fY2X39zIAUAOggoIUsCwgkBQIogSRZUYpiQSVSSSikxWUyhqKlVNo2nodA2DoWEytSyWls3W cjg6LlfH4+H1fL5eINALhXiDSGQQiw23t0aJxCiV4k0ymenuziSXmxUKs1JpVqksarVFo7Fotfc6 Hd6q11sNBqvRiLeZTDaz2Wax4O3393arFf9gsz3Y7Q///ME9+g/8FWAA8HC9QgoNCmVuZHN0cmVh bQ1lbmRvYmoNNDc1IDAgb2JqPDwvTGVuZ3RoIDYyNi9GaWx0ZXIvRmxhdGVEZWNvZGU+PnN0cmVh bQ0KSIkEwWdQCAAAgNG//equq0tTCqWQ0FSRhkQaZlNGokGltNNAGaE9lSISSdpIW6S9i9KQjEJC ifi8x6NHlJdTUkJREQ8f8uAB9+9z7x537nD7NtnZZGWRmUl6OmlpJCeTmEh8PLGxXL1KVBQXLxIZ yblznDlDWBinTxMUhL8/Pj6cOsXJk7i7c/w4Li4cO4aTE4cPc+AA+/djZ4eNDfv2sWcPO3dibs6O HWzfztatbNmCgQGbN7NpEzo6bNiApiZqaqxfj4oKysqsWoWiIsuXs3QpS5YgJYWEBKKiCAkhIMCT J5SVUVhIfj5373LrFjdvcv06166RmkpSEgkJxMURE8OVK1y4wNmzhIcTGkpwMIGB+Pnh7Y2nJydO 4ObGkSMcOoS9Pba2WFuzdy+7d7NtG0ZGbNyItjZaWmhooKrKunWsWcPq1axcyYoVLFuGnBwyMkhK IiaGiAiCglRU8PgxxcUUFJCbS04ON25w6RIREYSEEBCAlxceHhw9iqMjDg5YWWFpiakpxsbo66On h64u6uqsXYuSEgoKLF7MokUIC1NZSWkpGRmkpBAdzeXLnD+Pry+urjg7c/Agu3ZhYYGZGSYmGBoi L4+sLNLSVFeTl4e4ODU1VFXx9Cl1ddTXU1tLQwPPn/PsGY2NvHzJixc0N9PSQlMTra20t9PZSVsb XV10dNDdTW8vPT309TEwwKtXvH5Nfz+DgwwN8eYNw8OMjDA6ytgYb98yPs67d0xM8P49Hz7w8SOf PjE5ydQUnz/z5QtfvzI9zbdvzMzw/Ts/fvDzJ7OzzM3x6xfz8/z+zZ8/LCzw9y///gH/BRgAzO/r 7woNCmVuZHN0cmVhbQ1lbmRvYmoNNDc2IDAgb2JqPDwvTGVuZ3RoIDQzOC9GaWx0ZXIvRmxhdGVE ZWNvZGUvV2lkdGggNDg4L0hlaWdodCAxL0JpdHNQZXJDb21wb25lbnQgOC9Db2xvclNwYWNlIDQ2 MSAwIFIvVHlwZS9YT2JqZWN0L1N1YnR5cGUvSW1hZ2U+PnN0cmVhbQ0KSIliYGRiZmFlY+fg5OLm 4eXjFxAUEhYRFRMXl5CQlJKWkZWVk1dQUFBUUlZWUVVTU9fQ1NTS0tbR1dPT1zcwNDIyNjE1NTMz t7C0srK2trGxtbO3d3B0cnJ2dnF1c3f38PD08vb28fXz8/cPCAwMCg4JCQ0NCwuPiIyMioqOiY2L i49PSEhMTEpOSUlNTUtPz8jMysrOyc3Nyy8oKCwsKi4uKS0rKy+vqKisrKquqamtq6tvaGxsampu aW1ta2tv7+js6u7u6ent6++fMGHipMmTp0ydOm3a9BkzZ86aNXv2nDlz581fsGDhwkWLFi9esnTZ suXLV6xYuWrV6tVr1qxdu279hg0bN27avHnLlq1bt23bvn3Hjp07d+3avWfP3r37gGD//gMHDh48 dOjwkSNHjx4DguPHT5w4efLUqVOnT585c/bsuXPnz1+4cPHipUuXr1y5CgTXrl0HghtAcPMWENy+ fefO3bv3gOD+/fsPHjx8+AgIHgPBkydPnz579uw5GLwAgpcg8AoIXr9+AwZvQeAdGLyHgg8Q8BEI PoHBZwT4AgNfv35DAd8RACDAAI5pJ1cKDQplbmRzdHJlYW0NZW5kb2JqDTQ3NyAwIG9iajw8L0xl bmd0aCAyNTAwL0ZpbHRlci9GbGF0ZURlY29kZS9XaWR0aCA3MC9IZWlnaHQgOTMvQml0c1BlckNv bXBvbmVudCA4L0NvbG9yU3BhY2UgNDY0IDAgUi9UeXBlL1hPYmplY3QvU3VidHlwZS9JbWFnZT4+ c3RyZWFtDQpIiXSXiV/VZRbGwY1EwH1DcclyS9Pc2qxmmhnBi5qEuU8qprlrZc0Mi7mjlrk0NYYo mtoyOXpB4BJbaAoEXhQBgYugFy4CIv4N855z3vV3r//A8/md7+95nnNeP/9Onbt07RbwTPfAHkHB IT179e7Tt1//AQMHDQ4dMjRs2PARI58d9dzzo8eMHTf+hQkTX5w0+aUpU6dNn/HyK6++9vrMN958 609/fvsvf/3bLP/wThFdZgfYnomc02PuvHfmR70bvaDfewMWLlq8ZOmyYcv//v6KZ0etXDU6ZvUH a9YymQ8nr5sydf2GjZs2b9m67aOPP9n+6Wf/+Oe/YuP8wuMjEmYH7Pg8cqeU2fXe7oWL9izZuyxs 334mk3hg1cGY1YfWrP1i4pcfHl731ZGjGzYe23x867av//3J9m8++/Y/J2Lj/L/r3CWhG5MJnBOU FHKSzZR8atfp3QsH7xmyN2XYvv0jz5x97sD3B2PGHVpz7vyFL384/ONX045uePnYq8dfn/n1T2/9 /N+3v/3lxCw/RHPRtqN74M65gOZdQrMI0SxnaJgMoPmAoTl/gaH5ceq0ozM2MTTbCM3/Ll22s5kA zUUbEJ4b/A6Tie7L0AxctDh06bIwjub50TFjBRpGeP10geZNhib10gmFRhDuzdEM3gOE94FM4kpC c06gWc9mYjIzGZqfv0m7wmbS0OxENFF9khcwNIMsaMaOO/SCQHPk6AyFJj3tymW7QBMg0fSO7nvK yzXfk2sYmh8AjXTNT9szMlMvXY6dhWi6WtCADLiGoRlBaIDwWmE+DY0jIw3R+BMabr6T3DUDwDVL vV0D5gM0wjVZv6YDGnBNPKGJ3Bk0N+TkfO4aK5oYQPMFoEHzEZo3sknGToS7csKEJvlU/9OEJmUY dw0jLFxzWEOTk+tANPanomHmWyoIQ6BMNMx8W17blped5ZCERaD0XHLXhJFrDvBcEpophGbL1rwc NlNGJkfTOYKhsTGZoKR5iAbMNwhyiWhWnE0UgdLRbD6ejzKExk+gAdckYdcAGiSsoRkD5ptw/sVJ lEtA81tBXk5uVgY3X3inzgkSTUjPKERzGgM1NGU5oaHK4miQ8KZXrl4ryMnmhClQmEuzspgMdo0I 1BiG5twEgWb6xmO//5bP0aRioICwhgYDReZDNO+fITSrTTTXuQzMdMmuctndcA37UaEWNOMhlyxQ 6wDN9RtXQSbXAYThd/tbXcPbfDGvrBVnLIGCyipkMteAMEOTBq7xl2gCOZpkXllLRGUlisqCrkHz FRWyma7R786kXH7HzRc4p4dPNOCaVQfHcjSssqYcKS4qvMHQFJCMz8rScgloeC7H6JX1R1GJmEnl UrT5HF5ZfaCydiMadM0Zo7LYTKXFSsaRkZ56RQaKu4YRVq4JVWhUoCZNXnfzj2KOJi8ny4FowMOs a2aTa6iyOBpmvpQwH2icTKakULiGzZQqctmVV1aS78pKZDPFCNeU3eQzQaCyHYQmVkMjbwCsrMV7 xKIjNFBZEy9MuiVlhGtSeS4lmiTrorPcAAzNbSYj0BTksVymi+ajNqdAofm0U0JUlmjz8tu3nDeL GZobMpdsKdipzS1oFtANAOYbznMJrmE3wJ3y22XOUiZz/boWKESDlWVTuUQ0uxGNdA0/jyrulN8C maJCK5o4iQZzOT9KoQHCtOhWjWZdM35tZQXOhIQ5GugaFigLGggULrqBHM1+zXxVXMZwDVYWkxFo AlGml4lGVda4Q3erKggNC1Qhm4mjSeVoIgQadQOA+ULBfFqg7rKPATS+XAPme8oNAIuOoRnJ0VSj jHTNDUSTRZWFF4l2A0jX8FyCazBQMTXVdysr7xCaohLRNblQWb+IXKrLUXcNEh5JaGprqqsEGnAN mU90DbomwUDDXcNzydG4amuehgYXncgloEnCAzRau82hzWHR1blqlAwF6qpAI08JWVn8PJJtjrk8 m7iyjn2MIOwUuczX2hxcE2FBg0c13ubcNfdQpqqqEtGg+WhDZWtXFpwSNt7mxg3AczmqHmXETE5C 87uORlRWgHANBOqUWHR0A9TX17lctZaZkHB2rnSN9mxJCjafLUOxzRvoY5hrKoySKMCZMuXJF6E/ FGRJiOXd0FBfB/+pWs1UzNOtfjfcNfS72Yaap518lIThI+7Lj1Hpxpnyzd8djzPpJaH35wNNpuKO XhJwHjmgP1kS4vjvtmlbV7w3YEO57zc06P+J/25Igti6qTwJEXTy9bD2596U5e4HIAP/Sclo/clm SjeToLauhqbRzWdyIRqYyUhCrn4N85MvSJTELoGm0e2WaGqoJMpUfwLhX+m9QUlgMuJ5GQVJ4Gia Gmkmi2sQDbgmz0wCQ2NTJ19fWt6hQ5qETJ2RbstqMZKwQ/Rnb4nG09So0FASysvJNXK1yGsYZCzX MK0Wj6dRydSK/ixTJUFoMk00kXK1EJpmD8xEMi4siUoyX6moYYnGLt8buHXVyTdwULPHo6Gp5a6B 381kEI26hgWabgHiodCLPxQegoz4mHvcNVQSpcI14qHAty7PZZB8KPQf8LAZZSxotFzyM9ahVoux vClQLSCDMykZPVCFGKi8XH4Nx/JcXsS7JligAZVmhQYIV5P5blmWtxko6Zoolst+LS18JrcZKLl1 S7T+FKsFzyPcUPPoGm71lqmVuXSqky9HuibO+65JbuUy6Bo9UJXcNfrJp13D9BTjqyW6jcnQxzS5 8WvumavlJs9lvva8FK7BDYXPyzb8mIfm73bJGoZcFhf6QpMgzAeuaWtr9YFGypQ59Ws4Sz/5umjL u80ic99sc5ip2FjeomvQNUQ4pOcjkjHQQNdI8znl1qVAZWpvKPlKffTI+BgynyJcXu6FJl1bdIQm KPiRRcana0qtrrlsj5No2LMlqV3IPBQyD3xWlrdr5KJjaEiFf41H5LLe0ub8cgQ02TiTvAEITXt7 uzGTR6IxAlVqBioNNlRcuLxrUMVA09T4wMt8Tqe8hmWg7NI1n0c+tsrQTBioOnJNhVze+skn0UAu QYXP1EpJ8CgZ/N3GQ0HdAFf0G+CxJtNiVBarYWrzKusbKtu66GxCxYJGD1Sljsa4hmP5yXex4/Fj A02zDFSDaT6eS9016hru6KCvaWMyrbr53BKNbHNAwwNluQE6rB9jzKSfR/IaxgNUXY6ApuNpMiJQ dS6vy1F7XqJMfESHt4z4T27r5VhmPi8dwjXh8R0kI363Nd48UHeVjHSNQAOBeoIq7fJj2phKS7PK pWE+6hrtDUU3gF/4kyc+ZjLR3NNOCe0GwAMUX6mz/J74lLGicRmuKZE3AL6h2JX1fwEGAOt9jsYK DQplbmRzdHJlYW0NZW5kb2JqDTQ3OCAwIG9iajw8L0xlbmd0aCA1MDgvRmlsdGVyL0ZsYXRlRGVj b2RlL1dpZHRoIDExNDEyL0hlaWdodCAxL0JpdHNQZXJDb21wb25lbnQgOC9Db2xvclNwYWNlIDQ2 NSAwIFIvVHlwZS9YT2JqZWN0L1N1YnR5cGUvSW1hZ2U+PnN0cmVhbQ0KSInswWNvngEYhuHOttnZ tteus23btrdu62zbtm3b9v7IPi37cidXzjR38vRNjyMs7L8EpoRSIiCxlMSUVEoGJCdSKClNqaTU QBoprSmdkp7IQGQEMhGZlSymrLGXzZRdygHklHKZcsdeHlNeKRzIJ+U3FVAKEoWAwkQRpaitmFKc KAGUJEoBpaUyprJKOaI8UEGqaKokVQaqEFWBalJ1Uw2lJlELqC3VMdWVIoBIop4SZaovNQAaEo2U xrYmSlOlma250oJoCbSSWpvaKG2JdkB7qYOpo9KJ6Kx0sXVVuhHdgR5ST1MvpTfRR+lr66f0JwYo A02DpMHAEGKoMsw0XBoBjJRGmUYrY4ixyjjbeGUCMRGYJE02TVGmEtOA6dIM00xpFjCbmKPMNUVL 84D5xAIlxrZQWUQsBpYQS5VlpuXSCmAlsQpYTaxR1trWKeuJDcBGYhOwmdiibDVtk7YDO4idxC5g N7EH2EvsA/YTB4CDxCHiMHCEOAocI44DJ4iTwCniNHEGOEucA84TF7xcBC4Rl4ErxFUv14jrwA3i ppdbwG3ijpe7xD0v94EHxEMvj7w8Jp54eQo88/Lcyws3L7288vLayxsvb7288/Ley4dA+BgIn4Lg cyB8CYSvQfAtzvke9/wIaT9D2694//yO5+9PSPkrwAAC37scCg0KZW5kc3RyZWFtDWVuZG9iag00 NzkgMCBvYmo8PC9MZW5ndGggNDAwL0ZpbHRlci9GbGF0ZURlY29kZS9XaWR0aCA0MzYvSGVpZ2h0 IDEvQml0c1BlckNvbXBvbmVudCA4L0NvbG9yU3BhY2UgNDYzIDAgUi9UeXBlL1hPYmplY3QvU3Vi dHlwZS9JbWFnZT4+c3RyZWFtDQpIiWJgZGRgYGBiYmZmZmFhZWNjBwIOTk4uLm5ubh4eXj4+fn4B QUEhISFhYRERUTExcXEJCUkpKWlpGVlZOTl5BQVFRSVlZRUVVTU1dQ1NLW0dHV1dPX19AwNDI2MT E1MzM3NzC0tLK2sbW1s7O3sHB0cnZ2cXV1c3N3cPTy8vbx8fX18/f/+AgMCg4JCQ0LCw8IjIyKjo 6JjYuPj4hITEpKTk5JTU1LS09IzMrKzs7JzcvPz8gsLCoqLikpLS0rLy8oqKyqqq6praurr6+oaG xqam5uaW1ta2tvaOzq6u7p6e3t6+/v4JEyZOmjR58pQpU6dNnzFjxsyZs2bNnjNn7tx58+cvWLBg 4cJFixYvWbIUCJYtX75ixcqVK1etWr169Zo1a9etW79+w8aNmzZt3rx5y5atW7du27Z9+46dQLBr 167du3fvAYK9e/fu27dvPxAcOHDgIAgcAoLDR4DgKAgcO3bs+PETIHASAk6dBoEzEHAWBM6dO3ce Bi7AwcWLFy/BwWUEAAgwAKPq008KDQplbmRzdHJlYW0NZW5kb2JqDTEgMCBvYmo8PC9Db250ZW50 cyAyIDAgUi9UeXBlL1BhZ2UvUGFyZW50IDkxIDAgUi9Sb3RhdGUgOTAvTWVkaWFCb3hbMCAwIDU5 NSA4NDJdL0Nyb3BCb3hbMjkgNjIgNTY2IDc4MF0vUmVzb3VyY2VzPDwvQ29sb3JTcGFjZTw8L0NT MiA1NSAwIFIvQ1MwIDQ2MiAwIFIvQ1MxIDUxIDAgUi9DUzMgNTMgMCBSL0NTNCA0NjUgMCBSPj4v Rm9udDw8L1RUMCA0NjggMCBSL0MyXzAgNDUgMCBSPj4vWE9iamVjdDw8L0ltMSA0MyAwIFIvSW0y IDQ4IDAgUi9JbTMgNDkgMCBSL0ltMCA1MCAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4dC9JbWFnZUMv SW1hZ2VJXS9FeHRHU3RhdGU8PC9HUzAgNDY2IDAgUj4+L1Byb3BlcnRpZXM8PC9NQzAgNDU5IDAg Uj4+Pj4vU3RydWN0UGFyZW50cyAxPj4NZW5kb2JqDTIgMCBvYmo8PC9MZW5ndGggODM1L0ZpbHRl ci9GbGF0ZURlY29kZT4+c3RyZWFtDQpIiaxVXU/bMBR9z6+4j9skHH8ldiSEtBY0McG+iLYHhKaQ pm0QTbrGDNiv33Hc0FIQ26Spap0m1+eec3zsxG9Xrp4WpaP9/Ti/X1YUfypmdVO4um0oHo3aOzoX PGFSkeEsw2VCwlqWZGS0YibhOqOL+K1zRTmvJnQe5+0SE1vn2gXFJ9XUUfylns0dXRwcjA7HFMUf xxSfjjmFf+MzTmVHgjizQhiDkXOVSaKubCJBNWreoWbWRUJoyhSzoCFIGaYsKc0SWlXRNPoRiUQw ZbIsIyE140JwSXuhTCbMpr7u2xtqUMpJpkxwDhxfkUri5KdDnPQNeCKpXETx8YLTYRt9xoczFPVf u6amDWzp23HFUrFFSjH1QMpqDy+UZMaIdT/PyLLMPmaUMSm36GCiCfCYmyY8EWtKYqAEdIMiSUYw rgK4YlJ7WVqv9W23wM1Epaov09Y3wXyLJnazuqGH3MgWHI8fD0E/YgEQIcXaayu9yZLBu0E8UKEp g/sG5CTTqaeUwjmT7pLzdyE3077Q9OQ4Uz05ACBpD+RUIHd0ivz0P/Enn9/T8fEhpq1jtr1iKQKl Aus+b+MzevLwbPwBM6ylW2TxFDhX+L6n8wtOE4pGeRTnOThRPo18QrmhvOyz6n3Pb1FMOWLM/fiL JOUr3MIWAf29MGA2FsDAssTCEJ5Qvohe5fOKPl5eVaWrf1av86voKF+LOhm1k/sHYWIQ9iSInttY fh/I9bwCo56DyJjfCGFAzHCByIgUmyULHPY5t/oArbHLdmVqD7fXX6YBVIleUxg2eDgUgIfTYBA1 qbp6VVHdkWtpVjXVqnAVFeSKu7ZpF/fUTsnrHbCHNkI83wempUnG1U6rYrlctf7w6fssbq5dvTdv F3Uzo7qhr+kLlsrB0uEQ+gdrd1xVHCdOOHv+0thko9g8K3gL8om3Dx4Gdy8ruiw6HL84tItm46oS Q0hB8tkeSCYXGRK8Y+qqnNcOmbxZFdeALK7vO7TCijl079rrm/4F0S2L8qXMqv9oMPhp/dfumj8J X8M9Un3cTOqf9eTGS96kqoSjUN14l4MT1cRrfmlTaGn8q+hpWGdF3XQOeHDzscnDkm7b+VuAAQDP vsR/DQplbmRzdHJlYW0NZW5kb2JqDTMgMCBvYmo8PC9Db250ZW50cyA0IDAgUi9UeXBlL1BhZ2Uv UGFyZW50IDkxIDAgUi9Sb3RhdGUgOTAvTWVkaWFCb3hbMCAwIDU5NSA4NDJdL0Nyb3BCb3hbMjkg NjIgNTY2IDc4MF0vUmVzb3VyY2VzPDwvQ29sb3JTcGFjZTw8L0NTMiA1NSAwIFIvQ1MwIDQ2MiAw IFIvQ1MxIDUxIDAgUi9DUzMgNTMgMCBSL0NTNCA0NjUgMCBSPj4vRm9udDw8L1RUMiA1NyAwIFIv VFQwIDQ2OCAwIFIvVFQxIDU4IDAgUj4+L1hPYmplY3Q8PC9JbTEgNDMgMCBSL0ltMiA0OCAwIFIv SW0zIDQ5IDAgUi9JbTAgNTAgMCBSPj4vUHJvY1NldFsvUERGL1RleHQvSW1hZ2VDL0ltYWdlSV0v RXh0R1N0YXRlPDwvR1MwIDQ2NiAwIFI+Pi9Qcm9wZXJ0aWVzPDwvTUMwIDQ1OSAwIFI+Pj4+L1N0 cnVjdFBhcmVudHMgMj4+DWVuZG9iag00IDAgb2JqPDwvTGVuZ3RoIDEwNjc4L0ZpbHRlci9GbGF0 ZURlY29kZT4+c3RyZWFtDQpIidRXW4+btxF916/gYxsgFMnhFQgCxOugSFG3biWgD4Yftsqu18HK 68sCafvre4b375OazYMNWDEcWUfD4XDmzG37w8fHt7fXh0fx3Xfb/X/e34jty+s3b99dP759eCe2 z549/Fu80spJQyIomfBPJ3SM0iURLMnglE3i9faHx8frw93Nz+LVdv/wHgcfHh8fjmL7l5vbR7H9 x9s3d4/i9fffP3t+JTbbv12J7YsrJcq3q50Sh09CCyWj1iHgUylKRohPh3cbLd5C5k+QefNpo7UV iWSEGVpQkBQFWenEx5vN7ebDRjstKaSUhDZWKq2VEd8WMeNk9Cz3z2/EO4gqYbzUSkEPS3gjlODj eJzhC5Qz4nDcbH86KvH8YfN3/FESQvlvrKbZALfk6xRJryejSFI3KlpWr8nIEHS9jy2KMsWlRUka M5mDg6Gox1nvlNPVJN1MgvYAISOCloqKcpLG8rOsre+brwDoyFMWs5EvwfmIS+KIbrnDjGdrhZ+X H+X9oAWUaKOrr6NhJxsJ37XHQyvelOD9AOOMtJ5N8vBc8GvjGMVzk2XBkI1TkrJxUACmdeOoGPfj C/An/2/7kvn74uqn5+BRpdkcMQ9CUbE68+1qJ05+3F39FSdiFL9Cxwtc/wv+/lm8eq3Ez2LzbL/Z 7vewSexvN8xQ9vb+kMmqgtj/CmGxB40Vf/5XGLH/CAgpAvO/LR84jQAEuMxFOEQ5sT9u/rC/uxEv Pz786/7mKHbvrw83f9z/svlxXx+2u7tGUrbHqfY4JfhPtTk4tlnBaA2jNYzeGJDJCXJUeXHcGI+Q O6bTQO83u7PXmHYNOZAXIQVZgy56yLJm41ECHHgvrDIsAn2SNGgHEhTeETM8M/5Q9GTUhiBVPlhU geqWotSBCQTiSpUTmBJyy+l8wEtQgnAuEZ87wOhcLPCX0yOVuDptJZl8sU6VkMeNUy1HCR5pr55Q mGsTq72fNSS8qcmSZ1Kcg/o992dvv9/cfpN/sHZpU4VmjSg6XDdQpnyoUmsI4TNIrpiLBmuuAqRr JJYC4/cgLf3G7+AmB27961fozrsv5c0TVx6f8O6Jb49PuHvl7ONven/H6S1tUJ6rE/4LheI2atRo rodkNZK5PI0zikpid9QGtOaehSGtME01uQ6bgRqknHclQ4s+gw6UcjTHzQPD2eilXaE2tRTu+jqy uHegw8Kub3rJmTcfmP4fsulON0O5wWgvQ25+Dv/IT+D+gvaCyitVtNrBockYiqIUULST5mH8oHTy KJ+1qpIOKKsbAr8SYmGEMyB3sFy4BqYDOmru/JgBjOc7HZ7pPKG8GwxKifyEHDYGHdfhLM1yHqEP k7IG1BtxqgEcG1wlJjWgKBmt7LiuI6i8w6yOzk9q+k6feUC+7dBFLXdhO3ys0ZvhX9uGi9vfIcF8 Rr+Lid2bqVwGgwWPvcuNZIQevWEiB3+bCYTvnWLl6MTCon5B1jIpzTIxT4thYn5DlhnS0SmXsrI5 4VbvaRz1mpN6Imj8QuRUCZMF58mCngr3YuayMz3RZGOIygy+dGRBzyFXydeVdaDdOQiqeWCIS4Lq iNLsF/nQkAVBOzrnV9N37qmNolgO4GmECYwrLClhYlLlOQiJxe6/zyRLpViC+jGVxmJ9kBrUw5yN gl8hmwOKNlfGjgHBTNOlnNQsNSaqc3bkSeDrNxBbhMvjNmnTh7Sa3IQen3TVgMIba+bE3L4YQ/+t dZ9qDjDqWt/gHcC18w1das2zMWGeDF3w1KKLM7VEwCRbazvHnPpVMS+Oc4xV7IOM9R5lqChFAEND sSjWRq7qODOjrDSFk2Ajz3gBpcGKYdOlWYqoqNz5eT5rMx5vCjkjQpcdoZ4yrFNiYSq4w2uGxk67 ghb6UM4ZQh6Gxo+1JZdioq5V09cIWamSriUp1gIxV5IeYbRBnVrUQtsqUZt8R22dzIjQF9OoWBWF XpdauasjHw/EXXJtVa+gl2NsjQOqgdU1mxAtX2oEUsc0iqOY6FqOphwDLVIomQcy1MKV2WMSPnQ7 XAi10NfjjUTSXd/KnAsysrudy0Ck1jhtuWcuIT2+igeNVpicz3lkqdUkbrh6aoiMmJSm3tpDiplH d7lTOy7EQHibCnFRAoo1pRhVis+jRo/pIqF6/CdDES1DBXP9ugldadWFVShMgUbPXdt1mQZ/yHmj S1eb9yCuKJ9n1ucJG3uDsMisXPoa4Ai5ZBLm5vs8Dc+28EJSaFStcbYuZZ9h8wiRFXd7BrS2aHu1 g9JPrButS3nRtJddMOo6ZFhM9qW2cLB5NWXXDZT7Yijv4kvdCoOeUjYOmwlFUnBlGvqw8EqdB7Rx 88BwNvpW5odkUujD+XTTN5D53oEOC7u+6SVn3txWRpheWe7a1I69MeTAfc7dEQ6JOi9UYDjyhUM4 MN1GCkKBQibw5cgk54kXNIdCrXxe7hqGVY5Q3rTPp7ukcciecrprHFi9GWcnjANFvPINfcg2Mpr3 2HFzx3B62Dgkp/d1jSdvbitk2x2Gyzlf4G6rasLc/i4ZpnhQLib2d2Y3DqENLKgNCnk/s8GbmS/8 beYUf2+sK0cnYhb1C/7ydmIWMhityzjZk6Eji6Tp6JReWdmcg6v3NNp6BCYuORu/EF9xd4icPAvG ohNG6znygw1KoRRHng4Hbzq2YOyQHEwcGies3b3gLEqf93HJWc3rkV9lS8MWnB2SU/51jWfe3Vir 6ghfFycuKq5xLE8RKD1qmg6Sa6Wpbah1lwODpU0NyoMLYXBRKwjqxtibNzN8nebrU0v64P61m4gp wJV+H1WdXI894zF4jC2s72YI4FjE+haHPBjzsWv9BdapU3Shl7snIPBfj1VubdMFGluj4NvKxZGn fhUKRFjEme8JPYJ9j4t62u6SNKW5o2LFU5QV0UnAYSBG7nrVyqZLs3SsT9gK+sZR96zkxnI7Qj3n 2aDFbCxHE/yJhGrUBAu00Fh2NAw6rkudWnNJZupaRetGFQ0i2cIPwVou5rrSY40yRW693HGlih21 bZpDsbKuaeho5A653t+4ZLle/k4t61X10kyuUUGFcH2pQ+OnVmBso/1Y3+a8G6ueH+tX4xMMROZM wEJfjz2ve13fypwLMnI4HqUhpdoCahNclJUWYx4k0C0rG5zPWeUqkFtxSFOjzAgfTidBxQvN1GPX dlyIgfA21RVMVWtKcWrkn0aQEdM5qUb8h6EcOSoY9esmdKVVF1ahTMU0Ou7arss0+EPOG11Cslya VG11n2EtwBDuDQ/ulpcWdsmAHCGjTMJkfZ/n5dki3mAKmapFztYt7jMsKr4sXt2iDq0t2l7toPQT lMCh7JbETs+bo9EpT1SIAana/o5ATUsXy1eyrycsUS9E47xV1Oc0Y013wDl03HV/1oIcWf7Bu/5D aqY1dKHaxC7r+/B/DiVJXhjeIhEEvmXIwLzSsJcyC5EoQ546/7+Is5n0a4Gv1M93azfTF3DzOR8f n/b8Ob8fn47GaSyOT8Vnh8RyyDNOxOVnSRLMiJiPDeYMW5s1Q6W6mFC6LX+WamjQI8o8YoKvu+bA DjgbeYeaxeBsWMP1sADow2RU1VAqI85NqOtV1KDKKltQqvFjDLMqKwwVMM2QjrFC1Am/EPN1rmMb o9YzEkOdDfjgQCOq/epsbGvIjCUeQVZnU51T+EQ1L9k6OaJ+SYMmAPqhqvWvmob5DRrXpbZIGZ7q dbkiu4zAgFKJy0Ee5cnUGRPFpd6f8zAskZgJw8c65lKdWbMNPGvEGhB2U+gDgtbN0ws0/I/9MseR 7VaCqF+raFuGwJm869ASChBkvJIj4APavSKYE29X7+CXJXU8XhaHzDhBbUlsWwGIC5XSotYEqnMf z57TNeBTMtvzcag4tKWFYxG8paYjC76pIlS/eCuHloftBNXV2lcD1/pedQFPbgIrd7ARzjFNL7Ph xKUZWYYTv1cwX7aKh1S2ZM+C3VM7JrSSbZ84G4kZ1MR0WJyr3zVMiGAm53mMRExDhuWOJARQkB5t 6ajdm2qvu4IEV9RJh+aLMqpd2qXdcCjmlZzRVTaUXCMzuL6QEAZ2B+/f6Bbw52Vf+0ie0laPGbFR KaJTa1HKofbl626aM2rHk1e/7nqMtV36YHjuXWvD9KSnJmeRJMG1Id2AGTX1tmxXHxpc32861HL9 XrLtm0G7xGImywh5LjwxJAvfhflclpG7/gC13fKZZ+p/JnsZPR8qFbBTRixz5WWNxzKj/7rAAi36 W/dhS75TVz0woNtFgECkmuggEGPO0kmOtUo1csi22DdODq8/rk1O19c4iiMhOTnKQQ5Z+TGsbnLs yhKhOSNSkCNU1JOTg09BIQfWZHvsmxyYUJFwIKyH9cKb0jiHocqNHEXJ4QrfAU6OUP2gb9r6Ph/s y8hxakYOBxvsUMmxmpTAFHLInxXdHuATKcfPVWuEPJUc1clRot3wIclRhpEDHa9MqJoDQkGsUXKE hieK+a2+UouTI3uDj4McN9XJUYwcuFAjR3FyVCdHaPMgh6tEtUcONSeYnZID31QRnBxeDi0n2wmq i6BgwFQq5LvA79ImR4xB0Ss5cOJKDpQhyZHb4SdzkyO3IAd7SsgBX9B9DnugUjMemOWFdhrmOTIL OZKTIzsjjtq9qU4OZAEjh71MS3fcX9oNofDe7TRDZUPJNcLHjQfNyMHfUHKkIEeM5CkJOWJGbFTJ EVo/QtChFl/3MnLA+dWs8dtGjhrk6B61Wgty9MvJoTkKMxolPDQc2pERQkWUUHJgPpIj+2JwBRsT 9SCHS0GOZORIl5ND42RXLuif6SDHlhjVZEQxV57WeCwz+q8Lz4NS92FLvlNXPTAQ5PjA4QOHDxw+ cPjA4QOHOxz+evxk1a+tDp2veD81vQLas/VmaOv3JDZz06I5Q9vOdigoKyumN8N9bW1WMdfmpq6r W0PPmxouiecmPykGk/Vdd6nrvraq1VVQHVKv7t+1ZOfBz9b7bo+vrfIeIQ1pFe5DJhy0KoMJ/Ihd kqx+v1vba+OQm70OdfNVG7lqpfBepjTjGmFw4zIHStbKr60KYnHvhic433bHat393eM4W9FGotVc VWvjB3Vr+a79bzcFnfQYlvXsqa1p2nc/k87+7jWvh3Ui9jPcktQAsB+FoTbV8IL8wTteu9Hy2JLE H4LEgKk3Bk3PGNqwGON7JaXjVDIzEE2iXb4vmRBHimFfbx7xfLy1pCSzlq3jSW4FEv/UnMCtaXdO t6A/HugALKx/ff/v1z/Pvx/lSpv0OSlrX1vSPadip3fRhvfPX0Ovo1xtr9IFLPyCj96GDD2qcl2u TQN8apaeLtsdNU1PKHT5ycoKELPBLFlKnjzbGv8PcS+E54PrLuU2plonI2nJMR8aYdvt01Bxzvty qa3Lrlbc/67Rfu7fTj24X1DHXh/sQsyGS2B716JsMgHVFDtQKX5vGr168R0MO7U+PAnUtOyMUFnS 7EQNa8y7wQQmJv9OJFjluq0TdyNBhnejsQgnK/XM78yyqcqJcdedNGo8Jv3FjgLgYluavgrX4EDW SYdK2Fa7QGmbVq3neL1dxkGTlMavJcyB/NoWWL+6S+edidbeNFZhZdmcw7JecsOhJ2lgdAf42dqK xH5ta2nt8uCNYudESRFGQY3QNVJj2MkdI/teuwYDoE1sv9Wo0VNFbeWI3XZEzeDswGllHki06Lm0 rxSxqsYrINvvoKZ6tSCvv8K0YkHjGHl7OUk3sLuvbwCEodzeXaI6tA6i4l/tEVLNYucKHFGdpsq5 /Topj0hh1xKUvvxxFVqL9Boqkuh2W8xHI++xGHkioUPd/fTlBkm29msvTlIKiaIxmBkGxK/xOFJB 4p9siQJSh536MC/M1mOsKQ5ygd9d9mu3YRIVqZmNCgtz5PU/fwMn1sTFfzF1lk5OrFWqcUK3u5td OQFJOCE2f18of0MNH++4XA5BFtrPIVdyTlTXsnKCJDBOZKMgY5ByItDUfYNVPXBDKlvPw4dD4HSD mzrHTOdEtn45tCt6MNQ4amjGhGyvhJsmnDi/zQcnhGPAjnEib/8twzkhQh0HJ0Rq2TmR/ZUznBPJ OZEOThTjRO/OiSqcKO7QIiBtBSdEQous2zpxN/rgxd0IJypO1jixVe395pwg0cEJWsTSpHE5J7Kn j9B6JK5QiWU3e7Wn4qk7zB6acULTS6vLOeEptE0DwFpvGqt3bk4cw7pxAoee3B82J0pwQvyh0Qm6 Nf4QVhW3BuWEazdvjpHz2mtXTtAPZQHlqNFQ8ZZ1ToD5dkTr7RHXitd9aLkEJ0JN059x/XB/dSz/ lcrMZpw4njH+IPUZWUHKidBWJJtTTb7ybk6Nf1VrRvw1TpTgxPQEBdU5MYdxIp4KMeeoVh2h9RWc ONQsnMB85ESLxSzhxPGKoSRN65zA4tS56zROQNtYqMYJFXDFygkVkF+NE8kzc3MACExceJ5Uug27 PJarjSrQUjs58UHBBwUfFHxQ8EHB/zcK/nq8+/Jra6tto9GOgCnrFcAu0Ic3ZeiGno+7ao0YGhqt GwzMhPH2mmHCd3N93bR6WPjk06fpgVPgLeHgljUnynRfylJzfW1JbxfqnOKv4tLt0nP72Vx/ssDX VnkV4FRSxi3bKrTqFjbkV6E15827ib22KncRqhCxH8qma5JvC0tHX4jW3e1wtrENqVprvx5B9FYv tTL6ndlivFbf/W7iSKv5D64oNU44L+24UH/S/t19wimPYcscH5pWxg8m93z8ZD+vrU5eybLzD6fA qed6dtl1VOkPhvLaai1iPU4qaKNsoUzzokvKA1pyB7g2Q0GLKlXLrcpccI41ZV9dfhO8iL3ejMOZ Ei0quaxP627Btt5OBT41l+AK1feIVF3XHw+UMHbav77/9+uf598P6cfd+tzMlHOgigMr8ErLKXt3 pQ9sfQvoTo1jriFIACtqJFCF/uxZcSb8jmueM0djSe9vm946NfoLAhS6mT87stYzo5Q4fhlJu6si KiRJi65xOlSqLDBGFmQebmtqHZiAIir2XUjr9hFrqMona+17Qyo4P5h6MVh28ay66S/TNM+5ZZdI KMxt9bLfD9V+sUmKLL7qasjNdsrPx12VyuFSuiESMUDqnPFTYyK4oxccWjWH5pyuwi6TuCOWo33Y 5wYkZyYqcM7iqPyw7ACJm8w6f9ldNOyUTEDVXTU+ooQz69mOfifJwv7hb+OqtYOgXRpDv6lVLJOq rJ0JUwCwcZHNIk3LbxrnTFo+x8i0eNPMTvv+0vTcdLlNnerS3PbraDOO1RNIO1e0bMEHwvGXxPLV bgOyAr0R6Nf5griOEj4kLQPP5OYpm6kQkHs1b6pA1zJ0mFQVzwa7iFWcVmpudC/hu9q6LUE/LpYx dXpU0Zz+sKJQIo2p1IavG7zQx5AZMniNql3HM0iAXpe6oOyfka26e8Y8YIw9FV1j1/iL0lVUFBPJ ESLy+UiTepECsJVkvXaq3pNYH5mFO1Rv8MCxp+73F15hjpi2MdWWhCN9uRU85uzlNmyIa/xwU5KS ZZ6h4WsPE2+9o0C3/+dvAMiauLIvflw6AbJWqQ4Q22IZ/QBI3gDp0wEiC0WgUoCwKRUgKQCyg6QA JBks0nSAVNeWAYTZXQCSLDZQU4AYt/reJG8sGUB621iQW1SAuEYHqAaQY2QTgGSzYhVwiN59IemV mJDFznMTgBQDSPy7A8S9S3KKTLP88iVjHApa3QHi6r6EKuPYDx7SOb2hIkWx3lQvVnBUAQIYG0CS A8QTQmg1HwBxFSlSAYLlGEDkhbVDOxu/BUDAMHoYblIBkocAxE7JhR4AUWlOM0xmirZfnAYQM3tq AZCb6gCxiLMDpyNAYZGWa/1NYzU2A8gxsmyAJL0/3I+hoh4ACbUcAMkOkOoASf+xX+Y40txKEPb7 FGPLELgWyXPoCAMIv6GWI0DAu/2LXCLJ6mlDB2hrpgOsKi6Z8QUVIHLho48cv8I9tyRW4jdCcTW/ SXWjxS7hUwqAVNvJGUZs0IcRESAmoK43QDwYjABIIQMIkAgtfR0AOdUNEHsYyZIAsdejigiQfKfF nkJLMe8Sxt+Z6HEotZbjqmeJC9IGSFWAlBkAifeUFgAJLa8DIFvNDpBKgOz0jj0nQHL0pKqdzTzi MJrauV417cM7XNbY2tBwMTSAHNroPpVhCbsFQIIxoX0TWZrWyVwC5GoBkBsKNkA+jPgw4sOIDyM+ jPgw4i0jfj1+mvVTtVnU4dDRbA95W5VW9f8vr1GZgPwet5HocmeL/bJeMUM9HPa5hXrY9vDrUPNt Fe0yCoxrtzEshQcwlQJFX3jxSKGajYh9GkUEOrT+n5Yq73yxu6dKbtq9u3tC01/dXRNNbJ+ENgI2 P/3s+VYVzQ5ha/8qH7tNeo8M3tZZpHD8TqnNDWgPlkT9/XJ7ZH8/H855cUw7DvE8umP20nxncVKc l7YYXMfO9alSvkxa1oYwMNsn10Txo4DSxqulvbUUM5rn42hEVGbN1jXS+ggutLUWJ7PL8e4YT20s tISst+ZwiMYNgmanKNq0aRyU5DKxyXvlqBF7ISwi+UK75igb884avl/jWOapYAKXSnndT0C05ude ZBYi0H7+eGCTU1796/Xv1z/ffz/E+YolM7TMZHOUMJlreqXWcjHQwPsva+IibLdx1CQxLK+XY2RF 89iKKFi8HDxxPLclCylgZvUFDU2DtVY5WnEV2c9aG5OgK/ISTPOm1Tq84MQ9rPYPDfSLEHGoxWLN oVRu/E2LU7ur1ZnfIqtO883aMiNueP/WxIt8HVvL8eXGlCsBzFAvXxCklmP/t2QlK/Mo2tMl7LdV ZsIa9rm1tnv6UCW7cwkSASrDZCUJ6nUdxznFskXqlce5mBuvReRAQwSqg7sWwtjocAkUNNTKbleP QAYQrKJfKgwGV5GOlPTXY9dLk9Ccva2Rv8B6T5eo6Jsg5Ty8Rc5hNLEmydyIVGgMLR8p+K5mP49C s2m5R4NVp1cTYvl3iqe9rVkkn7dhmIShXBZW1/2yIa69c/JWmeb/sqheLOkmeokRt67oGRdmk170 t5k0ltxS9KGA4IhI6/cAXI5yPBfD4C+5n9+7TsJPuz/0l+/1EkjtWhgtLqn4mMfj1hz2di/yxhE1 7kUX85pkS8d9l5QkwVIzDH+m41pjEk6r71uMh8MrbjbTa0a6NxrzpkZvYnKMkovZDJqjXq8mTCLU sl+pbGmezObgjOLKJqbuCQvz9XGhSSWRnufIpr/UcG944Bb8+RugMgci/JfsS+kClTlLJVRineLl AZV915XLg9d8zFTQ7FAphEpoNlOHyjGyKVQQByh0JQjybLjQlgIq5TKoZF/jMKgkw0WZAZUUUEkB FR8lGcEXMwIqoSFkbahs9XKobGUEVE5tQ+WmEiobe8CUQgXlSqgUQiU0SQVcx9b2l3tApRAq+IIQ JB/7v6UoXEGtbHqkf7iyo6LwknloGB5Q2Spad3IJTVMboVICKmdGKOYS6YBKDajUgEpVX7hGQMUE mNCGiknANaGSDSq8MzoMRAioiGRDCJWol5aaLQUlpwypQYtyF+Q9OaASw4AXQqUQKmgaxweiwfag m0qoQHWoiJHE9YVQSUGLK6CSNlTMW89hhVBJLaBSaNzrKPFDvQ6oJIdKlQDuAdUywYyecWHMDRVK lVDBajYtaIZJz0ricDy3hxVCxd8ldwHbTwplQ8WlxsqWFylUckAlESp1HlCJNCZqQCURKhKsqt91 DRnLoMKfR0pwKYeF4zWESgqoFOID3buhcqobKjmgUgMqvD+WtWIft9YPqISKeNwDx4QKm++AT2jf B9DOkVN/qeHe8HBA5cONDzc+3Phw48ONDzf+Mzd+PX6491OlqSVdrss2D4qdRblW9GloA5VIj7mp L8+iuMoiMrYm0/thu8v5BXX6Ytdh+T6/mVg+0K7BzZPvmtdYa8o2ihk/w38gDHc8+rrcTY0UL6br Bvhii09V3dhBNQIgs2qh1WyQET/Dz8bWfbW452FxPq2X3/9TgBqLz1FNK3hOryIBtrZ6Okwv0YwS m/upKnDcUncnEx8Uu5Ry9iL9aXdSZpWdBtcpPKU3qmiWKLb2rzaOvfUcWfRMRKivhkdr+378cJ/n 42jYq4V5h0OATPml4cSlolbfOMxT27BMRSjdXLrRYDrsSKGsZpQNQ4jVijXEvhTJSvKh2ekmzT4J 89nLf/WS78e7frU41y2mQTWw74MCQn4v/p3lByIaXeuPB9ol5dW/Xv9+/fP990P8GbFuGRkiQfbK /ZSJ2JYg/JWim+4ZEEah6G/bIvHh6WSIYQhjV9GEQIHzrGIizBtQk5U61EiQaGwpdjiQtunsnC0A pfEQbbDyqeBVKKDZQpAWqDYEadHs5NCQSojXU236wVPpnuNE80lAY4K8j2SCbKgat6OVvKEaTKZI ZyavJApZE6/NhFJ8FOblGQFdbC0j4UXat+wDEAmbLRIB1aRU/MnlvdEkJ1mUQla0JRxaa5EfD7V3 CV2p6XwNUA19aUfVkp5yw57zREUalrwkTVR5FNOBsaBqmlSKfVdCgH1hcONObUWOPNSVPUq2lMXT OjbzAmyH7vOlkxNtdK2HU7qW1tV0G+hiTlmLsn/1IhzRykFE9l94wcXgywFdzbzjKNLQSu6Nn8Dm DEPRXctaz2i3Kh+F0RQtlp6807o0v7CzMUhSERateJWPqjwXWYBkIpCjJjeanupxLdpq25kR52o8 7bi0eGbErNDhbbFLKMxrZ0ZKmZkRrmPhs8mtKy6Wnq+B+oiNx8jE2OivQx15bKSQDlc0qbOmhWM4 ntaWxsam0cI6siFbRmyU24EpjIyYlzlPa4W2Ji8z5MHaeY3YWtnRcavy5uEw/pIG89woudNWiMYN U4S6mkoRGssgZyU++kcvPrx5fGh1h8ZQ61ycCPrYGTsmoyA2aHt7hEZUXDklNDA9Ki4HdyxwB/78 7SEtVbAa/MXUJ/6ujAuEwwR7zafKhgkKmnCOoA7ACEzQR4RJUpiEIF3XCZM9TJJt0WBFIVIIcLRh UgkTqAET8ZeiEUFhMmJ7EBAMJiVgUgImyWDiQ9agzV+RTbeGFBt9d6jTPngoy31dNG7ZCpjcRwZM ENz8oIAnwsROExc/wiQZXdoBE5dWEGwSJsCKwwRuLTDJ+wDo6ZI/AiYlYMKgJTggTBJhcmhzw2Sr KE3CJBEmCBiESTKYlAMmKWBSDphoihT7IEwqEXGtgElocvEImIQqocLysDgfXofNdJhMWrhoBpOb 5DAphAl2TGFSBSZoeIVJUZjYL+m/QZj4gK4Y73JfMZi0GW6/r20vanYnEXsTVGQCBfAmUIoDJQdQ SgClxst8VOHZyCKqX9mao6Oto7APdW6g4GwNKA3xi0DJBovoFArpAIpJ6E0CpR6Y4L3kIlAQIzdQ YiSMhUCx16GWWlwNbvTYn2ysa7kZKlCqAsWjtAMlbaDIdckUAkVimhWD5Ci/OrSARyZQtlaufaJb zeHjeWquI1Bq+P86gFIVKJA2UHJc3HoAJcXDOYBCTSxmAyVUpGECJQVQSgClHv4eQEHFlXkbFj4F zYFyQ8MBlA8zPsz4MOPDjA8zPsz4T8z49Xjn30DGwGm5f0/u4ZCrrE1IClq/dGgoSreZu/rzabS7 lbdo9ieq8Y0dP1VN9vDMYfo4yKnI8CKCQHeu/tVvdajqVnu5Iz/VfGaow02Pu9byEF6Iu786sBnh zRtlekvW0a7qDJD5ipdDqGqyYmxSMRAau/jV2p4q9WqNrZII7HQV/n0I4fL5mBC54dXApJVTRYd6 T2BvuA+1Y6/NhBI7HV9EDBBvTMMNTe6vWEqX0k5mZz9dTwp2xEwnik/+e6q6jclU1fJPzXc6NHnn pSZwDOtirSqYtb4xvu/HO2/CXHBkeiY49EFLkX0CqvJLK4p7Re2+cZ6nNqjMrZJp0u8+FWh+yKVo ZUBI4RQ4ixqgZzljYT5jxbk5TZOY08Qa3ftfTOb78a6HLd61TqMw1O9T0/62L7TlBBeNXvbHAx6P qNa/Xv9+/fP9f/bLbjeKI4jC9/sUcwmRDN3VPT0zCCFhsARSkBDeS26QYwKRHUfgKMnb59Rv99pL 8gK+8e4e9/T0T9X5qn4XWKoL5UVLHgl4rgdpyjjcljXmquVTRh1ZtbLCavSWu3Yh8VvvjkScasRm S5AsoY/zyLAfrUksY5pIKJmE+07yjFs13Gi5yBOZhSNN5uG3WoLeXVd7RQZ3kdA61KRakmdDA0Nr PGtnBHdKXasitHhtfzTbuV1JSbbxwCYlamWO6KBNa6pRI6Ru7KKrOd6KMNVrJ0yb5RXsXXq4hP9W Q2nlVKqQqpQV/Chn2USFbGkuIAvW4q9UCR7RYmUaUoSGwOpYrmckSAlB4XfHalGpxs6rxQchbzWa Kyoye3jxDmPUZoMjTxgqooA7A/ZqLYAIJDDc4pvmH2vNgYnvyiIZuVh3IlXnVHBNzULQLbMACAoJ Th3rUELjTmkbx3AxZM/NnpAIdl1IyYJkeWrU+PavJLOsccqepGzdTesauFu0bvaTbWGOeWxIkYvi rZDSF9VR5oPZGAhSf8IXmwib5hLulgMCxlqkGvU+A25kVjto61B9dHXhpkmtbDOFopJdmYiEpiDF gzGMTVrZ1SdDQJX5jjY3DuDDl86JFyyvmK0LIBREWz4soqiSNBm6+WwXJKrfP7waKUtldVOjZpU8 oVq3u+0adtQcGoOaGSUYt1nNT7m6xZfZyk3O2DBEqFpqiWqtJvcHClgCm/U9BblZzQeKnGseNEzR sdNVxLCsp4bnLZ6CBSV59/bqhzM7nMaRSC0VrMI8wIKG8+efgJKtJRRlcCE0Vfw588uNJF4hs4F3 kpCSJPmhIwHMALE8Y0Hzyq5rTJLsm+wjF+8HMlbomloxt4Ger5CEJBQkyU6S3rgYgTCRkWRdmSTx W43ETjVUpssWUHKShAb/cJJ0rQZJKI51DpKQLIOL5AFg/ug8kCQpSZKShJtbi4HNSdI1TvzBSjtf 7K25BklSkMQxzTEdJMlqHPhwkpBQglqQRIVSB5KoBOdqsTIjyTw7SZKXOzT3KoDVolKQBD7nJMlO krQFhmYnyaBtnSRdZXwLSVKQJAVJUpAkDSRJQZLUSbKuShJykqB+cCLkoMQSJMkDSco4Bpu057BI IwmC3dyemxMlwIHmJCEnCTuIbgIloCFOMIHKkfpP9o0t5rEhhXQIBUmSkqQESZKSpARJSElCShJU Ik6N2UnSNSRskGRQs5IkrwMinCSkJCmdJMOw5CTpkyGgjCSD1kuhQQU3jCV5c5YAB8YScrskwDNY Ql4kiBosycoSCpakIETUCYNGA0tCzebd6ASMJVxV2rObs4TbObdEqMYSa/LIwOYsyc4SZKdzY3GW DJp0ska2GjWwrKaE5zVPQW43urcHSRBtRpI+Ege/quAkGbEQJHmgxQMtHmjxQIsHWjzQ4n9o8WV3 z7NBCvhaVmtv1U8Q2mpvWDhRR2VBG+kBcqDeexbRlhfXltk1j8t7Dnwt0gIcLcvg8NVmW+3kK06b DRkH1zafapWmcIt5cGFQyByFPXzlIcWJcNxzjzgjT4Zz0bEM0U3XUDw8AbasXot1zWpa0MriRnbX 3q7v2JuqotEg/IPjJTfvPgyJnfTRtVkbWxY5SMIJdb/DibO9acJzQbBa5hUsna2MW1W9lIKgNhO4 Z3hsRCUWW+VCieeDKvbkEoSDX8R31AWeJ3vuD8OymalouptD47vY3XMmvB2pa1fSsl0JO4bNhc1v 25h4rBT3pSN+cy1+4840h7ksciUQsmXy6vHB0HV3wF5XCqZbCPLWeNWwlqVk2ZWmNwEblhZHbOVi dz9z+fZKJOlqtO93lUFdLS8Ke/IqgnvX+e7s3atp9/T8y6c/Lqfnz5++e/X29VSmFy9OX0NP06+7 0/3u6X6Puaf95x0OP4FM+7+mNO2/4Q9yBqs+0Y8Evs6aSojNOdVt2l/vHr09fz+9fLz/bfej4RUb bLVtRYf/51DMXCnDBngoJj7V0fuL6YQXh+jX1YEvOLAT/UhTXbzU4SqoFV/b+dfby+ns76+304eb P28vv3189P3jY5nyidQiPi8f17F5Z1zvnBLuElb7hHA1urKfby4+XU3vTt5Mb26+3/KEOETqh5g2 njrZnDyhzIa8gj2uyDAYz7qkusps718+e/b1FzuXI4NxNluqWcee+tizvd3u+7jZ6jd7cKt6clVW xHutR7fKXEUKtYqt4s2Nv/ELP1xe3+AQY6P+2n8FGABofIHhDQplbmRzdHJlYW0NZW5kb2JqDTUg MCBvYmo8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnRCQm94Wy02MDAgLTIwNyAxMzM4IDEwMzRd L0ZvbnROYW1lL1RhaG9tYS9GbGFncyAzMi9TdGVtViA5Mi9DYXBIZWlnaHQgNzM0L1hIZWlnaHQg NTQ2L0FzY2VudCAxMDAwL0Rlc2NlbnQgLTIwNi9JdGFsaWNBbmdsZSAwL0ZvbnRGYW1pbHkoVGFo b21hKS9Gb250U3RyZXRjaC9Ob3JtYWwvRm9udFdlaWdodCA0MDA+Pg1lbmRvYmoNNiAwIG9iajw8 L0NvbnRlbnRzIDcgMCBSL1R5cGUvUGFnZS9QYXJlbnQgOTEgMCBSL1JvdGF0ZSA5MC9NZWRpYUJv eFswIDAgNTk1IDg0Ml0vQ3JvcEJveFsyOSA2MiA1NjYgNzgwXS9SZXNvdXJjZXM8PC9Db2xvclNw YWNlPDwvQ1MyIDU1IDAgUi9DUzAgNDYyIDAgUi9DUzEgNTEgMCBSL0NTMyA1MyAwIFIvQ1M0IDQ2 NSAwIFI+Pi9Gb250PDwvVFQwIDQ2OCAwIFIvQzJfMCA0NSAwIFI+Pi9YT2JqZWN0PDwvSW0xIDQz IDAgUi9JbTIgNDggMCBSL0ltMyA0OSAwIFIvSW0wIDUwIDAgUj4+L1Byb2NTZXRbL1BERi9UZXh0 L0ltYWdlQy9JbWFnZUldL0V4dEdTdGF0ZTw8L0dTMCA0NjYgMCBSPj4vUHJvcGVydGllczw8L01D MCA0NTkgMCBSPj4+Pi9TdHJ1Y3RQYXJlbnRzIDM+Pg1lbmRvYmoNNyAwIG9iajw8L0xlbmd0aCAx NDQ4L0ZpbHRlci9GbGF0ZURlY29kZT4+c3RyZWFtDQpIiaxX227bRhB951fMY1LE5N7IXRZBgFhO Whd2mkYE+hAExZaibKYSqZBUXPfrO7ukeJPN0Ilg2KSlmdlzZmdmz3qviypd67iCly+96H6XgPde 36SZrtI8A+/8PP8XPlLiu4yDJG6Irz5QpVw/BCm4K30iQvjkva4qHd8mK/joRfkOHfOqyrfgXSXr CrwP6c1tBZ9evTq/WIDj/b4A73pBoP5vsSQQl0CBuIpSKfFJCA8ZQBlnDoUUbX5Bm5vSoVRAyF2F MChw6XIFXLg+FImzdr441Kcul2EYAmXCJZQSBme1GfNdFRi7P3+CDE0JsMClhGAcYxEwIGDckRwz CxCfQbx1vMstgYvc+QN/iItG9lc10ITEtNjlCHcD2gPFXd6CUsKEp5y5UtJmPYNIuaEaIgpdxnpw 0FHW4dE38IlPG0j0AAmjSzRiIKlLeB2cu0wYWkI0/PpL4Ic+D7g1E8osgv4KF1Hd7tZrsI42Jfj1 8FHzx7LAIJTRJteKmSQzF3N3II9RkVOI2ZcIjrkiMJACzJwMxuDMp0g3FMZQWnDE5RYcBsBKa8Hx Gtyba6wf+8d7b+r3enF5gW5NmfV3LMCC4jVqW2+LJRx9uVy8Qw+l4A5r8RrjfMbf3+DjJwIrcM4j x4sixATR2jEVSiREMZzZV46f3qE1RFjHxDz/AwZRgR9hjyD+s/qB7rgDEnPmK8wI8SHaOs/e7rPY tJvewIfkyz4tkm2SVeXz6LPzJmr4XZ3nq/uWIz1wPKpJA3PB/jrgNBBJjc2ioVhf1BQXIwFm1BZX gE0T1lBeEqLEK1wXu+1BuuaNqjogDS2z+jGIiOMBI+JcMOw+vF1wXz23QR91YZiWAJuWWxcGSbbf JoWukhKq2wSstwURtklnij6MAxsrsIU/xFH0Ugu6/HkiveyQ3t5sMrs7nWCKqEx67QNx+NgNAtHJ DsRUfv06FDVUVOfPkJfqkpms9tlKZ/H9BHz+VPhj5DIwM2UucpzJhz2hQZOKlkQdakjiqimGsREz 61ETA43yR4x44AqfCWaN9AqWt7pIs5uJdIhT7CYn5FBVczdUHBqGyVFWumDDxESFXq/TGN5keAIn yTd4+SfhhQelkGbEzuFVTztKR6XaBRnyeZ9v0slKDX6wUrnADq9nzmz0/Ah9G2SIfplud4g/raYY yB9lINlBQ8ytqyb9RiQROq6sNtxRZWXlLi+qsyt9nxSw3Bdf06+J/jvdTPNTJymyELXW/IGCPu3J KsYE61BDdhfvlhDn2x2K1m8SCk9BSDAyn03QzgF/RMaEGTJ5m24q2/ew0Ltv7w4lJ2GD4kTRuTOg x6nHpA0x6qFYb2ZUGaU/2EYiQEE5ezw/Mgi6IN8xCOiTRcOYQoi3D/kdk2AoQTs2bbzR6Zvc6Ph+ dr/QIzXxBM3Zk5uhGwgQks/Smm3LtP0/Fo42nI/nqEmUrKcAnp7VGZZb8YjYrH0U+gSyERBpFm/2 K1SZZb5N8Fy2SvNsNGbpI0KTU3PV4uEIh16t0kbOf9knpXkt8Z6zwWxjX7dStr95wcMLoAIMMUts tMBXVDz53ojYXRKjmM3XViTvinyXl3pTdmv4bR79h1cwt0dBFB+tkGY2oi4SbcJPaWV6EnnFQuWG VkH4uE0tkKka4cf702rFLhrukWoK7tllhrNV26sW3KXVLRT5vprWWPREIgvvs/ZUnsOuVtJ8fPB1 MfqcXnc1oDO4vPCu8lhX+a4YyefOXVJup0G90+XjdgxFqqSktsMBWL046o7ufYhVMKuo2BBruoZ9 maym0v1kQfhguoOgEUGzi2lKcXTR+mQWtzq7MdfTHHY6/icxe1B3zR3eMqc4PlkyPiypyBPZ2bej m4gJ06f1Tm+T8gX8mpcVPpJstcvTDLnpbNWNFXE8udpTx0xZFAJ8GNbkBVVaPy3/CzAAzZCgEw0K ZW5kc3RyZWFtDWVuZG9iag04IDAgb2JqPDwvQ29udGVudHMgOSAwIFIvVHlwZS9QYWdlL1BhcmVu dCA5MSAwIFIvUm90YXRlIDkwL01lZGlhQm94WzAgMCA1OTUgODQyXS9Dcm9wQm94WzI5IDYyIDU2 NiA3ODBdL1Jlc291cmNlczw8L0NvbG9yU3BhY2U8PC9DUzIgNTUgMCBSL0NTMCA0NjIgMCBSL0NT MSA1MSAwIFIvQ1MzIDUzIDAgUi9DUzQgNDY1IDAgUj4+L0ZvbnQ8PC9UVDAgNDY4IDAgUi9DMl8w IDQ1IDAgUj4+L1hPYmplY3Q8PC9JbTEgNDMgMCBSL0ltMiA0OCAwIFIvSW0zIDQ5IDAgUi9JbTAg NTAgMCBSPj4vUHJvY1NldFsvUERGL1RleHQvSW1hZ2VDL0ltYWdlSV0vRXh0R1N0YXRlPDwvR1Mw IDQ2NiAwIFI+Pi9Qcm9wZXJ0aWVzPDwvTUMwIDQ1OSAwIFI+Pj4+L1N0cnVjdFBhcmVudHMgND4+ DWVuZG9iag05IDAgb2JqPDwvTGVuZ3RoIDk4Mi9GaWx0ZXIvRmxhdGVEZWNvZGU+PnN0cmVhbQ0K SImsVl1v4kYUffevuI+7lTKeL3vGVRQpkFWVatnNbiz1IRtVLpjgLdjUOMvSX98ztsEGQsqqVQTj wJ17zzn3zB3867LKpsm4ostLP94sU/LvkqcsT6qsyMkfDIrv9CB4wKQiw1mEx4CEtSyIyGjFTMB1 RI/+dVUl41k6oQc/LpbYWFRVsSD/fTqtyP+cPc0qery6GtwMyfM/DskfDTk1/w3vOY1XJIgzK4Qx WDlXkSRajXNPUIaYXxDztPKE0BQpZgFDkDJMWVKaBVSm3tT7yxOBYMpEUURCasaF4JIumjAZMBu6 uN9+ohyhnGTIBOfI4yJCSZzcdpCTrgAPJI0Xnn+74HRTeJ/wxxmC6pdtoWkDWepyXLFQ9EAppnag rHbphZLMGNHWc4gsi+w+oohJ2YODjaZJj71hwAPRQhJbSMhuECTJCMZVk1wxqR0trVt+/RL4MFCh qsO0dUWw36KI7brb1JAdbcHx9f7S8IctkERI0WptpRNZMmi3JY+s4BRBfQNwkunQQQqhnAkPwblP QTfSLtDU4DhTNTgkgNN24FQD7t0I/qnf/Dvn39Hw9gbbWpv1OxbCUKpBXftteE9HX94PP2CHtbSG F0fI8xWvX+nhkdOEvEHs+XEMTBRPPedQrikeIyJe441iGJi79W+SFJf4CIcDwC+aBfsgvYFYgYUU PKB44b25Xi7Lwh2b1c9v46/eu7gl835QTDY7QmJL6MiADtNQ/r4F1eJxxUVYF28WOEvU7RYhzkfU FL/k3OorVMXBOmRmIpfqwj0L1RCEW91hapYuIQYBEmICODq3+SotK0ooT9c0T7+lc8pyqmYpgWZV jIs5rTAl/qQvb7JJmldZtSHH+0jNw2LOyhgI5qBeOk8XSPPlLb2intyq15szrmEn9QMzV7xZUNyE 7oCJyHSVT2hXC4aTsBOvfq4JOUvrLpsUkZsxLY8PkGunUEvqFUbqkNGZvlgf+0IJyRRwyvOt0Tkj eLFZvZR7zRoVk2y6qd0Ql0m+WhawSlHS7R3Nk01aUjHdt8rOGZ0ZefhySe16JWR0ULIxW2vBWbF6 TVT9ozZp5Nz3ijIBhokba+fbRXV2OXJLl2/fMLWWGS7bH3BN8P+5RgvBRHPNnumaXgujF1vYS3nK NX+ks+RbVjyXtTFOJ9C4Rk2gcYu4BMW/RcM7NjBa1tHTnVX8VVallH7PKiqL5wr+3PmxmY4vjyqt BYu4kOEBjyxHCvzKwo+qV3oU/sdZpXGZa+Puy3P8V5ORXWf0gfu6bCfcNy3KdVJOsvyJknI8g2Dj 6rlM+wT/EWAAD7FeuQ0KZW5kc3RyZWFtDWVuZG9iag0xMCAwIG9iajw8L0NvbnRlbnRzIDExIDAg Ui9UeXBlL1BhZ2UvUGFyZW50IDkxIDAgUi9Sb3RhdGUgOTAvTWVkaWFCb3hbMCAwIDU5NSA4NDJd L0Nyb3BCb3hbMjkgNjIgNTY2IDc4MF0vUmVzb3VyY2VzPDwvQ29sb3JTcGFjZTw8L0NTMiA1NSAw IFIvQ1MwIDQ2MiAwIFIvQ1MxIDUxIDAgUi9DUzMgNTMgMCBSL0NTNCA0NjUgMCBSPj4vRm9udDw8 L1RUMCA0NjggMCBSL0MyXzAgNDUgMCBSL1RUMSA1OCAwIFI+Pi9YT2JqZWN0PDwvSW0xIDQzIDAg Ui9JbTIgNDggMCBSL0ltMyA0OSAwIFIvSW0wIDUwIDAgUj4+L1Byb2NTZXRbL1BERi9UZXh0L0lt YWdlQy9JbWFnZUldL0V4dEdTdGF0ZTw8L0dTMCA0NjYgMCBSPj4vUHJvcGVydGllczw8L01DMCA0 NTkgMCBSPj4+Pi9TdHJ1Y3RQYXJlbnRzIDU+Pg1lbmRvYmoNMTEgMCBvYmo8PC9MZW5ndGggMTY3 MS9GaWx0ZXIvRmxhdGVEZWNvZGU+PnN0cmVhbQ0KSImkV9tu20YQfddXzGMbNNTeL0UQILaDwkGc urWKPgRBwUi0rVQSVYmp6359z+6SFEVRcpoksFamd2fmnJkzOxy/2lTz23xa0YsX48njuqDxdX43 X+XVvFzR+Oys/Ifec6YzIcmyzOOrJu5cpj1ZJTOrmfL0YfyqqvLpfTGj9+NJucbBsqrKJY3fFrcV jX+d391X9OHly7OLcxqNfz6n8dU5o/Tb+Q2j6ZY4scxxbi1WxqQXRNvpasRpjj0/Yc/ddsS5Ii8z hzA4SZtJR1JlmjbF6Hb014hrnknrvScuVMY4Z4Kep21CZ86Efb8/oxW2MhIm44zBTthhBDEKxwFO BAdMC5ouR+PLJaOLcvQL/rMMm+KPq0NTFrREd0xmhneCkplsg3IqmOdSZNby2l+IyGXe7UfkMyE6 4eCgTeZx1mimeR0Sb0KCdYtNgizPmEzGZSZUgKVUja/rAg+1NDJuUy44wXkHJ26X3eRD7GBzhj/v Lwk/ygJGuOA1104EkkUG7hrwsApMHuxbBCcyZUJIBsxZ0w8uPAVcr8JGG4NjmYzBwQAqrQ1OpuBe X6F+4sf4OtTv1fnlBY7VZdbNmEFByRR1rLfzGzr44835O5xwjh5Qi1ew8wk/b+j9B0YzGp1NRuPJ BDHR5HYUKjSwPZliy+QBHzRBBbOw/kuCJhs8gjoQ+fO04CC4t2BLO3DBNE2Wo+/eFQ90vSmrclou 6PWiWBar6vvJp9HrSQ3r7Vk5e2yh8QbaQSmG6M7FH014dWAhCu6zoIK0oMZQ3aguIZE6H6SLMF4w 5tRLuIXGeiCZiqbCN52ASh5RpWVnz4hoz0VYF8XtfFVQTqsuviLho+o+r348gVI0KDudITB8HOdD FC9A6hCRgd5i4Quoog3qFEgb7DyPSZXJGsQZWEvLnk20H98CXW+KLSBtKV/RfIZv8+rx+cd8iz5Y lX8WK3wCbkEBbfTkW09i2JF3aCQOmt939Hm9Lja0yB/xua4JPUGh/DYKpUR/j330iylUOwr5ILKO zT1krxaL8mFLy8+Lar5eFHR5TflsBl63tCineVVutoHFjx0STb8m+64sWpB33vZc5dttOZ3nFbLz MK/uY2aarJ0gU30bmYqLqJCvYHIYXmNwiMYteMPF3VA2i0Kc0cfHUKH7BCYXYjhbSplMcGf62Wro onVRbOarux9gd0Z5ch74xBeUaOtJt55wPQ17cmhk0pp+shbF38WiwYGJBKWRTzclyiIHyorK27Y+ 9nJ3c59jiGlyp/u5Q7fXzoVZwzolY/dHM/Ypm1LhAlPEja6v6uVIcpUpHS/h9uliJBlvrmbrkNb6 qcTtKPYe3T4bHfWY7hskA/cNw4Uz6P7Q5A0OKWVZmJO0wGWJXzVDsScIA/F2UYBtq/sgQLw6iSzC GHYaUBxxOmgqhK+t0CYQ4YQMpjSI6YffBopCwbTkdCiXOFXgnLAqnLdKB16N1MKlSHjY9UBDdpYN vx0KYjBoFzpa8SJkRwejCVZv//IwQ8mEcUaYOL5qKAa/ewcZd208XVJPhPLlab0ZFIJpRwd0nDTL 8NR0durc9S6TZgbTtG7MiMk5HGLSS8PL5fUJ4dlD4WmJfwEd9yYO+8i+rtOO+TmUeQebsO3022Ep zBmM92tKeMyJfrBojzjtaG/Q+aDBkCJpmA1TsOI6asEbVo9gQwF3YXRStEPRUd4wtAhi2GnAcMTp oKnYOIwx0URdaRalK/vxn5KeTi8B6GgiKNfFSt2T3oCdZcNxT3oKwg160Qg2RsOtqZPTP7A8TFOt GW1c1IyCGii8w/RtPF1VT8TyPzI7LD53VHxp/PRJez3ZCbz08Pj24+LFiF4QZDfZ5KvtOt6wx0/g M2NKITfhSLmpTkjVH0o1qQRk1IWX1lQmRg50ovA+gZrck6oQKNx9nWp27HI54rGr0yOeB23WeWi0 Agk5vOS1a0LSj7mF0ZVqQtHV6SGu1GmGPcUCGvB0aOWmnxjOdu97SagsjJCiWbooTmnWNddJ3QvT ui/anpVlh+2eaJMwwv2PnLVrwnl4ZjmYtmTJ15aaZpLWnqUnquypiL4kx8OixXvM6SuT82HZap1h huXMZrBvogB/e3vqruQHb7wsaNBj0G/n1Vp7PuMoGoOhUNZogEMTd2JXsdpCTXuPQn2md5akJ6vD zEmf8POGvtrqPYiTzGVOgIu941LgO4tPuya8hYhid9qP7duN3Dc5/E+AAQA/nXlXDQplbmRzdHJl YW0NZW5kb2JqDTEyIDAgb2JqPDwvQ29udGVudHMgMTMgMCBSL1R5cGUvUGFnZS9QYXJlbnQgOTEg MCBSL1JvdGF0ZSA5MC9NZWRpYUJveFswIDAgNTk1IDg0Ml0vQ3JvcEJveFsyOSA2MiA1NjYgNzgw XS9SZXNvdXJjZXM8PC9Db2xvclNwYWNlPDwvQ1MyIDU1IDAgUi9DUzAgNDYyIDAgUi9DUzEgNTEg MCBSL0NTMyA1MyAwIFIvQ1M0IDQ2NSAwIFI+Pi9Gb250PDwvVFQwIDQ2OCAwIFIvQzJfMCA0NSAw IFIvVFQxIDU4IDAgUj4+L1hPYmplY3Q8PC9JbTEgNDMgMCBSL0ltMiA0OCAwIFIvSW0zIDQ5IDAg Ui9JbTAgNTAgMCBSPj4vUHJvY1NldFsvUERGL1RleHQvSW1hZ2VDL0ltYWdlSV0vRXh0R1N0YXRl PDwvR1MwIDQ2NiAwIFI+Pi9Qcm9wZXJ0aWVzPDwvTUMwIDQ1OSAwIFI+Pj4+L1N0cnVjdFBhcmVu dHMgNj4+DWVuZG9iag0xMyAwIG9iajw8L0xlbmd0aCAxODAzL0ZpbHRlci9GbGF0ZURlY29kZT4+ c3RyZWFtDQpIiaRX227bSBJ911fUYxIgVN8vQBAgVoKFB8lMJtZgHpJgwJUoW4ElaiV6PNmv39Pd pESRlBRvEtiU6O6qU1XnVFeP32yr5SKfVfTq1Xj6fVPQ+GN+u1zn1bJc0/jqqvyHPnOmMyHJsszj oybuXKY9WSUzq5ny9HX8pqry2V0xp8/jabnBxrKqyhWN3xeLisaflrd3FX19/frq7YRG498mNP4w YZS+TW4YzXbEiWWOc2vxZEx6QbSbrUeclljzL6y53Y04V+Rl5gCDk7SZdCRVpmlbjBaj/4y45pm0 3nviQmWMcyboZVomdOZMWPfnC1pjKSNhMs4Y7IQVRhCjsB3BieCAaUGz1Wh8vWL0thz9jv8sw6L4 42poyiIt0R2TmeEtUDKTe1BOBfNcisxaXvsLiFzm3TEinwnRgoONNpnHXqOZ5jUk3kCCdYtFgizP mEzGZSZUCEupOr62C7zU0si4TLngBPsdnLhDdZMPcQibM/z5+JHiBy1ghAte59qJkGSRIXdN8LCK mDyybwFOZMoESAaZs6YLLrxFuF6FhTaCY5mM4GAATNuDkwncuw/gT/w1/hj4+2Fy/Rbbapq1K2ZA KJlQR75Nbqj3x5vJr9jhHD2Cix9g5xt+fqHPXxnNaXQ1HY2nU2Ci6WIUGMosTWeRq8g8TR+xmKag MQvP/5Kg6RavIBHAf5ke2I0CWKRMOySEaZquRs8+bsuqnJX39O6+WBXriq5Xm/QpifD59Nvo3bSO 8/1VOf++j5U3sfa4GeBOxF8N3gg1gYywuImw0gPM48AXySIkyzRPyF4x5tRreIf2OsEHqkWTYHEQ WXocGdJ2b+jZFyHkpFz/jZgQUX6P7+pMWKIJq9UbQnpPBgavAUV6AIWCtgUUbi7F8jLWT9SxBOKp 1n7nQew6hDfzOeX0uM03m2JL+bZ8Ho119ygjQHhnTdz0cGIRRKe4TGvWc6ruCnqIdu+Lv4t72jSM CNsTRM57bDtYhfq9DTI5QjzPq5we1suKcviYlasVvszyqqDHZXUXnW4K+Dw4kQcnvOfEu4xDnPrY SVFz9mG3XN/C5nJHodjLNf0bXps6D9rR2qM83NhoaHd6ncFpY7lODjf5rDhDHdmlzhOU0RGFxNEi dEzrj4mCmWDsZfPxsS+PlsmuPH57qKhc0FUraydCVE9VRwruWCIS2lCJM5dVchBJCk51uNEy1ubG H7uC5stdtVxjvNhzuiopv78vHxMB67c7SuXv5W/vwuMIPE0/GC3+md3l69uClutFuV2l3hmZvqx2 kelncqqfTpsBxijU2T6dMT2atOx0afKpWBTb0EYvNlHzk00UJ3XTVZ7QR4+K1jLR5UWOkz9GMisi I0Lr2M5pk2+r77Qpl6hpvsPrVZGvd60WpU+3QeXsUIeCqELxQ3v68qzIbjN6++sNXc9DEhdL9L9P n3Zfnh8l8uYuxyDcJNL2uWG0c2FetU7JOEHgLPcptVJhCFJghq7HvdVIcrR7HQe5/dv7kWS8Ge+s y5Sv34I4OCHarxYvRic9ppkFNMLMwjC0DLrvm7zBJqUsC7O2Fhi48FUzb+sQBvC2o3CAobtBYCxX ZyOLYQw7DVGccDpoKsDXVmgTEuGEDKY0EtOFvwcKPWHidjowO06m2CesCvut0iGvRmrhEhIeVj3S kJ1Vk99WCiIYCTTRihehOjoYTWF11q/6FUomjDPCxCuQNj6Y8g59tm3jMqUuQPnxst4MCsHtp01o P83DvC3/enzYt8bYTczh5HPJORzyRpzXH88Iz/eFpyX+hei4N/HCiOrruuy4gwWat2ITdn+DamVJ YERjvMsp4XHX8IOkPeG0pb1B54MGQ4mkYTbcpBTXUQvesPqQGQLcDqNVokMULeUNhxaDGHYaYjjh dNBUbBzGmGiiZpoFdWUX/znp6XSRREcLfTtcP8HUI+kN2Fk1Oe5IT0G4QS8aYCMabk1dnO6GVb9M tWYwYkbNKKgBT9+zcZlVF7A8obLD4uPspPrSbdTXp/ix7oTXGZfhCHa4mXmGZhB0N93iWN2kmevk DvzOmFIoTjxHt9UZrXLeF2vSCdJRUy89E1GMHOhFWJ6BlUdiFQLUPVaqZqeOlxMe20o94XnQZl2J Ri0QkWPS758pki7mfRhtsaYo2krtx5V6zbCnSKEBT30rN73KiD1xaqmCqD6UOj3aUZxTrWsOlLob puexbDtWVq1sd2SbpBEmANRs/0xx9vesBsuWLPnaUtNO0rNj6QLLLiH6kRqfkK28cGhyPqxbrTMF lyzO/ybNze/PnZa8dy9kQYNecbGfWGvt+YyDNBjOuayjQRyauBMHxuLi4dzRq8DPdIVIerI6TJ30 DT+/0P9t9Q6Jk8xlTiAXR9ulwGcW37ZNeFvfNTvYft7IXVPD/wkwAIdS+xENCmVuZHN0cmVhbQ1l bmRvYmoNMTQgMCBvYmo8PC9Db250ZW50cyAxNSAwIFIvVHlwZS9QYWdlL1BhcmVudCA5MSAwIFIv Um90YXRlIDkwL01lZGlhQm94WzAgMCA1OTUgODQyXS9Dcm9wQm94WzI5IDYyIDU2NiA3ODBdL1Jl c291cmNlczw8L0NvbG9yU3BhY2U8PC9DUzIgNTUgMCBSL0NTMCA0NjIgMCBSL0NTMSA1MSAwIFIv Q1MzIDUzIDAgUi9DUzQgNDY1IDAgUj4+L0ZvbnQ8PC9UVDAgNDY4IDAgUi9DMl8wIDQ1IDAgUi9U VDEgNTggMCBSPj4vWE9iamVjdDw8L0ltMSA0MyAwIFIvSW0yIDQ4IDAgUi9JbTMgNDkgMCBSL0lt MCA1MCAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4dC9JbWFnZUMvSW1hZ2VJXS9FeHRHU3RhdGU8PC9H UzAgNDY2IDAgUj4+L1Byb3BlcnRpZXM8PC9NQzAgNDU5IDAgUj4+Pj4vU3RydWN0UGFyZW50cyA3 Pj4NZW5kb2JqDTE1IDAgb2JqPDwvTGVuZ3RoIDIyMDcvRmlsdGVyL0ZsYXRlRGVjb2RlPj5zdHJl YW0NCkiJnFfZbiPHFX3vr6hHx4CatS/AYICRZmAoGMVKRCMPg0FAU5REQ81WyFZk5+tzblXv3SQV S5CK7K66S91z7rL4tK+2D6t1xT58WCz/eNmwxe3qcbtbVdtyxxaXl+Xv7JvgJpeKOZ4HfDRMeJ+b wJxWuTNcB/Z98amqVuunzT37tliWLzhYVlVZsMXXzUPFFv/YPj5V7PvHj5efr1i2+PmKLW6uOEvf ru44Wx+YYDz3QjiHlXMVJGOH9S4TbIs9P2HP4yETQrOgcg8zBFMuV54pnRu232QP2b8zYUSuXAiB CalzLgSX7CJtkyb3lvb980e2w1bOpM0F55BDO6xknNFxOCdJATeSrYtscV1w9rnM/o5fnmNT/PO1 adrhWqI6rnIrekapXLVGeU3ihZK5c6LWRxb5PPihRSGXsmcODrokHmet4UbUJonGJEh32CSZEzlX SbjKpSa3tK7966vAQ6Ositu0JyU476HEd9FNOmTntuB4PVyS/4AFhAgp6rv2ki5Z5ri7xnlIhU8B t+9gnMy1JZMsbs7ZsXH0FO4GTRtdNI7nKhoHAUBaa5xKxn25AX7iv8Ut4ffm6vozjtUw60fMAlAq WR3xdnXHJi/vrv6WUWzfAMUbiPkNf39l375zds+yy2W2WC5hEls+ZARQuLtcs4v40bDlGzazJVDM af0vw9s9Hmm8R0jTgtPaNCE1HldCJ4vsh5vyfvuwBXlu92VVrstn9uV5U2x2FbvcPK3+sy1f939Z /pZ9WdbO3j2tQNTGYdM4DE+M98Qj57WKnkFDSG4rDoVAnRC5NISUIpOeA+/dk+dMWsQFm0CB4OpH oeFJ/+nDj8e1pXvkli6S4yZnVc9KvcM5rR2nFGAkcICvhgeXPBib2zggwGSpeuYLFQiQ8/5Ey+eV kOEzSqYyyE7jpLHktJeKZBhcQt/OxirQHGT3hgAQSYEj0mk66rSh67PKSJ+0C9r1xkYiiuYGO0+j BQomxPNB0vUbEhfFjLYX0wgkCdZbaWPaNTaQpOC5Hog4DZfTVpyP190snm2LZ/ZY804k3iW24SiY xxPnIsuEjSxLC2eKw6WQWBZi4owsu74dkKguO+QBfsgDEWwsQoioqUNpQwNTJMwQajdAZ+Tc7hGA hghKbXMn6u/GxhzfexSBd0RXjzLHdE4F3o0vznWJQFnuKFlrYSLOg+V10p4Y3/pDRUz3/BG4Tynm /YMz8RaPaYrxn9Ekz7jgOxe0tTZKrAHmgFY18KEzOJFMKN70AviQqhVSlCR6+gjPIcnGUore3fcv I6YlkJQoYrgI0RrhbB24uUPFbBhrxhjrI2O0EmRamBN1Bm/nTHpXkOfpF47SL7LPhcS+EeekFbmA ePQwRtWEW+5Xu8MLke7odrQ4SJxSxP3lvjpR5kRb2DvqJvrgCmoQpjVhhCwZZh8edfYTGDWyelKG JKycqxpHtA3IO9U6FXbXcCeRBRzy6EDaNZk/Nra1v0ufnfVdxZv3KOWeeW0RL1Nt84ImhIXSlrGJ oQBmoBinpe/MiZLom+pR58e0Duk6FFLUdz2siYkDVNERrHZNPg62F5NQJQGhFtDkjbT2BJxB1Dkj 3hHWeVpiy+myKMQ8MdGdG5GKoUQ2oHGNyPbL12E5/HpZ3v/RaZtybTT8kAVX8l9NR9zqRta9SAt0 4wN56+NokRR/4NzrjzEnPI5bate21HQ1sb4DK+RNWlqJirtO4g+fnqvNnlVPG5YyDvJI10lXJVs9 P5dvbMXI33RXdl64DoidRys0lL97LX6FgvKBPZfrVVXuDyT11w1bHQ7leruq0Lm/baunqKCXJJMn 4YgnXmEUcChxQ2UrdtgcDttydyI6chwdtBI0fxyNSzRAqAQMVXdJIsRRlYJ1JjjtpUEWfdK1RzSo 6Z4oZCHdOrLJH3NgfnkKZurPwSy5M8SawkAlDc2K74ab7Sa4eUB0Mo8B7vqWvfSQdnh9iei7vr3Y 7i7wsoOcmoeBCiL3xk9gcKj2r+vqdb8B1p5WFbvfHqrt7vF1e3gC8qq3zWbXwc1MRtGRFi0NshDg NtKyft3vMWZe1Li+WN3fQ+OBrXb37GWzP0ApvW4V6d79j1Wg1dYOs8xIxUj0CTDo/xfVI0DrYGJu eC+gY45pWArSDzHdSBtgeptvcnZzfWvnJwmLRE9dvcMsSBi2jpu6nmunclQ4NMCU5WFvkWmtc697 j54zHIsJUwsq5+mRjVNU70ks5kdU9XuROZUTYdOCrnotuHY8tuAy6FjHeHC1O2PbW3f6DWbtTn+Q mPGwmyXm9ZFPc/qmkqbO6M4ZgzGChl2LLi5Vdq0GzkzGCalzp6kDqpsUK50mCY5GXJp4jfTDHmUi qWiiMJ4nmqnGNo0PyUyujg8U00gmGWi3JNnjhbHU0NnguR4IOQO3M4a8K8ZHuhVzpltRYpjK+y2L tgYaU8uC5tk17Lu+PTUe2GktabpJK4IV7biQYo7RaNjMaW7GzRyuJCc7wqAH1pLPjgdHtA0oOdU6 FUZRUfWIoYWJhIitezJ8bGZreddBdnZ3g8G8L9HweWURAlNl83LiPGqtjedrRKVxoG/0iQEAVPe9 tjvNA0NuDWUU9WUO+38NThIVDPquaENsxZMvg+3FJBY1HYz1kQ5aCTIkjAWcgcw5I94RvSOMckcZ 1Ws5p1xC5a/bfxpfFDUIoFJqlGNdP3HCa8qSUsQj6GtO0c9P6ZcIgHuo8ZXWCAgVVMwtfWBZ6lEi sPoUxNDi1BhuyqcxaozkIxr7FJzTPJV215SkRAZwxHMV2jX5MGNw340eH1snenycdSwlknmd5MUR nbOyptUwdNUwkRNYDVw2y8irE2z1TbGoU15aB3Sdyimaux9SNrGDqj2i167J2+H+Yhq8JCLUIprs kda+iPNAO2fKu4M9T1/JzxREIWb5q3DvPmlAkENoauEvXwfF8H8CDAB6wj44DQplbmRzdHJlYW0N ZW5kb2JqDTE2IDAgb2JqPDwvQ29udGVudHMgMTcgMCBSL1R5cGUvUGFnZS9QYXJlbnQgOTEgMCBS L1JvdGF0ZSA5MC9NZWRpYUJveFswIDAgNTk1IDg0Ml0vQ3JvcEJveFsyOSA2MiA1NjYgNzgwXS9S ZXNvdXJjZXM8PC9Db2xvclNwYWNlPDwvQ1MyIDU1IDAgUi9DUzAgNDYyIDAgUi9DUzEgNTEgMCBS L0NTMyA1MyAwIFIvQ1M0IDQ2NSAwIFI+Pi9Gb250PDwvVFQwIDQ2OCAwIFIvQzJfMCA0NSAwIFI+ Pi9YT2JqZWN0PDwvSW0xIDQzIDAgUi9JbTIgNDggMCBSL0ltMyA0OSAwIFIvSW0wIDUwIDAgUj4+ L1Byb2NTZXRbL1BERi9UZXh0L0ltYWdlQy9JbWFnZUldL0V4dEdTdGF0ZTw8L0dTMCA0NjYgMCBS Pj4vUHJvcGVydGllczw8L01DMCA0NTkgMCBSPj4+Pi9TdHJ1Y3RQYXJlbnRzIDg+Pg1lbmRvYmoN MTcgMCBvYmo8PC9MZW5ndGggMjAxMS9GaWx0ZXIvRmxhdGVEZWNvZGU+PnN0cmVhbQ0KSIncV11v WzcSfb+/go+7AUzx4/KSXAQBaiXYzaLudisBfQiChSJf2WotyZEVJNlfv2dIXpJXUpKi2QJxWziy xuTMmZkzH5x8tz+sV4vlgT19Opl/vO/Z5MfFzXq7OKx3Wza5vNx9YK+kMFxpZgX3+NUw6Rw3ntlW c2tE69nryXeHw2J521+zV5P57h4Xd4fDbsMm3/erA5v8tL65PbDXz55dPp+yZvKvKZtcTQWL36Yz wZYPTDLBnZTW4lMI7RVjD8ttI9kaZ/6OMzcPjZQt85o7wJBMW64d0y03bN83q+ZtI43k2nrvmVQt F1IKxS7iMWW46+jcz0/YFkcFUx2XQkAPnegUE4yuwzlFBoRRbLlpJi83gj3fNf/G/4LjUPhxCVpr EZZgTmjeyQqU5jqDci2pl1pxa2WyR4gc926MyHOlKji4aKN63O2MMDJBkgMkaLc4pJiVXOioXHPV klttm/yrTUBodKfDsdaREdx3MOJKdqMNVdyWAn8ef0T/QQsokUqmWDtFQVYcsRuch1b45BF9C3CK tx1B6hA52x2DIync9S0dtAGc4DqAgwIwLYPTEdyLK/An/DP5kfh7NX35HNcSzeqMdSCUjqgD36Yz dvLH2fQH3HCOvQcXr6DnF/z8k716Ldg1ay7nzWQ+ByY2XzXEUGE9my8DWUXH5u9xmM1BY0Gf/2WK zfcQoUQA/yJ+4DYSYBEy4xAQYdh80/zlane9Xq1ROv/YPaBW2E+7d4d+z15u8S8KE3X41/kvzYt5 8vT7y931x+ytHLw9YScBnqr/DIgD1ggzAJOeU3XED3APv4BHSqAEdAT2VAjXPoNplN6x71Jm3+lX 0qpl8DR+FIWgORSiR2RXP7LDbc/WxT32pj+87/ttkN9SEMjhoFyRmYsc7nN2EMrOeKGPTC2210Hf bH3o2YsP6wPbx7gedmxxd7d7/7fPRFUNUa2aE+X383GVBvE0hMl7bkIfUijmjOlzAbXF0eQnvKEE xY+Rzg7Hsp+z3bv9sr94s3gAg8jF9faGrXZ79vDu/n63P7DdKsT0gtwNBqhNnLOg0ROMd94eWYiq HxDHi76K40N/13+Jnfrr4qgtysZS/f+eOMpPuFmUjgN5TJT7xfLX/sBu+8U1vm1ClS4XX/C4/TqP Wwy43+OrPetq0DZyMrWY4mtqNv2H5e1ie9MTW0LxnddHDboTx0r3PUb/4s36bn34GC9/6p72HTfG uHBtvQVNN6cBnd0usIYMATVnAsppDtFk9DGwqgNzJX11AnOCCL5plIEt5kWaundJQB1Y6fA935Km xd4QZK7jwn5KlrXfnTN516yeBLkNY7eGkoWVVouZHmabs7y16eCpEHMaXZTGEo3UJ9URLELanB6p T3guzyipTtAIF+eUiEjbOBOtoZkoMBQlhqLEUPxmQn77B0d8FG7lacvZnBN+6tKQgc0X03IuKZsv p2pGqQJy7CDYZPCfTTWB/TZtj23HWxOUKQXLtUxJNyQE3d/6kQS/qWBw2VRSQbsouVy0OY+9jQ4W o1mEuxjVaixU2Np9TE9RV2S14SIdAGZ12YkTV5dUKW8Dat2SWdo+JU6FzRiktIaO0/KJ3RM9laPL UgPmXintWGQ/ds0hpPiDkL4D91NJaGlRE43USIrT5FKLHVfFpNVSNCtrCT6eFa3ogvMdtPngPLYv q0ayZePxXoiXs9BpNHlTacuCweiyGUQGmD1dKnpQAnBibDDLlk0FrZwsLmSF55xdogJnWLWVNFya lOQQbYkVHpFuhzfI6jedITJjMXaeQh14jEvimMdShIfHkH/R4eU4InGR1Fwq0sK6qKowM5urGYxd 1hwxGDFTo2II32trUZLLalBRSu/YsYG1gGkr0ro/iLBAJnUXGlolxcyWXkFasUKhf4N7I/5kWU3Y LBzImLUNgmy0EFZjS5BmRNiWlntNIIrBLBsRtpysHBsUnnN2ICztU0pCGrNmh9YuMS4iR9DeXBwc 4Ag92jQEPs0iGZ4fEqua1klEUGM+qWfpIxmxIcvwxJW0HA1Xj3HEVeIbR9dxDX5JW2ZVrm8pFfdy uI57SCS2FRm/W1oSXKA8vioxNG+B7jbM+iIdqfK8S2PDlr3gGMnjwBcDTa86neAJly1p3slxLpGE TheRcCEhYli0QAyRGp7h3alU0KNnnE8yZws7ajCPBSHi7UBWzMlu2LKUzDxX+WzMaV0zIecjeCb1 WKlEWgRH0pE22EtnLS2XoSZOwDwWiDJ1wpZqHB3By9RpOlU3hpRSaqS5zSiuYpvpfEmTbkPjxV5c CaDH+KFdpfUNPUb7kvHKfu5/3x6mHFfkq5WlsbRJCmw5M8d1YjHL0Vhc7DOFBgIb7XCoSMeqQuJQ EFKeZDgjeTwQh3ijnl1uLnkajVpBzCcsYWglFkswelju2izNoxFmy+zKUtGWYZgyC4syi04gPTqo 6AoyVrevWk2gfr0bUIrrGjoGB0hdaDGuaiYkGmmBkdxfrB5m4sj+N4zqbQi3V6OXCMLq/z9btiNM tP5CpemC04PIoMFYAxS0hGYY9ASIREhITJueRF+970O/tGE5L2Aq6QjPZDqD1geKRPpx6RUWNulQ x/G9gyxqLDsUWFk2nSTCMyAPeKPzxnpWWl83IEFtZHQQldb6k+uoBWPH1s+IqrtEyT+NM/SUeXE1 Zc3/BBgAsLwirQ0KZW5kc3RyZWFtDWVuZG9iag0xOCAwIG9iajw8L0NvbnRlbnRzIDE5IDAgUi9U eXBlL1BhZ2UvUGFyZW50IDkxIDAgUi9Sb3RhdGUgOTAvTWVkaWFCb3hbMCAwIDU5NSA4NDJdL0Ny b3BCb3hbMjkgNjIgNTY2IDc4MF0vUmVzb3VyY2VzPDwvQ29sb3JTcGFjZTw8L0NTMiA1NSAwIFIv Q1MwIDQ2MiAwIFIvQ1MxIDUxIDAgUi9DUzMgNTMgMCBSL0NTNCA0NjUgMCBSPj4vRm9udDw8L1RU MCA0NjggMCBSL0MyXzAgNDUgMCBSPj4vWE9iamVjdDw8L0ltMSA0MyAwIFIvSW0yIDQ4IDAgUi9J bTMgNDkgMCBSL0ltMCA1MCAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4dC9JbWFnZUMvSW1hZ2VJXS9F eHRHU3RhdGU8PC9HUzAgNDY2IDAgUj4+L1Byb3BlcnRpZXM8PC9NQzAgNDU5IDAgUj4+Pj4vU3Ry dWN0UGFyZW50cyA5Pj4NZW5kb2JqDTE5IDAgb2JqPDwvTGVuZ3RoIDk1NS9GaWx0ZXIvRmxhdGVE ZWNvZGU+PnN0cmVhbQ0KSImslm1v2kgQx9/7U8zLu5Oy3kfvbhVFAtI75VQaerjqiyg6ucYkVIA5 Y5L2Pv3Nem3ATuUDCUXOGjM78//tPJhwUJSLeZKWcH0dxj82GYST5GmxTspFvoZwOMy/wwOjinAB mhKLtwqYMURZ0FIQrai08BgOyjJJn7MZPIRxvsGNeVnmKwg/ZPMSwr8WT88lPN7cDG9HEIT3IwjH Iwr+02hKId0CA0oMY1rjSqmwHGCbrgMGC7T5A22etgFjEqwgBmUwEJoIA0ISBUUWzIN/AqYYEdpa C4xLQhmjHK68GVfERM7uy2+wRlMKPCKMUvTjLCIOFNx2hOMuAFUc0lUQ3q0o3ObBJ/yjBI2qy9TS pMZjqcJRQSJ2JEoQsRdlpHPPBCdaszqeU2SINW1FlnB+JAc3au8e90aKKlZLYo0k9K7RiINmhArv XBAuHZaUNd9xCHyoRCQqM2lcENxvMIg5ZNfH4AdsRvHr9uL5sSzQCeOsPmvD3SFzgmfXwKNXZLJ4 +hrFcSIjJynCk9NRV5x7irhWOkNdiaNEVOLQAVbaXpzw4t6PsX6qf+HE1e94dHeL2+oyO85YhAUl vOqq3kZTePPldPQxcLl9xVIco5tveP0JD48UZhAM4yCMY5QE8RylxilcuTLFQ4f4FQ0hxgqmbv0X OMQFPpJogOn0CwWLyFVimDJ4GlRBvAp++ZivM8jnUD5nkHzNX7J3v8bfgvfxGyzWYLWVOA2MOT37 29e3sZlUVXDdDj5ONpvF+gnKHO4mLxKmZVLutvBpl9ePopaYD8N89mMviDeC3vSFUzjifx8fFvWy qnNhkSv8K79g1eONq6IIe9d6YdeUGnmDobHpu7Da7mGbs8dOcrB+OTjEIYUOcTo51OkufYZk+64H SDRARxPJZbYfiYkquF8wuOKEYbdjtvfB+3B87tq1xF0DyIMzzqybSDXJ/dcyWawhgWWeJksYTHuQ 5EWQTFQNsBOQDhydejwgeWc/RZrcwXaTpFkPkLoEkMCBdWKOPBDvyVHtrA00mL1k+F7dZlVfN1yu qZLlEnabbVlkyQo2Rf6ymGXFtoc4ugixUqemsAssu7zeVZv393y5zF+hyHclzpMeGt2lOWN4dOaG sPjmUtXr8f9HR6swuwPjyFNrZtwXfePCnJuYTk6koO7XxslFKPdNxTsp8Z7aGfmMtTcZ1HU3L/Cn mHvRNAXXg2UvUW8yOocs6vJEXZpDPy3KpotybK3ivF5i9By4n3FZS/Ay5iKtdPB2ajf9J8AAy2Sh Ug0KZW5kc3RyZWFtDWVuZG9iag0yMCAwIG9iajw8L0NvbnRlbnRzIDIxIDAgUi9UeXBlL1BhZ2Uv UGFyZW50IDkyIDAgUi9Sb3RhdGUgOTAvTWVkaWFCb3hbMCAwIDU5NSA4NDJdL0Nyb3BCb3hbMjkg NjIgNTY2IDc4MF0vUmVzb3VyY2VzPDwvQ29sb3JTcGFjZTw8L0NTMiA1NSAwIFIvQ1MwIDQ2MiAw IFIvQ1MxIDUxIDAgUi9DUzMgNTMgMCBSL0NTNCA0NjUgMCBSPj4vRm9udDw8L1RUMCA0NjggMCBS L0MyXzAgNDUgMCBSPj4vWE9iamVjdDw8L0ltMSA0MyAwIFIvSW0yIDQ4IDAgUi9JbTMgNDkgMCBS L0ltMCA1MCAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4dC9JbWFnZUMvSW1hZ2VJXS9FeHRHU3RhdGU8 PC9HUzAgNDY2IDAgUj4+L1Byb3BlcnRpZXM8PC9NQzAgNDU5IDAgUj4+Pj4vU3RydWN0UGFyZW50 cyAxMD4+DWVuZG9iag0yMSAwIG9iajw8L0xlbmd0aCA5ODQvRmlsdGVyL0ZsYXRlRGVjb2RlPj5z dHJlYW0NCkiJrFZbT+NGGH33r/geu5UYz82esYSolrBqqZYtLZb2gUWVcSbEC4mpPZBuf33P2HFu RNGyQsiM43xz5pzzXZz4feOrSVF6Oj6O82+PjuLL4q6aF76q5xSfntb/0rXgCZOKDGcZbhMS1rIk I6MVMwnXGd3E770vyqkb03Wc14/YWHtfzyj+6Cae4r+qu6mnm5OT07MRRfEfI4ovRpz6T6MrTmVL gjizQhiDlXOVSaK2nEeCKsT8ipi7NhJCU6aYBQ1ByjBlSWmWUOOiSfRPJBLBlMmyjITUjAvBJR31 YTJhNg1xn3+mOUI5yZQJzoETIlJJnMJ2iJPhAJ5IKmdRfD7jdFZHf+KPMwR1l11S0wa2dMdxxVKx QUoxtSJldYAXSjJjxPK8wMiyzG4zypiUG3Sw0fTw2JsmPBFLSmKgBHSDIElGMK56cMWkDrK0Xurb PAIPE5WqLkzbcAj2Wxxi19ntz5Br2YLj6+2l14+yAIiQYum1lcFkyeDdIB6o0JTBfQNykuk0UErh nEl3yYWnkJvpEGg6cpypjhwAUGkrcqon9+EC9dP9iy9D/V6Mzs+wbVlmmxlLUVCqZ93V2+iKXnx5 NfqEHdbSArV4AZyvuH6n6xtOY4pO8yjOc3CifBKFCuUp5WVXqwLPFoilHFXMw/ofScobPEKHgP1R v2Az/DdwLLHwgyeUz6KfRvVshlY7b9sn177Lv0Yf8qWmj6f1+NtKlxh0vajDQG0k/x64dbR6Rh0H kXYc+gVVhpuQtRS9kvUcjjm3+gRHo8l2VSYB7mi4DaAo3NBX/bLGw0wAHoZBEPVb3Xq6LVoMhIe6 LHzdUDEeN65tqXUPrgzT5YBWOWjdGA7B4MNqheqI9QuIoZ1N0vVPZtbcDomVa7F6KTYUo95CkyIL A2KldEG+pseqvCc/dfRFSnXrWo9Vv+tO2QOh0X4cU0x3EG391JRuZdQEV0Bq3LNrWkcdSqBksg2x a1SLQkgym+wQeyzKe+d/OeCyeq3LOwYrkbyJtQHnh00Nm7ftHCNweIENnlaTgNM4KpoNQ0PjlltM 0J88e+nlrMY2Py3mVM+B8VxUD8Xtgztkrt419xVtu9OxyuJ1or+7Y83KaUzmvS07AG617JnzfV9S PaG584u6uSf06szNPU2g+KlxB/Qmb9GyWuClaMLA/566OhoKa6ua1hh7a2rcyVw112Php4O6Q+lM X5/OPZnUGPx4Hf5AJu3eRA54W4m8wpQNabyEwKr1bl4eypt5k7yFH2VvNmrXaHsz2C4qX06H1m67 eYkfsNWzw7ulk95uZfJ/AQYAI5yD+g0KZW5kc3RyZWFtDWVuZG9iag0yMiAwIG9iajw8L0NvbnRl bnRzIDIzIDAgUi9UeXBlL1BhZ2UvUGFyZW50IDkyIDAgUi9Sb3RhdGUgOTAvTWVkaWFCb3hbMCAw IDU5NSA4NDJdL0Nyb3BCb3hbMjkgNjIgNTY2IDc4MF0vUmVzb3VyY2VzPDwvQ29sb3JTcGFjZTw8 L0NTMiA1NSAwIFIvQ1MwIDQ2MiAwIFIvQ1MxIDUxIDAgUi9DUzMgNTMgMCBSL0NTNCA0NjUgMCBS Pj4vRm9udDw8L1RUMCA0NjggMCBSL0MyXzAgNDUgMCBSL1RUMSA1OCAwIFI+Pi9YT2JqZWN0PDwv SW0xIDQzIDAgUi9JbTIgNDggMCBSL0ltMyA0OSAwIFIvSW0wIDUwIDAgUj4+L1Byb2NTZXRbL1BE Ri9UZXh0L0ltYWdlQy9JbWFnZUldL0V4dEdTdGF0ZTw8L0dTMCA0NjYgMCBSPj4vUHJvcGVydGll czw8L01DMCA0NTkgMCBSPj4+Pi9TdHJ1Y3RQYXJlbnRzIDExPj4NZW5kb2JqDTIzIDAgb2JqPDwv TGVuZ3RoIDE3MTQvRmlsdGVyL0ZsYXRlRGVjb2RlPj5zdHJlYW0NCkiJrFdtbxpHEP5+v2I+JlG9 7PvuVVGkmESto7h1C1U/JFGF8TlcCpzLnUPdX9+Z3TtY4DCOFFuwcOzOzDPzzMsOXq+a8nYybeDl y8H44a6AwdXkc7mcNGW1hMH5efUvfBDcMKnAcZbjRwPCe2ZycFoxZ7jO4dPgddNMprPiBj4MxtUd HqyaplrA4H1x28Dg9/LzrIFPr16dvxlCNvh1CIPLIYf4bTjiMK1BAGdeCOdw5VzlEqCeLjMBJe75 Cfd8rjMhNOSKeTRDgHJMeVCaGVgV2W32TyaMYMrleQ5CasaF4BLO4jZpmLe0788XsMStHKRlgnOU QzusBA50HMFJUsCNhOkiG1wsOLypst/wnzPcFF6+NU07dEtQxxWzIjFKMbUxymsSL5RkzolWH1nk We53LcqZlIk5eNBF8XjWGm5Ea5LoTELpDjdJcIJxFYUrJjXB0rrFl6rAh0ZZFbZpT0rwvEclfhvd qENuYQuOP+8uET/SAoUIKVpfe0lOlgx914FHqYgpR+87NE4ybckki55zdt84eopwc00bXTCOMxWM QwHItI1xKhr39hL5E94GV8Tfy+HFGzzW0iyNmEVCqWh14NtwBAc/joa/ZBTbNVLxEsV8wdc7+PCJ ww1k5+NsMB6jSTC+zYigXMN4Cmfho8Kna9wNY6Qxp/U/kDBe4SONGzCmccHj2nQxNR59wg2MF9mz q1V1V9WTeQ231QomsCzWgM+aalrN4e28WBTL5vn4S/Z23MJ9f17dPGwgiw7yAUXJ7KH8q7ObTObR 1mCdsMTBs7ggAfEDBpQWjCfmNdr2knOvX6FuTMDEBRG4jAKRygQyLlsxWB42Yp79fHH14yMQZAch KQfk0aMghAo644I6jWRCxuWE6cFyIbbhc3l0iSTi6UQY5oYVbYhGs3IB10WzLoolOm+yrO+qVQOT 5Q1cXMF88lCsHoGnvhVeMGgfo7dUGZ6MUSYQ9xG2olKEV6uiRp7VyL+6mVzPCyhv8HvZPEBTQTMr oNnAPoVXfw+8SnLMekr/p0A+O4U5EZfCfj2fV+saFvfzprxD0PNqOmmqVU2grwu4ru4xxK0DCPHZ AX+E2Nekc6ZRkdnV1Lnzh8CaabVY3C9LVFagrllZw3W5vCmXn1NlfKOFivueFkddOHe7SlbFomoK KFDDR0o6uGvryMfnj8TLfEu8ekKlhWzr2pPZqbYePHBgIq4nVOQcitIcZlXdkLvqddlMZ1BX96tp EsFy+dSIaS2Ydjl1r1QhaSq+YtSgusWi3Kyr1d9wOynn96uC9BbLmj7VRV3TuNRGbFcy9jDjcux+ O5Lx3NfyazG5LufIiJ3ItBHAGu6lMrgay53frCEm0mL/NqGPWNPOFYsMtzPuk0fzTErJlMVO6pGR 7SPDux6UPL19kR3VGDsjt9QaOfbGY+p7BY/wqMktJ3nKY6vdrBHJvs0bGJ7SdQcFjn76OK6A4Igm QtCn6VDKKBuMZhOcg7vUsNvmao33NKY6r1UYHLB/tzCUxtlH7whXQh84aZ4pLnqcpBSnjnMA54hG gtOn8VAKeV8jB2mqNhJHK/xqOBaNaHWPianhSQi2didR6AcTLO9XGgzvV9orKpDHSWMJO5KTRBn0 xb75G0NxBsHZ2hsqS2EGxXOYeHTeaUOutMrIltOCdq2hT86i82/igmCMQmuClFxSQAwJTeNxKCGN Pomw3kobLjvGEkVt7nGYPBrTXhadMOXpYR21RWeX827DeazbcfQVaZeNtTvMj6EL2LZh42XMR72o S3S17uJqp77tqvL7nYeA4R8BE7kVmzoYI44XLWJ4msNuc01K656VeCnZp5PMsSLkvXw9ojQpfb3K ewW2TsWf2jqqhQm5EIpTLHs9VqdY0uK3gZLWv158AUm/0lAB+5X2ijqog/m2DmprbRDdMtAhpdU+ rsdS0sSrJBY36pF0AUUG76Rkj5xFF4C9lNSY0JRHBkEEa4SzbeT2DywOY9jmkrE+5JLGLME1P5Bx mnInbPmGiPcnpeBHs3JzjelJSpkbJhSNvV6xPOdYJCgp4xUmTixHT+A741pjcOgIDv6PJLIQh5kc iYFuyUlwXNKu/xhHfFfW2sSMa9rJk7BuB5I9csQAUP9Brm3WKOXwzKJ3somS8lZSR9q47kk6MY2d sugps9ARcsgTJVv0l2xpDNOokjuG8m2I8x/vHyvY4uAuyymFc5zZoRtY2lrtmZeoGXXiXKLaBMRb mODhqZfbGpc7mr+JcslTKmfxHhLLsDM0gcIXfL2D7yB/1jnzfwEGAFrmjzENCmVuZHN0cmVhbQ1l bmRvYmoNMjQgMCBvYmo8PC9Db250ZW50cyAyNSAwIFIvVHlwZS9QYWdlL1BhcmVudCA5MiAwIFIv Um90YXRlIDkwL01lZGlhQm94WzAgMCA1OTUgODQyXS9Dcm9wQm94WzI5IDYyIDU2NiA3ODBdL1Jl c291cmNlczw8L0NvbG9yU3BhY2U8PC9DUzIgNTUgMCBSL0NTMCA0NjIgMCBSL0NTMSA1MSAwIFIv Q1MzIDUzIDAgUi9DUzQgNDY1IDAgUj4+L0ZvbnQ8PC9UVDAgNDY4IDAgUi9DMl8wIDQ1IDAgUi9U VDEgNTggMCBSPj4vWE9iamVjdDw8L0ltMSA0MyAwIFIvSW0yIDQ4IDAgUi9JbTMgNDkgMCBSL0lt MCA1MCAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4dC9JbWFnZUMvSW1hZ2VJXS9FeHRHU3RhdGU8PC9H UzAgNDY2IDAgUj4+L1Byb3BlcnRpZXM8PC9NQzAgNDU5IDAgUj4+Pj4vU3RydWN0UGFyZW50cyAx Mj4+DWVuZG9iag0yNSAwIG9iajw8L0xlbmd0aCAxODM0L0ZpbHRlci9GbGF0ZURlY29kZT4+c3Ry ZWFtDQpIiaxXXW/bRhZ956+4j0m3Hs03Z4ogQKwEixRx6q206EMcLFSZtpi1RFdi4Li/vmdmSImi KNlBm8AamR6ee8/9OHNn9GZdlzezeU2vXo2mj/cFjS5nt+VqVpfVikbn59U3+iS4YVJRzpnHV0PC OWY85Vqx3HDt6fPoTV3P5ovimj6NptU9XqzqulrS6ENxU9Po1/J2UdPn16/P344pG/0yptHFmFP6 bTzhNN+QIM6cEHmOlXPlJdFmvsoEldjzb+y53WRCaPKKObghSOVMOVKaGVoX2U32RyaMYCr33pOQ mnEhuKSztE0a5mzY99sPtMJWTtIywTlwwg4riVN4HeRkMMCNpPkyG71fcnpbZf/Bf86wKf64xjWd IyzRHFfMio5TiqmtU04HeKEky3PR2AseOebdvkeeSdlxBy/mCR7vWsONaFwSrUtAz7FJUi4YVwlc MakDLa0bfl0TeGiUVXGbdsEI3ncw4nbZTTbkjrbg+PP+kvijLAAipGhi7WQIsmSIXUseqODkEf0c zkmmbXDJInK57TsXnoKu12FjHp3jTEXnAIBK2zqnknPvLlA/8WN0Ger3Yvz+LV5ryqybMYuCUsnr WG/jCR38cTL+mIXcPqAULwDzBT8/06fPnK4pO59mo+kULtH0JgsFyjVN53QWvyo8fcBumqKMeVj/ JEnTNR5pbEBO04LXtWlzahxiwg1Nl9mLy3V1X21mdxu6qdY0o1XxQHhWV/Pqjt7dFctiVb+cfsne TRu6H86r68ctZdFSPijR4PZY/q/1O7jMk6/RO2FDDZ6lBQUoFPOxZiR3LPfJu1ecO/0a1tGC/SD4 bRBkgkVVB75p2UNUZov44uMv8PpfJxjJllGrDt/BrE/K8FiVz2SU79Kqhyk1eF0+k/cXdPVifB5y Id3Vy5Pc1D/IzeXMuWdz0wmpT6gB6RIan1v90wkOus8B6h0a4Kj3qINgMy2clOSNOklI0nN8F2KX GN8kJgiF3kezkOSWxJvr6zIeY9UNzVZUXqOLypuyWNNmUS7pbvaIr3VF9aKg+7bbAuloxHbCvrOk LVMiKNKepQ0Ov/+zE/Eyfzdeec5MPNmeEa+zg4DpPo0dXJfGFIHoRGlEd9V8VkORlrP7+3J1i/WR fi9oXq3qWbnCaR+j1VRVC65xGJqgivvg5SoG+u3HCVolCADaJEL3IB/KeoG9s10mEpOuBZyUygbN 2bOwzWHxbb6YrW4LGEJnXr38kaKqLh5/X5fXBC7rCsNKNHC2a/p+rrUxQ0G6is1x9fJEtu3fzLZ2 ljn97NaQxxPdInUJXBbrZVlvaFLWBb37Vta0rr7WxXoTemFdPKzD8031dT0v2gLY7BJ91prcs2OC 68b7fN8Ueq+4XRebzYlg5d8vh1EJ08EqmoPV4IRNs5h0/HkNEsMWvmGAaTB9Ulef1LWD6XcCiwIo WcGoXM3vvl4XGyrS+bwJMrOoNhh3O6H9NYYWm/GJKRtq1KucLWnnoMBYjeW5264xANJiWjNxarCm mSKXWRBs7jqP7jIpJRoDc5Nj2jePcFw1E0fn6c0P2VGLaQ6C/mEQ4piEjpkfBJ7gVeMtD3jKYbDa rolJ3+ctjZA1s8cCg74+zisyOGIpMBiydIgyyUaTxQy3nrYa3W6Ussa5cCnJnVZxTMS01tBQWoa2 6oIroQ+CdJcpLgaCpBTOK3lI54jFQGfI4iFKiL7WOQ93KCMxSONXw9GVyesBF7uOd1Kw87uThWEy 0fNho9HxYaODULF4cmls4I7iDFAGsei7v3UUIwxuUs4EDYg3Drwncx3ez7UJobTKyKamRdj1QEM4 yza+nRBEZxS8iShehoSYANrNxyFCN/sBwjorbbzaGhtK1HoHlT6a08EqesKV56d10ojOfs37bc1D JdNFR3SFUon9CTTqrm0GE4X7YzIOg7gFJo18f7kncvv2BD+UfKPwL9AT3oqtGqa8Y54Idd7t5HDr Vf0wSStxEe0XFQ4jFrYOVO0Rox0BHDQ+CNiElofBJKqpFiZ2RJSoJH4DXne5dCVwS6WrgoP8IpNh o1EHh40OQh2ooejcLLW1NmI3hZijslWf2KnOhCbEUwZRDo3tYiHvdeYAzrLNQK8zNfo6tJMBi+iN yG2Tuv4Ly8MkNi1lrIstpdEsWP0BxtM194Qv35Hy4d6EE8eaM02uvpkg99tSesOECvcUp5jH5CLS gL+erTb3aZY7+gY+GdcayYkj3Lo+1coDl9lUGAiLD8Bp6R7+p2rEterWdGZauwd6J627uaRXHCkB 4RhCrW3XhHL4znJwwElIvkFqizatPaQnhrKnPHrOSHSkOPQTyt3enPq5xs1GwyTHLVCEiy7y/N8P JyX74ALLQwt7LeKcEueWRqwdcxKWYRPjiWoaUOI7j0+d3Imcz6FtseQ6T4OepetS0uHchEGUvuDn Z/oH8BdtMP8SYAA/xvfUDQplbmRzdHJlYW0NZW5kb2JqDTI2IDAgb2JqPDwvQ29udGVudHMgMjcg MCBSL1R5cGUvUGFnZS9QYXJlbnQgOTIgMCBSL1JvdGF0ZSA5MC9NZWRpYUJveFswIDAgNTk1IDg0 Ml0vQ3JvcEJveFsyOSA2MiA1NjYgNzgwXS9SZXNvdXJjZXM8PC9Db2xvclNwYWNlPDwvQ1MyIDU1 IDAgUi9DUzAgNDYyIDAgUi9DUzEgNTEgMCBSL0NTMyA1MyAwIFIvQ1M0IDQ2NSAwIFI+Pi9Gb250 PDwvVFQwIDQ2OCAwIFIvQzJfMCA0NSAwIFIvVFQxIDU4IDAgUj4+L1hPYmplY3Q8PC9JbTEgNDMg MCBSL0ltMiA0OCAwIFIvSW0zIDQ5IDAgUi9JbTAgNTAgMCBSPj4vUHJvY1NldFsvUERGL1RleHQv SW1hZ2VDL0ltYWdlSV0vRXh0R1N0YXRlPDwvR1MwIDQ2NiAwIFI+Pi9Qcm9wZXJ0aWVzPDwvTUMw IDQ1OSAwIFI+Pj4+L1N0cnVjdFBhcmVudHMgMTM+Pg1lbmRvYmoNMjcgMCBvYmo8PC9MZW5ndGgg MTUzOC9GaWx0ZXIvRmxhdGVEZWNvZGU+PnN0cmVhbQ0KSImcV9tu20YQfedX7GMawNTeL0UQIJaD 1kXcupWKPhhGociUrUASVZFGkn59z+ySEiVRstEE9trr3ZkzM+fMrAYfNvV8NpnW7N27wfj7umCD 28njfDWp5+WKDS4vy2/sTnCTS8UczwN+NEx4n5vAnFa5M1wHdj/4UNeT6VPxwO4G43KNi2Vdl0s2 +FTMajb4Y/74VLP79+8vr4YsG/w2ZIObIWfpt+GIs2nFBOO5F8I5rJyrIBmrpqtMsDnO/IQzj1Um hGZB5R4wBFMuV54pnRu2KbJZ9k8mjMiVCyEwIXXOheCSXaRj0uTe0rm/3rIVjnImbS44hx06YSXj jK4jOEkOuJFsuswG10vOrsrsd/znOQ7FL99A0w5pie64yq3ogFK52oLymswLJXPnROOPEPk8+H1E IZeyAwcXXTKPu9ZwIxpIooUE6w6HJHMi5yoZV7nUFJbWTXxdF9g0yqp4THtygvseTvyuusmH3IUt OP68v6T4QQsYEVI0ufaSkixz5K4NHlYRU0D2HcDJXFuCZJE5Zw/B0S7CDZoOugiO5yqCgwEwbQtO JXAfb8Cf+G1wS/y9GV5f4VpDs27FLAilEurIt+GIHf1xNPwVN6xmX8HFG9j5gq9f2N09Zw8suxxn g/EYmNh4lhFDuQtsPI1kRerZ+CtOszF4zGn9l0k23mBLCSrzRVpwnSJHzoxHRrhh42X25nZTrstq smCzcsMm7KZ8mM/mkBIMTFbVutzUDEfqcloufhh/yT6Om5hHTxPotY1btHEf8ZSgD+XfLfaIOuGN CEXISSdpAQslLhuindQBbCF9A+U7zr1+D/cQYicTF9v4p8fBdkw5uzP1ZjQc3/5IoXS0T9lL5TlE KgzAGTJnRaM36c2LyCIwTSYSRptChuwo2rR0bSqOrS3En8uqvvg8qVCGqlw8x25YP01qVhV1xZ7X bPm8qOfrRcEojg4fojMRRL838FhSczvwtiink7rcVA0DqqKq4PDVGYqutmlSypDmXp0js4Pdn6PG 4D7k4dNk9VhUbAsdCSpWDxd1eYFlmxXqSa1KRH9SlEXfUx6M2ffwVEw29ecCOZ9N5ovnTfE/86F5 iCz0r0/JK0q5s7qP+qpYI/6Yjuvb0cdhLGm5LjZxokLkW77YHTdDvwvMV0hIHbqYr+ricTOvv7Ny 1uafFd+msSJnOoRsO0SbRHQ74z0NXue1iq0QPSmktCqByRIHiPCYc4YqucyktzS8dluLTDoMv3Qw hDy4tKs4moCj/HR3Z2+zk05T/0Va0H85GvAJBP2GR7iqteP0ejASIwS/Gh5ciuUI9S4QLkG+gzCE aQbaqeBiGP3uKIo+d712CLVx0ljKgpeK7BhkZR91AxG0UJIsgMW8mbC4Jp2m604byqlVRvqEQtCp r+zQzLKb1230EYkClGgjSKqLIZPR1PGNZW91kh3rrbTxNWdsIHvBoxEfGjpPqvN4XlPPUa8G1HZK QvVppou+SZZaiE2T0TaNilt6awm0Q3qNRS1e354RnD4WnFH4RzGJYOOLF1U3TbnxFEvElugtITRx adsQZ7cLWuL95uNLV0q8lUSza2Xb6Tq7kawn/HY0d8p/r00qj7Lc0YNQCxNlECxvHhx9mLuRuJDr o0AC/Ihz0cU4+p1GTvQ77TUVu4W1NppoWOZAW3WIf4uUxAd2Kd5+2sAP6T2MZiZJtz6ydF95x3aW nTR30hABQbokF4OZEwEJZ5sS9dxZ9tarEY6xPgpHQ2+M3vU9ll4m2UugXl/lfi2ak1rsvq8PVShR NfrkgUGeJJheyXGs9p61sadKEQ/jMX1GsPZYsEkoMNEQL62JJmgEzcfNbiPCUOh2MhF0LveHFVHx xFA54W5Pp/1ue21GNkSNQDqeHp7tmiLYw9pg33bQFnlnHPYEk9pLv49IkwMfPSYIZZIfCBeocmnZ YeyMQL8//3w7HJoGl9Z9GXYsLLvp25t+idk0x1GD7ZpCOLqy7K1CMhQaQ21jSOuhoTOMeQnN2aL1 S829MPaE6NeadLlOpELqQ2hfoH9+2ht7/wkwAEHi4yUNCmVuZHN0cmVhbQ1lbmRvYmoNMjggMCBv Ymo8PC9Db250ZW50cyAyOSAwIFIvVHlwZS9QYWdlL1BhcmVudCA5MiAwIFIvUm90YXRlIDkwL01l ZGlhQm94WzAgMCA1OTUgODQyXS9Dcm9wQm94WzI5IDYyIDU2NiA3ODBdL1Jlc291cmNlczw8L0Nv bG9yU3BhY2U8PC9DUzIgNTUgMCBSL0NTMCA0NjIgMCBSL0NTMSA1MSAwIFIvQ1MzIDUzIDAgUi9D UzQgNDY1IDAgUj4+L0ZvbnQ8PC9UVDAgNDY4IDAgUi9DMl8wIDQ1IDAgUi9UVDEgNTggMCBSPj4v WE9iamVjdDw8L0ltMSA0MyAwIFIvSW0yIDQ4IDAgUi9JbTMgNDkgMCBSL0ltMCA1MCAwIFI+Pi9Q cm9jU2V0Wy9QREYvVGV4dC9JbWFnZUMvSW1hZ2VJXS9FeHRHU3RhdGU8PC9HUzAgNDY2IDAgUj4+ L1Byb3BlcnRpZXM8PC9NQzAgNDU5IDAgUj4+Pj4vU3RydWN0UGFyZW50cyAxND4+DWVuZG9iag0y OSAwIG9iajw8L0xlbmd0aCAxNjg5L0ZpbHRlci9GbGF0ZURlY29kZT4+c3RyZWFtDQpIiZxX227b RhB951fMYxs01N4vRRAgdoLCRdy6tYI+BEHBSLTN1CJdiYnrfn3P7lISSVF2mgT2yqvdmTkz5+zs zl6t2+qqWLT04sVs/nBX0uyiuK7qoq2ammYnJ80/9J4znQtJluUeHzVx53LtySqZW82Upw+zV21b LG7KJb2fzZs7bGzatlnR7G151dLs9+r6pqUPL1+evD6lbPbrKc3OTxmlv04vGS02xInljnNrMTIm vSDaLOqMU4U1P2HN9SbjXJGXuUMYnKTNpSOpck3rMrvK/s645rm03nviQuWMcyboeVomdO5MWPfH M6qxlJEwOWcMdsIKI4hR2A5wIjhgWtBilc3OVoxeN9lv+M9yLIo/rgtNWaQlumMyN7wXlMzlLiin gnkuRW4t7/yFiFzu3TAinwvRCwcbbTKPvUYzzbuQ+DYkWLdYJMjynMlkXOZCBVhKdfj6LjCppZFx mXLBCfY7OHH76iYfYg+bM3w9HBJ+0AJGuOBdrp0ISRY5crcFD6vA5JF9i+BErkwIySBz1oyDC7OA 61VYaGNwLJcxOBgA03bByRTcm3PwJ/6aXQT+np+evca2jmb9ihkQSqaoI99OL+ngy8vTX7DDOboH F89h5xN+fqb3HxgtKTuZZ7P5HDHR/CoLDGXW03wRyYrU0/weq2kOHrMw/kuC5mtMQSOI/3kasB0V sMiZdsgI0zRfZd9drJu7ZlPc0lWzpoLOm2V1VUFKZxf0tngo19/PP2Vv5h3QtyfN8mEHlm/BHpAz xHsq/twGHENNQcawuM+DONIA6nFQmYQSKEAQNMJ6wZhTL+EayjsCnSSP4NKws2J8tOIiuPOzC/Pj IwjEFkHvHAiZPIqBa4Stgzetcw531u3dPR308/AZ+2MqoMGQhTTsLErGc7UD8G5TUlOXdNssijYU aEPtTUk3zaqkYrlcl5vNI/Dk/4UX49pj9DzI+6sx6j1EMw0xGRxCfHV729yDecuHulhVC9rcV+3i htqGipqK27Zcox+UFGBG09BtjHVkW+Ig8OgLQ+PbvIXEFbRBukJn2Xxef6m+lMXH6rZqH7aWmekl YWxd4xDkTtiRfRTgrqk35SNFUN/MMenimfwtHGPTHOssjgpQU1Vv2qJegGtXSNN1WZdrVKK4u1s3 aKxhdpekng816UNB1uqgEHfF4q+ypbJeFHebz7exw/9A9zfluoyMbj6j0OMiP8YlpXxuIPyhm2g/ Wjm63uIwtBJNLqyvnljrc+ulNnFtkt7i83pd1u1OkR+relnV1yDrcjJJR6J3aC7aHvApeKhqpJ+6 hFXJa7WEz3Aw44sSxamv8wHlOmqhnWjnwmXGOiVje8E57xPZJBq5ThcUj0+xY68yyVQuYqvez95m QanKhuYnwvVLp1mJ0jodLPRnr55lR/2mtoYkoK0x9LVjQUwavsxmlzcFboVbKel9w1HKsnBZ0wId G39q5m0HcwJQH6ZB95dDjCiG5sdhA2DM8jGvAeS012l7B7jMHhc4Abohf07I4EIjn2NcHQJwSbp4 2XTpxoNdwqqw2yodimFwbLkUHw+8u6dDK6teSXapuQyRSIQSjXgRKqqDzYR1vGE1WdZkxjgjTLxd a+ODOe9wcIzsPE3IJyL62ppfdnoZ5t/u8o9DNd21eDpXn+9uWPv2aNLlxWz7Dm7YyXW8irJ0WJxd DPQ59OfGLSFgw7+AjXsTHyOov06FF4CUxMEt7ry+o5ZRHbX2syAwXhE2rcUzSfBuFgTn8Srbn426 PeK3p9tj/idthjJJw2y4qyuuo1a8Yd21cCrmPhLP9gfQHgieN1vlTMOLQKa9BhxHvE6aCvErY0w0 0dHNgsJyDGAXalIhXkt++6QIQtTpuYJDUQQVu8jYgRAnTK16qe6lIsYEJQf1aMZ9jIlb05VpYs9q smadiLRxUURK8hCan7L0NNGeCurrKz0tSX9UkoM3wEiMAnXAG8pLvHbDizUocb4u6k13J5hezhXe Q3h+pCtBs24fkS5nh9pNmgGijoJpTITRIO8wB+G8tuPKCC7wto2nSF+3isU37pjrRxwORHvo+NDY 5bavJbVARA6v0d2YEEzE20fR1+weRF+zk9DS4TPtNhJo2u2krYN+ynsv06ReFu5YYjuMgA20LIL1 sZzdtuN0p2Uah3o+NLfqqjDScpJJuD2gjrsxoR6uXx2UMVnwnYXt8ZLGnoWnCfdUIF9f9Wn94iX7 eE/lfFrBSocXCuc2F77rpe/eDprpfwIMAA5QWqQNCmVuZHN0cmVhbQ1lbmRvYmoNMzAgMCBvYmo8 PC9Db250ZW50cyAzMSAwIFIvVHlwZS9QYWdlL1BhcmVudCA5MiAwIFIvUm90YXRlIDkwL01lZGlh Qm94WzAgMCA1OTUgODQyXS9Dcm9wQm94WzI5IDYyIDU2NiA3ODBdL1Jlc291cmNlczw8L0NvbG9y U3BhY2U8PC9DUzIgNTUgMCBSL0NTMCA0NjIgMCBSL0NTMSA1MSAwIFIvQ1MzIDUzIDAgUi9DUzQg NDY1IDAgUj4+L0ZvbnQ8PC9UVDAgNDY4IDAgUi9DMl8wIDQ1IDAgUj4+L1hPYmplY3Q8PC9JbTEg NDMgMCBSL0ltMiA0OCAwIFIvSW0zIDQ5IDAgUi9JbTAgNTAgMCBSPj4vUHJvY1NldFsvUERGL1Rl eHQvSW1hZ2VDL0ltYWdlSV0vRXh0R1N0YXRlPDwvR1MwIDQ2NiAwIFI+Pi9Qcm9wZXJ0aWVzPDwv TUMwIDQ1OSAwIFI+Pj4+L1N0cnVjdFBhcmVudHMgMTU+Pg1lbmRvYmoNMzEgMCBvYmo8PC9MZW5n dGggMjE0Ny9GaWx0ZXIvRmxhdGVEZWNvZGU+PnN0cmVhbQ0KSIncV21vG7kR/r6/gh97B3jF1yUJ BAFiJehdEbfXs4B+SINCWcu2rpLXkTb1pb++z5BccldSfEabA+ImkLU7ImeemXlmOJy92vXr62Xb sxcvZovP9ys2+2l5s75b9uvujs3Oz7tf2TvBTS0Vs7z2eDRMOFcbz6xWtTVce/Z+9qrvl+3t6oq9 my26e2zs+r7bstnb1XXPZj+vb2579v7ly/PXc1bN/jJns4s5Z/FtfslZu2eC8doJYS2+OVdeMrZv 7yrB1ljzR6y52VdCaOZV7QBDMGVr5ZjStWG7VXVdfayEEbWy3nsmpK65EFyys7hMmto1tO5v37M7 LOVMNrXgHHpoRSMZZ7QdzkkywI1k7baa/bjl7HVX/RX/eY1F4eMSNG0RlmCOq7oRI1CqVhmU06Re KFlbK5I9QuRq76aIfC3lCA422qgeexvDjUiQxAAJ2i0WSWZFzVVUrmqpyS2tk39jExAa1aiwTDsy gv0ORlzJbrQhi9uC4+fpV/QftIASIUWKtZMUZFkjdoPz0AqfPKJvAU7WuiFIDSJnm0NwJIW7XtNC G8DxWgVwUACmZXAqgntzAf6EP7OfiL8X8x9fY1ui2ThjDQilIurAt/klO/rxcv5n7EAwH8DFC+j5 BZ8/sXfvObti1fmimi0WwMQW1xUxlFvPFm0gK7xniwesZgvwmNP3v5lkix1EqkGwG3JGNwhCSKdx eOKGLbbVHy66q/X1GoXzQ7dHpbDLdb9ib35d9+zn7lO/2rH1Hf6iQFGP3y1+qd4sksdvz7urz9lr MXh9xFICPpf/GJAHzBFtwCcaouFZ/AIH8UA59TZDfMG50y9hGiV4GAND6s7oUTRRKWhNVRe/sj6J eswuFxdf3X1ul/v+u6D89E4tJN6dc2Hr/aNLUeReN2AfLd11991+uXkkZnKI2agFURIfj5pQwXb8 gm00DWsorRI19ZSYEVlS0PgQNKK8nmozDXoZ19HvV5tN97Bnm65dbth1t3tY7q7Wdzesu2ZgyU1H z/fL9p+rfs/6jvW3K0aOnx0ZHJhaLDpea5RYc2Dx71KK7bJvb6EazzIF/nibamQNRuuY2z3ldkW5 3UX6AmyAs19tVm0Pnu+7T7s2wguI5Ci2Wb3iHieMRzFOUS2vrnar/f6RpKrDpD6tIA7KQGmUqH5y GdhSBlKcrIOkcFIHb0M2QzWkoFB++2539mG5R6RKnh/xV/93/kYqHzjtwgH0VKebYxof+Bz1faH2 k8spozgIHnbr/nFfzdcoWC1pYnhqscripD7gaFI04efF8jP7sGKfKH3rO9Z22w/DLPWw7m+HBLP7 Xdd3bbcpZRCLdKzeKCoBd2gCdbRd3fWkIjS4x4qh+Xrk0F5+3YpICifs+GH5LwTvft/vVsstW7bt 6r5ny80mkWXq6uXtEuPq4Ko9wY2a5hWaoHx0VjYIqaBXdC9raF7aVhRdwzxP09kmCQRGJanCe94l jEYigsw1NbdfkmXtm1MmN9X190Fuw3g2hpKFI60Ws1+YgZyttU0Lj4WY51BqtQsjJRnISzAwK3O8 ZLzC1+KEktEKGvX4KSU8VmCanQzNThzDk8DwJDA8fTMhv/2dIz4Jt/Q0DW9PCb+0acjA9jfTciop 299O1SWlCsjRqzHx4p9NNYF7ULplYEDVJiiTONLtWCaFGxKCxmn9RIInGQy21UjK6c5CLhdtOA98 uLoVo1mEvUqk61RZh9udj+kp6opsbLhIB4BZXXbiyNWWKuVjQK00maVbCjqeDTcokDLOYnRJwR0F /a1GxxMGEfRSKsci+3EnGUKKH7jwDbifSkIJi5qohEJSnCKXNO5CMiZtLEWzspbg4/qpeROcR+vl PjjvQXM5kbWVx70ybs5ChzMOrbRoy4LBaFsNIgPMnjYVPSgBODE1mGVtNYJWVhYXssJTzraowEtc yaQwmBZTkkO0MfBSpPVwV71+0hoiM04N5ynUgcfYxA95LHi4zAz557iBTUlcJGMuFWlhXVRVmJnN jRksMLUeMBgxk5NiCO9ja1GSy2pQUUrv0LGBtYBpR6R1vxNhgUyoJjS0kRTHuPAS0hErcJTjM+VP lo0Jm4UDGbO2QZCNFsIqDA7CTAirBYYTRSCKwSybELasHDk2KDzl7EBYmm0kZkcRs2aH1i5wXESO oL25eHCAIxZ0UxD4dBYJsguRrZVKIoIa80k9Sx3IiA1Z5jFw0bw0bD3EEUeJbxwdhlfwS9hyVuX6 FkLWXgzbsQ+JxLQi4rulIcEFyuNV8qF5c3S34awv0okqXzfp2LBlLjhE8jzwxUB7agsJHnfZkqob Mc0lktCoIuIuJIQPgxaIwVPDM3VzLIVGb6f5JHO2sGMM5rkgRLzp7oJzshmmLCkyz2VeG3M6rpmQ 8wk8k3qskDwNghPpRBvspbWWhstQE0dgngtEkTqhphpHR/AidZpGjhtDSik10txmZC1jm2l8SZPS ofFiLh4JJF16h3aVxjf0GOVLxkf2c//79jDluCJfWpTGopMU2HJmDuvE4ixHY3GxzxQacEy0w6Ii naoKiUNBCHGU4Yzk+UAc4o16drm55NNo0gpiPmEJh1ZisQCjh+FOZ2k+GmG2nF1ZynU5DFNmYVFk 0RGkZwcVXUHE6vajVhOoP54NKMXjGjoEB0hNaDFu1ExINNECI7m/WDWciRP73zCqjyHcXk5uIgir /zpTtiNMNP5CpWmC04PIoMFYAxQ0hGYYdAWIREhIjE5Xov953od+YcNwXsCMpBM8s/kltO4pEunj 0i0sTNKhjuN9B1lUGHYosKJMOkmEa0A+4I3KE+tJ6Xi7AQnGRiYLUWnaH21HLRg7tX5CNNpLlPy/ cYauMm8u5qz6jwADAOuIotMNCmVuZHN0cmVhbQ1lbmRvYmoNMzIgMCBvYmo8PC9Db250ZW50cyAz MyAwIFIvVHlwZS9QYWdlL1BhcmVudCA5MiAwIFIvUm90YXRlIDkwL01lZGlhQm94WzAgMCA1OTUg ODQyXS9Dcm9wQm94WzI5IDYyIDU2NiA3ODBdL1Jlc291cmNlczw8L0NvbG9yU3BhY2U8PC9DUzIg NTUgMCBSL0NTMCA0NjIgMCBSL0NTMSA1MSAwIFIvQ1MzIDUzIDAgUi9DUzQgNDY1IDAgUj4+L0Zv bnQ8PC9UVDAgNDY4IDAgUi9DMl8wIDQ1IDAgUi9UVDEgNTkgMCBSPj4vWE9iamVjdDw8L0ltMSA0 MyAwIFIvSW0yIDQ4IDAgUi9JbTMgNDkgMCBSL0ltMCA1MCAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4 dC9JbWFnZUMvSW1hZ2VJXS9FeHRHU3RhdGU8PC9HUzAgNDY2IDAgUj4+L1Byb3BlcnRpZXM8PC9N QzAgNDU5IDAgUj4+Pj4vU3RydWN0UGFyZW50cyAxNj4+DWVuZG9iag0zMyAwIG9iajw8L0xlbmd0 aCA5NjIvRmlsdGVyL0ZsYXRlRGVjb2RlPj5zdHJlYW0NCkiJlFZdT+RGEHz3r+jHIxLj+fTYEiI6 llNEdCTc4SgPgCLHa8DHrofYQzbk16fGs94PuCOJ0DLg7amurq7u3fR979vbqvZ0dJSWz48NpRfV XdtVvnUdpScn7i+6EtwwqchyVuBPQyLPmSnIasWs4bqgm/S991V938zpKi3dIy46792S0o/Nraf0 c3t37+nm+PjkdEZJ+vOM0vMZp/jf7JJTPZAgznIhrMXJuSok0VB3iaAWMT8g5m5IhNBUKJaDhiBl mcpJaWaob5Lb5I9EGMGULYqChNSMC8ElHcYwaViehbhfv6MOoZxkxgTnwAkRmSRO4TqKkyEBN5Lq ZZKeLTmduuQTfjhD0PjK19S0hSxjOq5YJnZIKaY2pHId4IWSzFqxzhcY5azI9xkVTModOrhoIzzu ZoYbsaYkJkpAtwiSZAXjKoIrJnUoS+t1fbsp8NCoTI1hOg9JcD9Hknzb3ZhDbssWHG/vH7F+2AIg Qoq11rkMIksG7abigYqaCqhvQU4ynQVKGZSz2Uty4SnKLXQItCM5ztRIDgBw2oaciuQ+nMM/46/0 Ivj3fHZ2imtrm+12LIOhVGQ9+m12Sa/evJz9hBt5Tit48Rw4X/D6ka5uOM0pOSmTtCzBicrbJDiU Z1TWo1cFnq0QSyVczMP5N0kqezzChID9YTxwGfpbKGZy6MENlcvk3cwtlxi1s2F4aoaD8kvyoVzX 9PHEzZ83dYmprlc+DNRm8reJ20grMho5iIKFOYgHXCZx2Yy2yjAuRaRxxHmuj5Edc/ayUDkVynWE VWKsKh57iFgMQMRGCJVdtPVD292Rv2/oWkrxezN4nPJgTPNNEI1hyo02UZ7BPfV1QwtXV971e/ps ey4nbWKXxI4Sh4E4ltdIHBqEnPEIK0CsB1jiUb4hfv3u3q1o7uihw7m6rzzNwT1uxZF9EMMWG3yR /Qu+1mKcYDvid7Ry/cNAwA3a9M3S+Yaabv59lOabMJmGWwuRRZjrgzfsoiZJdvZr8OjbhhEGaU1o MRfj1irstqFvecRutAh2CVDYb8F28dgA7gv9y4Cy8bkxtZfajvxT39FT59sFVZBmeHQdotqBJuHD uG0Iv8yiDDM5fLqfp2/qpv2zmb+hl/6/em2lsgYrJCyz/6xWtlXLfr2ODeZrwSpq5w308c/02DR9 mLDH3nlXuwV5R9ViAdMGX0UzvUDWHJ8yGZf2lUSTCQPIsnqA5n4gt+poaBZNPX4fuO3xmV5tOsG3 E/D1pmssPgx29jLZ1O6h8bst+UeAAQBbKvYxDQplbmRzdHJlYW0NZW5kb2JqDTM0IDAgb2JqPDwv Q29udGVudHMgMzUgMCBSL1R5cGUvUGFnZS9QYXJlbnQgOTIgMCBSL1JvdGF0ZSA5MC9NZWRpYUJv eFswIDAgNTk1IDg0Ml0vQ3JvcEJveFsyOSA2MiA1NjYgNzgwXS9SZXNvdXJjZXM8PC9Db2xvclNw YWNlPDwvQ1MyIDU1IDAgUi9DUzAgNDYyIDAgUi9DUzEgNTEgMCBSL0NTMyA1MyAwIFIvQ1M0IDQ2 NSAwIFI+Pi9Gb250PDwvVFQwIDQ2OCAwIFIvQzJfMCA0NSAwIFI+Pi9YT2JqZWN0PDwvSW0xIDQz IDAgUi9JbTIgNDggMCBSL0ltMyA0OSAwIFIvSW0wIDUwIDAgUj4+L1Byb2NTZXRbL1BERi9UZXh0 L0ltYWdlQy9JbWFnZUldL0V4dEdTdGF0ZTw8L0dTMCA0NjYgMCBSPj4vUHJvcGVydGllczw8L01D MCA0NTkgMCBSPj4+Pi9TdHJ1Y3RQYXJlbnRzIDE3Pj4NZW5kb2JqDTM1IDAgb2JqPDwvTGVuZ3Ro IDc0NC9GaWx0ZXIvRmxhdGVEZWNvZGU+PnN0cmVhbQ0KSImUVF1v00AQfPev2EeK1PN92XcnVZUa t0JFLRRqxEOpUHCcxIXYJXZVyq9n7ux80VJAkXPJeXd2Zm734qNlV03HRUcHB3H+cFtSfDGeVfW4 q5qa4tGo+UFXgidMKjKcOfxMSFjLEkdGK2YSrh1dx0ddNy7m5YSu4ry5RWLTdc2C4rNy2lH8vprN O7o+PBwdZxTFbzOKzzNO/b/sklPRkiDOrBDGYOVcOUnUFnUkqELMK8TM2kgITU4xCxqClGHKktIs oWUZTaPvkUgEU8Y5R0JqxoXgkvb7MJkwm/q4jy+pRignmTLBOXB8RCqJk0+HOOkL8ERSsYji0wWn 4yZ6hw9nCAqPHahpA1tCOa5YKrZIKabWpKz28EJJZowY6nlGljm7y8gxKbfoINH08MhNE56IgZJY UQK6QZAkIxhXPbhiUntZWg/6tktgM1GpCmHa+iLItyhiN6fb15Ab2YLj9e7S60dbAERIMXhtpTdZ Mni3Eg9UaHJw34CcZDr1lFI4Z9LfyfldyHXaB5pAjjMVyAEAnbYmp3pyJ+fon/AVX/j+Pc9Oj5E2 tNn2iaVoKNWzDv2WXdKjl5fZG2RYS/foxXPg3OB5TVfXnCYUjfIoznNwonwa+Q7lKeVF6FWBvXvE Uo4u5n79SZLyJbYwIWC/3y9Ihv8GjiUWfvCE8kX0ImsWC4zaadvele1efhOd5IOms1EzeVjrEitd j/rQU8vk5xW3QKtnFDgIx/wc9Au6TCI5CW2VYlxcT+OAc6sPUR1z9oRQD6ZE0NIvOzi4DoCDe8Dr uaiKr1U9o25e0icpxZey7bDKvQD+RxDN/WXidBpAJkhaXULfmmLcNctnrJEra7buEn8eT5pzHyYd fiS+PixIw5QIZzYinnPDn3ZB++Hg5XDymGVvcb9so0q4btfWnDX1DMJoMe6K+TN61P/oWR/2WpTi cNf4sflnUe6vmjagu5o+tCWVuPqpqqm7W9bbsn4JMAAbEGhYDQplbmRzdHJlYW0NZW5kb2JqDTM2 IDAgb2JqPDwvQ29udGVudHMgMzcgMCBSL1R5cGUvUGFnZS9QYXJlbnQgOTIgMCBSL1JvdGF0ZSA5 MC9NZWRpYUJveFswIDAgNTk1IDg0Ml0vQ3JvcEJveFsyOSA2MiA1NjYgNzgwXS9SZXNvdXJjZXM8 PC9Db2xvclNwYWNlPDwvQ1MyIDU1IDAgUi9DUzAgNDYyIDAgUi9DUzEgNTEgMCBSL0NTMyA1MyAw IFIvQ1M0IDQ2NSAwIFI+Pi9Gb250PDwvVFQwIDQ2OCAwIFIvQzJfMCA0NSAwIFIvVFQxIDU5IDAg Uj4+L1hPYmplY3Q8PC9JbTEgNDMgMCBSL0ltMiA0OCAwIFIvSW0zIDQ5IDAgUi9JbTAgNTAgMCBS Pj4vUHJvY1NldFsvUERGL1RleHQvSW1hZ2VDL0ltYWdlSV0vRXh0R1N0YXRlPDwvR1MwIDQ2NiAw IFI+Pi9Qcm9wZXJ0aWVzPDwvTUMwIDQ1OSAwIFI+Pj4+L1N0cnVjdFBhcmVudHMgMTg+Pg1lbmRv YmoNMzcgMCBvYmo8PC9MZW5ndGggOTIyL0ZpbHRlci9GbGF0ZURlY29kZT4+c3RyZWFtDQpIiaRW W2/bNhh916/4HtsBoXiTRAFBhtop1gz11jUC9pAGgybTttpYzCQabvfrdyjJtzT1VgyBzZj+Luec 75By/Kr19aKsPF1exsWXR0vxu3JZN6WvXUPxZOI+053gCZOKMs5y/JuQMIYlOWVasSzhOqf7+JX3 ZbWyc7qLC/eIROe9W1P81i48xe/r5crT/dXV5HpKUfzrlOLZlNPwaXrLqepIEGdGiCzDyrnKJVFX NZGgGjE/IWbZRUJoyhUzgCFIZUwZUpol1NpoEf0ViUQwleV5TkJqxoXgki6GMJkwk4a433+gBqGc ZMoE56gTIlJJnEI6yMnQgCeSqnUU36w5XbvoN/xxhqD+ZUZoOoMsfTuuWCqOQCmm9qCMDuWFkizL xNgvIDIsN6eIciblERwkZkN55KYJT8QISewgoXqGIEmZYFwNxRWTOtDSeuR33AKbiUpVH6ZNaIJ8 gybmMN2hhzzQFhxfny4Df9gCRYQUo9ZGBpElg3Y78qgKTjnUzwBOMp0GSCmUy9Kn4MIu6OY6BGY9 OM5UDw4F4LQ9ODWAez2Df/q3+F3w72x6c4200WbHE0thKDWg7v02vaWvvryd/oIMY2gLL85Q5yNe P9PdPac5RZMiiosCmKhYRMGhPKWi6r0qsLdFLBVwMQ/r3ySpaLGFEwL0F8OCZOifQbHEQA+eULGO Xkzdeo2jdtN1G9u9LD5Gr4uR09uJm3/Z8xI7Xl/5MECbyj922HpYA6Ieg8hZOAfDApdJJCe9rVIc l3yAccm50VfojnP2lKjeEUV+X1aJntWwnFTExYCKuBECs2vrbeXrZkmN9VvXfqJFWT9sWnvC8jA5 uWM4aC0GCBe9xHLUGCxC62FB6yTFkZX4aPZtP7x447Y0d7ajklau8/SpwYZflZ5q35Gv15YChKMp Pl9Xm952ui/rHW06i5LzerGwrW08dW7TVpYeXFV61/744eWZ8akduaP7Lnjm/ABFAkxJAJTvriuR ZweNz4wt3AYo1MsndxbFpRO8MCzHVU8lfGPL1v9pIdi29qu6gXiWOtt1eCic4aj/H0elgEb+Z4LB uCO/b9AbC55ymzkMsMaTyrdl0z261tNj67yr3ANhxr6tl0vb7oY6GOX56riduIE7TutXq7JZ2jMq Jd+r0l4gLfh3moBnB4348yIdij7xQDg5Mb13Gw856gbv+JkQfhV8S6X9TJ7XS4cnkjC4Jv5NsH8E GABvDfkpDQplbmRzdHJlYW0NZW5kb2JqDTM4IDAgb2JqPDwvQ29udGVudHMgMzkgMCBSL1R5cGUv UGFnZS9QYXJlbnQgOTIgMCBSL1JvdGF0ZSA5MC9NZWRpYUJveFswIDAgNTk1IDg0Ml0vQ3JvcEJv eFsyOSA2MiA1NjYgNzgwXS9SZXNvdXJjZXM8PC9Db2xvclNwYWNlPDwvQ1MyIDU1IDAgUi9DUzAg NDYyIDAgUi9DUzEgNTEgMCBSL0NTMyA1MyAwIFIvQ1M0IDQ2NSAwIFI+Pi9Gb250PDwvVFQwIDQ2 OCAwIFIvQzJfMCA0NSAwIFI+Pi9YT2JqZWN0PDwvSW0xIDQzIDAgUi9JbTIgNDggMCBSL0ltMyA0 OSAwIFIvSW0wIDUwIDAgUj4+L1Byb2NTZXRbL1BERi9UZXh0L0ltYWdlQy9JbWFnZUldL0V4dEdT dGF0ZTw8L0dTMCA0NjYgMCBSPj4vUHJvcGVydGllczw8L01DMCA0NTkgMCBSPj4+Pi9TdHJ1Y3RQ YXJlbnRzIDE5Pj4NZW5kb2JqDTM5IDAgb2JqPDwvTGVuZ3RoIDk3NS9GaWx0ZXIvRmxhdGVEZWNv ZGU+PnN0cmVhbQ0KSImkVl1v4zYQfNev2MdegVD8lCggCHB2DkWKS5vWKvqQBoVOpmNdbdEVmXPT X98lZUtK4hotDoZMWV7OzuwO107fd75ZVbWHy8u0fN4ZSO+qx6atfGNbSGcz+xfcM6oIF5BTUuCt AqY1UQXkUpBcUVnAQ/re+6pemyXcp6Xd4Ubrvd1C+tGsPKQ/N49rDw9XV7PrOSTpj3NIb+cU+k/z BYXaAQNKNGN5jiulouAArm4TBg3GfIcxjy5hTEIhiEYaDEROhAYhiYLOJKvkz4QpRkReFAUwLgll jHK46MO4IjoLcb9+Cy2GUuAZYZQiTojIOFAI21EcDwmo4lBvk/RmS+HaJj/hixIMipc+UJM5liWm o4JkbEJKEDGQ0jLAM8FJnrNDvsBIk0K/ZFQQzid0cGPew+PeTFHFDpTYkRKi5xjEIWeEih5cEC6D LCkP+qYp8KESmYhhUockuF9jEj12t8/BR9mM4tcvl14/2gJBGGeHWmseiswJ1u4oHlFRU4HVz5Ec JzILlDKsXJ69JheeotxChsA8kqNERHIIgE4byIme3Idb9E98S++Cf2/nN9e47WCzaccyNJToWUe/ zRfw5svF/AfcoTXs0Yu3iPMZr+/h/oHCEpJZmaRliZygXCXBoTSDso5eZfhsj7FQootpWP8GDmWH j/CEIPuLfsHNWP8cK6Y01oMqKLfJN3O73eJRu3Huybh35efkQ3nQ9HFml8+DLnbU9caHgdqc/37k Fmn1jCIHVpBwDvoFXcbQtcAyPCpFT+GSUi2vMDOesdciBTuqjLcBVLCoqV8GPBwJiIezIGhaGOfC /LgznWucN21tzijjR2WTURDKeV4bU6hJBQIKi4oq85HAOUVFwLgIt7wHwoMY6tMvRziO5dKDnl+c Adsa2Ni68raDyoFfG/iNc7G2W4OrfBezncRSCrHiWApYA0a7hLgpkMpHVjjiTtLSighV8NfUsLbV zj1tKm8ip11V/2E87Bu/hmrjTRdG+ZeB+jmHia/rg8A5UKg4r/5rL6ayOTupe0R9qXuBIp92UbI7 uK3XjB892NUgOBZ6XWEJhmpnQ9bI4FRWxQkr9Jusvqtat7Odh11nva3tBrZV03q8XlCp6s46N2Rk bDTdadeJMDuV5tnrhOvRdSjsTPfk13VPYlr5/7o3KWN2UtSI+fY4VdCaPeyM6Zr2ET5VDv87hMK1 0CxN6xv/PJZ4aJwaM57um5QFyU70zWzMFlGjF6rNxu5He3gLn5COc7Zu8BAtexuNJ3PildMpNf5I /UvnjnYYJE37948AAwBiJzq3DQplbmRzdHJlYW0NZW5kb2JqDTQwIDAgb2JqPDwvQ29udGVudHMg NDEgMCBSL1R5cGUvUGFnZS9QYXJlbnQgOTMgMCBSL1JvdGF0ZSA5MC9NZWRpYUJveFswIDAgNTk1 IDg0Ml0vQ3JvcEJveFsyOSA2MiA1NjYgNzgwXS9SZXNvdXJjZXM8PC9Db2xvclNwYWNlPDwvQ1My IDU1IDAgUi9DUzAgNDYyIDAgUi9DUzEgNTEgMCBSL0NTMyA1MyAwIFIvQ1M0IDQ2NSAwIFI+Pi9G b250PDwvVFQwIDQ2OCAwIFIvQzJfMCA0NSAwIFI+Pi9YT2JqZWN0PDwvSW0xIDQzIDAgUi9JbTIg NDggMCBSL0ltMyA0OSAwIFIvSW0wIDUwIDAgUj4+L1Byb2NTZXRbL1BERi9UZXh0L0ltYWdlQy9J bWFnZUldL0V4dEdTdGF0ZTw8L0dTMCA0NjYgMCBSPj4vUHJvcGVydGllczw8L01DMCA0NTkgMCBS Pj4+Pi9TdHJ1Y3RQYXJlbnRzIDIwPj4NZW5kb2JqDTQxIDAgb2JqPDwvTGVuZ3RoIDc3Ni9GaWx0 ZXIvRmxhdGVEZWNvZGU+PnN0cmVhbQ0KSImUVNtq20AQfddXzGNbyGovknYFIRAroaTEaVoL8hBC EbZsK429riTXdb++Z3XxLaG0GHnt1cyZc2bPjn9Z1sU0G9d0fu6n21VO/n02K5ZZXdgl+YOB/UWP godMKtKcxfgZkjCGhTHpQDEd8iCmJ/+yrrPxPJ/Qo5/aFRJtXdsF+bf5tCb/azGb1/R0cTG4Ssjz PyfkDxNO7b9kxGlckSDOjBBaY+VcxZKoGi89QQViPiJmVnlCBBQrZkBDkNJMGVIBC6nMvan3wxOh YErHcUxCBowLwSWdtWEyZCZycQ8faIlQTjJignPguIhIEieXDnHSFeChpPHC828WnK6s9wUfzhDU PKajFmi0pSnHFYvEASnF1I6UCRy8UJJpLbp6jpFhsTlmFDMpD+ggUbfwyI1CHoqOkugpAV0jSJIW jKsWXDEZOFlB0Ok7LIHNUEWqCQuMK4J8gyJmf7ptDbmXLTheHy+tftgCIEKKrtdGuiZLht714oEK TTG6r0FOsiBylCJ0Tken5Nwu5MaBC9QNOc5UQw4AcNqOnGrJXQ/hn+bLv3f+HSY3V0jrbHZ4YhEM pVrWjd+SEb16OUrukGEMbeDFIXCe8XyixydOE/IGqeenKThROvWcQ3lI6bjxKhpA6QbBlMLG3K2/ SVJaYgtXBPTP2gXZOACNloUGDXEIC+/dKB+vy6LeUmKXVTHJy+buVe/TZ+867eTdDuxku5Moeomv LOlYJvJbT7Nh2HJr2IiYuSvRLjCcRHLYOCzCzYlbQuecm+AC1XHlTjVLh3h2JFqJRmG7HGFiSgAT 48GpvLM1jTuBGBPFkup5Ds4WI8dO8aeoaGPL73+RLXvZ/cj4D/mnyqOwv1v/qFyInXQevK18j3mk /MGW9XzrRGZU5asM55tTPp1im2pLaMgSI3hLTnkDr0RL/ARfccw0w3V4gl/1/imqap1XfWt/ZmVh 1xWtSruyVfZS0b7CzrqNrDe0KBiWi9hZ9ajW1L682E2xnNF6RdYVKvOsrmhSZpjzh2f3R4ABAGhG dg0NCmVuZHN0cmVhbQ1lbmRvYmoNNDIgMCBvYmo8PC9MZW5ndGggNjI2L0ZpbHRlci9GbGF0ZURl Y29kZT4+c3RyZWFtDQpIiQTBZ1AIAACA0Z/9666rS1MKpZDQVJGGRBpmU0aiQaW000AZoT2VIhJJ 2khbpL2L0pCMQkKJ+LzHo0eUl1NSQlERDx/y4AH373PvHnfucPs22dlkZXH9OunppKaSnExCAvHx xMZy9SpRUVy8SGQk585x5gxhYZw+TVAQ/v74+HDqFCdP4u7O8eO4uHDsGE5OHD7MgQPs34+dHdbW 7N3L7t3s3Im5OTt2sH07W7eyZQsGBmzezKZN6OiwYQOamqipsX49KiooK7NqFYqKLF/O0qUsWYKU FBISiIoiJISAAE+eUFZGYSH5+dy9y61b3LxJRgbXrhEXR0wMV65w4QJnzxIeTmgowcEEBuLnh7c3 np6cOIGbG0eOcOgQtrbs2oWlJdu2YWTExo1oa6OlhYYGqqqsW8eaNaxezcqVrFjBsmXIySEjg6Qk YmKIiCAoSEUFjx9TXExBAbm55ORw4wYpKSQlER3NpUtERBASQkAAXl54eHD0KI6OODhgb4+VFWZm mJpiYoKxMfr66Omhq4u6OmvXoqSEggKLF7NoEcLCVFZSWkpmJmlpJCZy+TLnz+Pri6srzs4cPIiN Dfv2sWcPFhYYGiIvj6ws0tJUV5OXh7g4NTVUVfH0KXV11NdTW0tDA8+f8+wZjY28fMmLFzQ10dJC ayvNzbS10d5OZyddXXR00N1Nby89PfT1MTDAq1e8fk1/P4ODDA3x5g3Dw4yMMDrK2Bhv3zI+zrt3 TEzw/j0fPvDxI58+MTnJ1BSfP/PlC1+/Mj3Nt2/MzPD9Oz9+8PMns7PMzfHrF/Pz/P7Nnz8sLPD3 L//+Af8FGADm5evtCg0KZW5kc3RyZWFtDWVuZG9iag00MyAwIG9iajw8L0xlbmd0aCA0MjEvRmls dGVyL0ZsYXRlRGVjb2RlL1dpZHRoIDQ4Ny9IZWlnaHQgMS9CaXRzUGVyQ29tcG9uZW50IDgvQ29s b3JTcGFjZSA1NSAwIFIvVHlwZS9YT2JqZWN0L1N1YnR5cGUvSW1hZ2U+PnN0cmVhbQ0KSIlEwYNW AwAUANBatYxlLizbXra1bNtYy7aWW+bCslYtLLul7+m102n3srGxAwSCA3ByciGR3ICHh5eXj48f CAgKCgkJC4uIoFCiQExMXEJCUlJKSlpaRkZWVk5OXl4BjVZUVFJSVlZRwWBUVdXU1DU0tbS0dXR1 9fT09Q0MDA2NjE1MTc3MzM0tLCwtraysbWyxWDs7e3sHB0cnZ2cXF1dXN3d3D08vL29vH18/P3// gIDAoKDgEBwuNDQsLDwiMjIqKjomJjYuPj4hITExKTklJTU1LT09IyMzKzs7Jyc3Ny+/oKCwqKi4 uKSktAyPLy8nECoqKquqqqtrauvq6usbGhobm5qaW1paW9va2js6O7u6urt7env7+ojE/v6BgcHB oaHh4ZHR0TESiTQ+PjExOTk1NT09Mzs7B+bnFxYWF5eWyGTy8vLKyurqGqBQ1sHG5ubW1vb2zs7u 7t7ePjg4BFTq0dHx8Qmg0Win4AycgwtAp9MvwRXTNbi5BXdM9+Dh4fHX05/n55dfr3/emBgMxvu/ D5ZP8MXyzfIjwACduO+uCg0KZW5kc3RyZWFtDWVuZG9iag00NCAwIG9iajw8L1dbMTMyWzc0Nl1d L1R5cGUvRm9udC9CYXNlRm9udC9ESE1LTkErV2luZ2RpbmdzLVJlZ3VsYXIvU3VidHlwZS9DSURG b250VHlwZTIvQ0lEU3lzdGVtSW5mbzw8L09yZGVyaW5nKElkZW50aXR5KS9SZWdpc3RyeShBZG9i ZSkvU3VwcGxlbWVudCAwPj4vRm9udERlc2NyaXB0b3IgNDcgMCBSL0RXIDEwMDA+Pg1lbmRvYmoN NDUgMCBvYmo8PC9UeXBlL0ZvbnQvRW5jb2RpbmcvSWRlbnRpdHktSC9CYXNlRm9udC9ESE1LTkEr V2luZ2RpbmdzLVJlZ3VsYXIvU3VidHlwZS9UeXBlMC9EZXNjZW5kYW50Rm9udHNbNDQgMCBSXT4+ DWVuZG9iag00NiAwIG9iajw8L0xlbmd0aCA2NTA4L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGgx IDExMjY4Pj5zdHJlYW0NCkiJ3FcLUFNXGj55Aom8TNCtS/EARXmEcMNLAVFDCHgpEExCpLZVk3Ah 0bzIvYCICkSLoNXSVvFJRW1VFOuj+NjO6tKxI0qF4qsia9WVump9VFt8g+y5UAVt3Z3Zmd3Z2Xvn zL3/f77/P985///nvwEMAMAQUApYYGKiCk9Oyem+jTTHARB6KFRh4ZIjPyxG7+eRTqMvoODnYXV1 AHhFAsCJzbHlmr/uitsFwAgbAOzpuaainNqr8zIACGhD+DkGQpt9bFGOGoAQ5A9EG5BiqIC3DAAf ev4Ng5majScsrkRyFwCsCpNVrxX2CnsBGJUKAOOIWTvbxtJwg5F9PcJDi9ZMHHRO8QUgUIjwK212 wqZoGj0dAL+5SEbrAEbfTT+B4BF6Ihx9Ce5iDsEtrktw+aTyB64MJ2atQ3ABqTqYDIbEDRvCde6f YXI4AJvB5YVwGWyGYwyTwa5VYhmYaJDGe6NPqTcY13crgA6QwApMgAAUGuPpG4Mv+mN7OF7b1nI3 qHyCSOS6MjD1TX2tw30C5mA2ohHEFAoqG04svrbl64NRTWuXVjSPbFZpPsRcn3NlsBGlsk8kI7HX uaxMNk8wTEPYjSpjrgWq7fkkBdMJqtBqnyUZjnnRAL7A7RlABHGLXiwRYcH9E/4DlkYzAVWU1mwz WnKhirAXGPUEVFqtlCQSC+9Hh6QrYCouTcBTcfVbUCqTyTPU8kQRDNQHxYyBL66B+Qx3jRmDRUnC sTEYuqYiMUYSHiH5Vfzf30DZ+sFnzuAAVtlSdO6VzLIycEoM7xjmikLFZd67uXu28Pd7uk7pULXn dx6LCN5z+r7L25G/XK966jKk7a9/nPqnlqv3K3bXNC4KuDEvy4OcOfubPK+eI1n3g7ZnTatm94Tq PLPKvJvzlp/xywo7c1zIWRj95fJtDWkp12/H+e3QrJ7vu85U3piSvHJmw+boM90uoacaYtYyWSip X0oJFuIV67nuPc74k9dLnxSfqeuqL+rmdK+Iz/OvCwm8+L6AqHwqWsT4YOoaXbPnltKu/YeE+09o Vs9y1smPbPysI6qE43fBHsou52yZ6zLsY6HszoNhad85LVvrYcp6yota2Vy5/iLbti54nnbZV9f4 eWu2NuXoEuJXLPcLX+VXufhxtvMb904+RvnbgkY00wsc9FzTIbvl+yQpa2Flc1JFVcBt4Yz/vySu l4zGAvod+/xzGs92yn/lTv8tis/Oh/eb8/HE3OkJJ4EzbqEIu4WgsLKa36T0EhSFRXRKb9featix tCq56nyD5zTjeV6JrooraWntrfgw6Sweu/z6ae6Emh0bZ0+9+ahbL1cc4FuwnzZGbw91uXjXOnq7 6+QZnChFSata0bZflNDOb1t6YFrvvtK2zuqGEj88wcN0atUuhmbT4W/F62O7SrZmbT7rR1x5f/vs dX8+l5xgeDt0Xs9eJoP1OwltnvFk9fRPjV+cKraF6Px9EuHknf5eTRTzEf7z6BHv1JfnRTmH3P/g wqW91deWbHmzkzw6yaVmV8eSDq+PmllXXAI03KvpnyZ/dmJK0umxmnu+LYdHxYUGhLeuvfyXick/ tpuTC640YpvcS1tL2uPm1z5aESwJ8Xp8VHjr+13XM6W2pFDRfMzhshkN91oWk8FkehTlVFsW7Grb xxhqqWlsIPIGM2aihNb+zqm/OkIRmKQ/4MHPM0JmNZsJu96oNUGVNYcq1NoJmJGvMxlJA2EnoUza l5JjsUhJNIY9T0laDI+IiomKmYo5GO/+x0lIkrDEfqP4wsJCcQEyJJGhWG81h6EObCWNlNVeFCbL UNFrWO02MdQVQSWRIxbReS1OVSfSuRwtGY+N6/cTlWjMNVJoQTwRykxakoQRMBSmGfV2K4koDPDQ aE3GbC1ltFpgQbiEj7nQ9lwBM1MlEWCetOAs4E3RkgZUepTVIvHA3PqPwklJZJutlmyJD+ZNa1hC rwH3MsTRau9z+2ye/4p5dMDw5SpyMFwB0jszHQwGaKg6OWpr9t9veB3uNRdLFbxH1uC8VvEfVJvD oy+dNvwtqgcf2l7dTXyrEsJD7GNz7h2zmZffPP7FzmBsTXjW3H11swJyVzdeLvyRc+WnzuoHO/iv bf583ELb5YfWdxTzrO5K+WKvs8T5OMjpjN9gWhnrxg8Q3PL9Bi6LmaNbwDnmP6JbWVNfk1p9dlx6 Vryj+LZLlGavoTFBvjFOsulJ+4onmU2irZsOBylauz6+wxpZfNcrtu7htowFHLPuzhJBxdhznd5u 5FfciV8GHr7R8lFe06GcPRvUft/xc+c+XFRUWZ/D2zb5cY/dt7v83SNdKW43s7T+aW27Y7MvCT6Z dvQ9c+qwnfFOqJA3OTjfYw7Oub7ovC5gMzGA8elXdzabxeTUYmUVtMRgl5Vi80s9iqt/OCHrMaz6 ZexxS9zPfMcG/X+hkBwcZgP6KsR8aSZsBqOXPRwTYvSX38CX3TAW06kUoGgjCI/NxRB57kTMwY4e hOHRpg62P1KPrA0qHW2gKBsZGxb2Lwpjg4N1oMzBalAbjCTUE3bKmGPUaykCGvsKhk42gqSrxk7k EHbCoidEUGvJhkaKhPkkgpGQpOxGPWUq4pH5upmEnoKUVQQpAwEHDuG5X7peMuxaPUU3RNSaKMJM WCgYiJgE8RBNkgZIxBhapEBrNGl1JprJi94GNgC1VCzvVRuNo1nLQ83IDcJBtEKoncjLJ0iKnPgi zmrnIegz4IsxFcHwqJgIFEYt6pDSAgIp0qz5FkqLWGmMRKEIhRDGRGKREbxMlRThbEV2Y66Bopuk JCYm+iV3EEpNJqikEST6ISJRTyayxVAmV6qleDpvilSplKarcbkKJuIqWaoUT5MnQml64qA+nIqn 4agNi3k0Oh1PT46F6klymKmSQ0USesVVfe7wJFwmVcshElVqJS5Tp74FVZkJKXKZGqoVtAlPI1fi 6I9V+iA8rkiHGUqpTI3L5MgOOUiTp6sRbXoJXPUP5qs9LKrjis/MfcECAREQ0egFAqLCuqsgGhWh 7CKY5bkgoEGX5R2Q1QX5RCxdkCCCoCLaSo2giQZfcS1qkJqmYkGMJkoNRnylWvtprVBtVLRq6Ll3 5SGp39e/2u5v796ZM2fOnHPmnJmz6hhYjw+IiQ4OjwJdJP1Kqvst4ENCI1Qhr3RWxkVEKdVqftAq cEJYoCpGIUgZpEpA71BlVGAwdPutDI/ig0Kiw4TpQdAO4CMCQMfAGFVAFB8RExURrlZ6iovEhqhU fFh4tORnStFJKqU4ITA8TK2MjAHlQwJUnjAlLCQ6ZMGrOf3KhoNVUbwiIDRgnlIt5dVKpUSwU7gv BBkKJXCp1ODpQB3kfjZsmS51eCymZeTAsZCSzGfrsoWwSs1ISVabEiEgFzJDuwISSJKyEuaLwZ2X mLUihc9JT4Q4yNbl8toUPkkHQ8mikMQcPjEpaYXelIGpOv1SMWckeabrBjggUgUNQgKkko+nG7z/ kzTvp2fp0nTStIxUWdEh4STh6aJPZQaZgbXQlAbj0qdKzGEMBA/WDE4VhoET1GHsG+WDk2TaAU4i WyCzdxh2HsqgWMFOc/qJE3JEz2YM3sQDZwqflZGolfJZuZALr1eXSPzIHIacdGNoMxkLpx18h9U9 QqW2RbUrP+ZK7vsVbi17+AdZTY0FQQU76lY1L2eD7W1TziVMfBo5a93yw4/sZqy8suEzC8P0jQnB v2xFMyTqL/19+8pHTliK5nn3Bquk+n+0XSx8qdC5bOiorvtzTfedPnSmpUc/tms7lX3sZFLB1JWK WTs+LH9eUurrIb2zZ4avX/OLH4pd5cX0ODiDncB02Yr/wv3xb4pBS9bM5BTCMKi+qEE2esBL5pR8 6MVCQ40x2LOQD7t2ZOMHJ9JyW9omZbJD4beLl4RtPPVVYaX1hWMy1RB2S6GMqrc12KBYlIGyURpK Nr13uhveEeLoVRgt7S9nxDjKzV+mS9MnLkvPH17O0MUYWfjPD7lp2WpYf8NMOkKfpzke9QvFvfMe NWuPzptYOzstu9u2+snzLkOT64Sp9Zna0Tt12trRC1pOfzrRO7jq8Kg9m5Zt6Fjbekh59X1P7dY+ R7/tVN3iD1pzqti/J91/acs0u2hLcxvzblkFV3VqO9PaTt0c94eGF6vuWju2z+mb5FWVh7c88+5Z t2XjJt/MX01x15xfXL2m6MuzHk76wnjnhrJt341qdLt45oDvWb8li15c3H9JU3djfO4fR+WfLdyb Xtz841vc3qbPf1sA1cz10Uv+VDI7dOH90xsiqo9+P89sq1V2XGffdbrsPfeay7627/Z4LjszPc6q suxkVWftlsr87mjtZbvA0/qdxfgCVHTnBveBlRfjL4B0XAiwoqb/+/+uxB59MaL2SmC38/OguJJ1 XwWVbXTrsdMMC9J4mePQGLUY6HAYQnRghJFbi387fOUyuY/PVJ8ZC38SotWpL6U2hvLemVEdbTdv eSweHlRFBueDpZHPzCdve8FNOKT7TvLtLbfK9n+227DPL/019lhESBdl5dbz4xmrh44ay69X2M3Z pCpqDJC1e13qvbBMoqiaOTOlszftWXnhCKnL29c272NmzcsnTV1k+W6zI48efuynbbR/7KZ1abK5 N7+5LcGxZHpQmELj/rx6l39TrbvlDvsnjHCgYW4c3oigSX9Df4MQ5dD/RskUb4kY9KYPXLU88n/A P+hjJ+NPkJyTY6Phjdz/80/HG0fkgCQcR4rIQmj9GmnhtxaeZHi2oRpUQxpNPGgaPEZozUd3mHY0 FelF+jS0Gn4V6CluQKUiZTbSwrgWuFvh7QdjSfDGoowavF58/xyVgOyHpJG0kBZxdC7InS9wmEAa mXagC/LWoM/QDfx74ClAm2HsOOoQZoHkGnQQ9WIPQAX+C+4mEUDFwvogJxO4a0Df36Eu9AO2w364 HJ8AHltSJOpiWs0APK2ADlGKgFCchXVYj9eBzNuEIj4gVUfKSD0xkhYqnvZj2llb1pfLAikYEUSh EWChIC0MqWFlLVo+INWEC5jgSByN0/FWXA86tOJuwCPiReaC1wVsoTS0JX2XyWR2AdrZGO4jMxZk M4hFTohHbsgbrFLCGpGgczL6AK0SUQBYDb4sRnWoHu1Ee9Fh1IxOCmuiq+gG6gXvWAMEu3zxTBwL iAfocSEuAX9UDEEl3o4bcTPodxZ3kvFgtQlZYL1JyzWklhwhZ8k58j25Te6RhxSizKkllJbKoXZT +6jz1Hk6mK6nd9LX6GsMZoyip2xZOzaBrQCs58y5TK6E28R9xB2TSNEosMsT7JoP91QSygdLVqMy VC7u2mHAEXQU0I7uCXYA+l5ZImAmVuAgHAOIxwuxBi/FOXjlgEWf4D24AR8BWzoBl/FVfBP/DfeI 6CUscSCTB+yLIGoSSzLJVrKNbCf7ISIbyQlymdwAG2+Tx2CjBWVL2VPjKCUVBIimFlErqTXUQaqF ukp1w75Z0nNoPzqGTgDb2+jb9F3YScJQjBvjw7wLSGeymUKmgtkBEd3NdLOWolds2ZHsLHYtW8c2 sl3sS86ec+BcAFJOzqm5LC6P28fd5u6YHTAPMM8w10s80T4kQ58Py96jEN2nSAI7BTnhqxANyylr 4OKF3COWXJZ5BmkUtOPU2AN26jrqpczRe3QbiqUWoSxGS1lw91EDzqGL8H4qCB1Au7k8fILSUN3U bsaNnWXyJ6ml9nH5nIa7A5o+ojYz6ZwUBzAVuIHMhYzW40j0BD9Gi2HlXDIJtaF1qAznITNUY3YA W0GutZLxuILZRf2GrqeUTCGeCDs4hmmnPkQ+yB5ZIg/kArHOIDvhwPX3neHrPW2qXDZF6uU5edJE jwnubu+4ujjz48e9PXaM02jHUQ72diNtR9hYv2VlaSExN+NYhoYKF3kqXYM0vNFdY6TdXYODvYS+ ayIQEocQNEYeSEGv8xh5jcjGv87pD5ypwzj9TZz+A5zYhp+NZnt58kpX3vi1wpVvwgsj46BdqXCN 543dYjtUbNPuYscKOs7OMINXOqYreCPW8EpjUN6/2C//mDbOM44/ZxvfYUgwCVAr7tZzb6ApxvzK skDaUINtwFhJCbDV7iJhYxtwSzEyJBHtVHnqomQH6byVtX+toeraJl28nkPXmapTkbpskfrHFCnr fnRSqy77r5m0PzJpi4b3fe89KLAsXaVp0qTd8bnv8z7P8/6+484TaiDqR3uFCptP8SVtnkYq2Cpg VsDSepTpgtDTKeiGqSdwsGAiaQdGpfUr/oAWVPxsCJq5PhBLaANHwwG/0+WKeBo1wRdXRjVSurUq t55CPr0bzerTRL0bOcWmQ/NyoXFVXSjaaTTqrkwoidixsGaORVgf1W6tV/FrvY9fd3gai8LLw2Gt 3FcUaDi8Qv2lbCGY9fsjrLddvvBpPf0upN/1+HWnWQ04UjIrquppWVs6Gt4cdbFrJIJGPY2hwbAL o1YCCzKbxmBYnwEaFRzNGCTzsWnyCSeVAPNEH5G1cqVbmVAfiWKz9qgaDc65Lu3p966UPqT+gKwO hxWX9oBTicT8dxdqSB2cWw565eDWiKexYK/mK13YWWUYlTs2G8mNmG7p6czCqNeXWmAjUoK4RTQ5 LmMkYUUz1bezS7Kd1Hg70nBEBKxoCusXVe0H2UaU1dsVWb1JuBGUGx9v9cQMj7XefpOYyW6XjVsO 8XVbc7u1vXvZnSL6sLUYWade3u9pPKGFlGm7rIWwZDQQRqXIwWYsucvFdnm+6KVRFLTs0TAvyzTq vETeZndEM0VZZHU9UvsVFsmuRzaqRxXczq/jdUhUq0kNG39V9rrdgYmDmlB3h3CSx/H4BOSCpaxe HQg3xNR5Z0NUXYhga3rwKKpqjyL3qFE1VixlRxXZrqiFUEidDkTXp1Qsrc47Ne9CZELAomr7+Gpo u31hs9MU4ZbJaY54iI1DbF0bIKpYICr90vaBPrLNx0cWwjschxVIjE7qL/8iLdpSYJX6xQZaLH+L 8uZX6bJ0kfLivZQvrzIY4VScBguUly5T3vY25cue47BcSxpcRQxfMOL3qF9aQpvfhO3icR1m98IP LMuUt4ZRP8kRv8WxJDgs3/o2fXUd6Q/I64PvXfTxBuJOUAHfl+D7BrSWFq1BWlzvq+yvBlcAxmz9 Gvy1xjj28rGUe9EWxi2iPWkFivmJJ8F3UN4HneJzlU6h/iHoGC3b3HTGgrVjrPeF9ezfRvsWnkDO E9vW4j8MvgHz5gt8zno/2znH+bQ8C8u7vjlHsBuxq7Crbtu2jjC6zXf6X+f+e0ij28C3vcTv39Y7 YbPi/rTyPdf3fWu7v96w3zMwytb9W5FUzkb81lY2/F+nywy2x7rdBd2E+X2Km2spLvVSwltJPT2Y w65qydsnF01fvtTXBnlKF+Eilx9yucDlPJdXuLzI5QUu57gEufRx6eXSzcXLpZPL/Vw6uFi5WLiY uQjeB6G/B++D34H3wDvgDfBj8BrIg4vgPHgFnAPPg++DBfAUiIMRvc3XeNN5Lq9yeZnLS1x+wOV5 Ln4uXVwOcWnnInIp42LiQl4v9LfgV+AK+AX4ObgMfgJeB8vgR2AJfBfMgURfW015TfmBXFE44Q2K uRfE3DNi7qyYS4u5STE3JuaSYu6YmHtYzEXEXFj8gnSvJEufl+6W9kgOqU6qkXZJdmmnVCnZJEmy ShbJJOEe1XabQ6bQULcQ0lbjFBqVtb8MKUXBdvRhrUzpFrRdIQoNdzu0drdmOqN/eRSFUkEQnj7l ZB8dKyQIpVNnnYZGIlTn/ufDsaUUGph7i+4RDpCI675l8Z6ficw7BG9O9+aYN6d7HcKlAWoLxeaj n6PbNPzJIdwxuiUzkGLTHQgXJOqO+I5xXTZV2DCfqNMV6a6zT3fqk7vP5XjS+aaFhPNUgXdvJT7m dgAW8nR5ulgIbywW2sm+84yQ48n7XM43hfNGyA53NZYSvyvxbjNn8b/ejEkq3irxmmC5JrxIZClR Wcm8IvyRqHnthv0GPfAnXFtb9lW7qutd1a6smf6eNdEalV35W3vWcoW9S/O0WHYY7xUz1fyUBBNe qWQWbqGBG/hrbTmAqnnL0qJl6VZUf7c2/P/Uz0P/wyc7KunZje+maSLDNpMDJW5bYJ8xbCvsJcMW qYOKyCRLOUof0p8NWyBZuGrYJtoprPvN1CKUDNtCLaZmw7bCHjFskTKmb/vS03OZ1PjErHxBbu3o aPPgsl8+nIpn0jPpsVnZl85MN8ldk5PyIMuakQeTM8nMiWSiiVdoYRVa5eG56aQ8lJ48PptKT800 ysGp+O1r+fsOh450uR9KTY0nwIxnMDl+fDKW+az+4YmkDGcifXJGnkyPp+XUDH6kzmZiieRjscyj cnps2yTSmRgbWxP5KI3lnqMMpWicJmiWZLoAWrHEHdRGHsPaD99h5MSRmaYZMKbnsvoZtNAEu4sm cco0uNHWjF5KQpPIOoFrQs/8pIeWjR5a4RvGSKaRJdMQ2p2k42gjBWsKLTTCG4QV/0x9+akP4w7R EdRw00PInkJ+wtAZvcY4+pmkGGp9Wrbnv5w/jJmx1eCZCazESX2ek7DGgQw/K8fALPJjyEnSY3rd R+Fju3TnfUvrtdZXuYk/hR8JldRMZ2knniI7rA64P7aMICbocVOWHjzyzm9Gqu6/KTkl/ZF8Kf/M GtPCu+I1orUB2wdiq/6MG0/4PwYAmvYHCwoNCmVuZHN0cmVhbQ1lbmRvYmoNNDcgMCBvYmo8PC9U eXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnRGaWxlMiA0NiAwIFIvRm9udEJCb3hbMCAtMjExIDEzNTkg ODk5XS9Gb250TmFtZS9ESE1LTkErV2luZ2RpbmdzLVJlZ3VsYXIvRmxhZ3MgNC9TdGVtViAwL0Nh cEhlaWdodCAwL0FzY2VudCA4OTgvRGVzY2VudCAtMjEwL0l0YWxpY0FuZ2xlIDAvRm9udEZhbWls eShXaW5nZGluZ3MpL0ZvbnRTdHJldGNoL05vcm1hbC9Gb250V2VpZ2h0IDQwMD4+DWVuZG9iag00 OCAwIG9iajw8L0xlbmd0aCAyNDg4L0ZpbHRlci9GbGF0ZURlY29kZS9XaWR0aCA3MC9IZWlnaHQg OTMvQml0c1BlckNvbXBvbmVudCA4L0NvbG9yU3BhY2UgNTMgMCBSL1R5cGUvWE9iamVjdC9TdWJ0 eXBlL0ltYWdlPj5zdHJlYW0NCkiJdJcHX5bnFcYhgBhwAMYdSNQEnDHuDNO0aaOEIRg14LbOJLax aQtqrHESccWRUYK4ojFNtfgCgoNhJKzIUASUIUSWiIifofcZ93ie9+ULXL/n/J/rus653dyf8fD0 6uXd+1kf3z59+/X38w8Y8NzAQYOHDB02/PnAoBdeHDFy1EsvB4eMHjN23PgJr0x8ddLkKVOnTZ/x 2utvvDnzrd+9/fs/vPPHP707y332M6Ge73mH9Q6P8I2cI2Siouc+9/6gefMXfBATG7Rw0eIlI0ct XRYcsnzM2BV/nvDKyldXTZ6yes3adR9+9PH6v/z1kw1/+/Tv//hnXLzb7I2hm97z3vxZ+BYh86+t /gGfz932/vZ583d8sDM2cNduIZPwxbI9icv3Cpl9+w8cXPXlocNr1h758OjH67/6+pMN33z67b+T 4uLdv/Pw3NRLyPhEJEce658iZjq+7cT2eUN3DN95MmjX7hGnTr/0xfd7Es+c/WH8uX0TDxz88cup h9fMOPL60TdnfvWft3/67zvfnk+a5YZoLoRtftZnS5++QiaK0MxHNAsFGiGDaM6OG38O0Pw4Zerh 6esEmvWE5n+pFx1iJkBzIUwRDkA0g+cvGBYTG8hoXg5OBMKIRhBePc1Ek5aapNEA4T4GmqE7gPAu kElYqtGsBDSrxUxCZqZA89M36RliJgPNFoFGyER/DmiG2NCMPrP3hxWM5tDh6RrNpfSMiw6JxtuO xuqa70NGA+EJjEa7ZkNmVlrGxbhZiMbLQBMVPQDQDAHXCDQvEhokDGgOrrKguZyZjmjcCU2YROMX BWgGgWtibK4RMuSa1co1V65eAjTgmo2EJnxLcp9jSNgVmkRCs//AJEDDrnnr2uVMkHEQYS8mzGiO DzxBaE4GsWsE4TFgPhuabCGTlZYKhHtAI8wXIwmLQCUSmv0TMVDThPk+emN9Ti7MJGSAsAwUoOm3 1S+A0AwlNIsITXDicjCfcs1acE2e+BiNxiNUoAkTMsmcS0QDuUQ0S04nEBowH7sGzHf0ek4uoEkD NG4SDbhG5nIgETbQhID5IJcCjcgloPk5Lyf7ioHGY5NCc4y6ZiAF6vmTCwkNuObMWbOy1r12Iz8v G9CADAUKcynRSNcswK6RgeLKAjSTDwnzHfnl5+s5KJOekQqBAsIGGj9CM0+iWXyK0MjKmoSVNaMA ZeB3a9dsIjToGn+XrsFArdBoCgpvSBkKlLvVNSkaDVXWklMqUIgGXVMkZPLzQAZd45jlrtD4SDTC fNupzamyEszKQjTFRWKmfECTeSlLBorM5xPhy2jmUg0zGnDNsj2jzTYvKS4qFGjEjyLzOZwqKwXM B65ZQGg4lyGqsgSaX4tvqpnYNfGqzSOosnjRoWuozXVlAeFVk0tLtMxVlJGBYtf0VYtusAWNDBQS Lvu1hNEID2Muk1DGEyoLXKMqS6IJdEKz8mC5kLlZVKDNl8ptHurFlRWpKgtdIysrQcyUyK45UFHG M0GgFGG96CJ8tfmwza1ooLIm7Jt4S8kYhONw0Uk0kWS+AQqNvgEkmttCRqLJw5agruHK4kBRLoX5 hpiLTrd55e1b5WUlAk2hkcvzDmpzG5q5us1f4FyCa8auOHen8nZFeamQKSjgQF2lRcdtHmbLJZlP oQkm11TdqbwFMsVFPaPBXG5VbU7mo0WH59HZcdVVOBMSZjRoPmPR6a6Jlm2+MzaIFh0TrmEZi2sy szIsrvFBmRQrGl1ZZ/berakiNCJQRWImhUa5ppc+j/yjuc1NNED4rvgYQOPKNU6LDl0D5uPziBdd yPJ7KKNcU4hoYCmkc6CMG0C6Bs3HbY6BSqy9d7e6+g6hKb4pu+YaLAXreRRhukZV1ghCU1d7r0ai AdeQ+a5p88GGMtEEGGiCJJr6utqe0KTbz6NIPCU0GiBMl2NDfa2WoUDdkGjQfO5GLqlruLJUoE4n LG0QHyMJl8tccqDYfM5onBbdfZSpqalGNGg+2lAyl1zDAg21eX/V5voGGNWIMnKmckLzi4HGIRed t3keHddoFi0eMbKxsaG+vs42ExLORRlcdN9p10RSLvWzBdu8iT5GuKbKUhJ5OBMu7zg4SCzXsFNJ NDU1NsB/uqdnKuF0GzOph4LYUHN0ErAkoD9/Ux+j040zXde/28Gr5YKlJPRMu3Y/MGSq7pglkY9b VxzV55MAjdPWle8N+N3NvzU1mf+JfzckIY+TkMZJ4JLwtfan6JrAhc0PQAb+k5Yx+vMKHtW0vPWt Jq9htbxbmnmmekQDM1mSYOkaTkKy7eSLiW1pblZoaqkkKnR/AuGrmby85UOBkpCCJx+jaW2hmWyu QTTgmpxc471hWy3RA+i9MWx4q5RpsKTbtloATZxCI/vTX6Fpa23RaCgJlZXkmpt66/KGcjfumjmU hG3Yn21tLVqmTvZnhS4JQpPljIZWC6Fpb4OZSKYeS6KazFcqa1ihcciuCbOcfHDXtLe1GWjq2DXw u4UMojGWN5lPBkr154nB7SAjP+Y+u4ZKolS6JpvRqNVyYbN2DR7VD0nGhsbIJa2WK5dxtTj0U8xH vaEEYVKBmbSMGagiDFQOBIqOakE4VPZnX4mmQ8ug+eB3k/lu2Za3DpQ6+TBQcA13sIxOgkZTQa4p NAOFM3kYbyi8hh91PLTL1KlcluuTL1u5Jt54pco31KOOjg45U7MZqGp2jfXkS9Ov1DA4+fgg6Xwk Z2ptxq+5b10tZZxLXN4WNL3UQ8EvqvORkmmxdU0Vdo1o8yJnNPxKlYHqRJl214TNQOVbAsVPsc/C 6Q3ViTIPNRprm8NMJZblna6fYtzmYqbHFhlCA12jzFeuti4FKstc3rzo+j1+3OmExiBcWemE5pJc dChDaB7bZFy6ptTumouOeANNcmSXlFHme+Cyspxd40ZowgANqfCPUrlstLU5X46AJhdn4ldqKKPp 6urqAY0lUKXWQKXDhornU0KgQZUe0GjzlZera1gFyqFc0zv8iV2GZsJANZBrqtTyNk8+hQbeG6DC MyFhnumBvgEsDwV9A8g2RzRPDJkOQwZrmNq8xv6GyjUXHVaWVHFBWKKpNtFYr2F5ZXU/eeISjdk1 NcaiM13Di064prubvqZTyCg0ba0mGtXmgIYDZbkBQr26XXxMO+YSZjLPI3UN4wFqXsMent2uZEw0 DfVOl6PxvESZjaHdzjLt7ebyNi7HCuvz8rJ0zeyN3SQjf7fFwzpQd7WMco1EA4F6iipd6mM6aSm0 80xKhl1TRk8xeR7RDeA2++lTFzOp5jPNZ78B8ADNSkPCT13KuG5z2+Uo31Diyvq/AAMAGUmZXQoN CmVuZHN0cmVhbQ1lbmRvYmoNNDkgMCBvYmo8PC9MZW5ndGggNTEzL0ZpbHRlci9GbGF0ZURlY29k ZS9XaWR0aCAxMDgwMC9IZWlnaHQgMS9CaXRzUGVyQ29tcG9uZW50IDgvQ29sb3JTcGFjZSA0NjUg MCBSL1R5cGUvWE9iamVjdC9TdWJ0eXBlL0ltYWdlPj5zdHJlYW0NCkiJ7MFTc55RGIbR1LaZ1Lad prZt23ab1LZt27Zt84/0sCfP7PuaSfe886VdKyzsj3iW+EICLKGQyJJYSIIlxZIJyS0p3FJiqYTU ljRCWiwdlh7LgGUUMlkyx04WS1YhG5ZdyGHJGTu5LLmFcCxCyGPJ65aPy48VwAoKhSyF3YpwRbFi WHGshFDSUsqtNFcGK+tWzlJeqIBVxCpxld2qWKoK1bDqWA2hpqWWEInVxqKEOpa6bvWw+lwDt4aW RkJjoYmlqVszrjnWwq2lpZXQGmuDtRXaWdoLHbCOQidLZ7cuWFeum1t3Sw+hJ9ZL6G3p49aX6+fW 3zJAGIgNwgYLQyxDhWHYcLcRppFuo7DRwhjLWGEcNh6bIEy0THKbzE3BprpNs0wXZmAzsVlCtCVG mI3NweYK8yzz3RZwC7FF2GJhiWWp2zJsObcCW4mtElZb1rit5dZh67EN2EZsk7DZskXYim3DtmM7 sJ3YLm43tgfbi+3D9mMHuIPYIewwdgQ7ih3jjmMnsJPYKew0dwY7i53z4Dx2gbuIXcIue3AFu8pd w657cAO7id3y4TZ2x4O72D3uvgcPPHjIPfLgMfbEg6c+PPPguQcvfHjpwSsPXvvwxoO3PrwL1Ptg fQjUx2B9CtTnYH0JEV9Dxbe453vc8+Nf9vO/v+tXiPstwAAIMWYkCg0KZW5kc3RyZWFtDWVuZG9i ag01MCAwIG9iajw8L0xlbmd0aCA0MDIvRmlsdGVyL0ZsYXRlRGVjb2RlL1dpZHRoIDQzNS9IZWln aHQgMS9CaXRzUGVyQ29tcG9uZW50IDgvQ29sb3JTcGFjZSA1MSAwIFIvVHlwZS9YT2JqZWN0L1N1 YnR5cGUvSW1hZ2U+PnN0cmVhbQ0KSIliYGRiZmFlY+fg5OLm4eHl4xcQFBIWEREVE5eQlJKWlpGR kZWTV1BUUlJWUVVTU9fQ1NTS1tHV1dPXNzAwNDIyNjYxNTUzt7C0tLK2sbW1s3dwcHRydnFxdXNz d/fw9PTy9vH19fMPCAwMCg4JDQ0Lj4iIjIqOiYmNi09ISExKSk5OSU1LT8/IzMrOzsnNzcsvKCgs Ki4pKS0rr6iorKquqamtq6uvb2hsbGpuaW1ta+/o6Ozq6u7p7evr758wcdLkyVOmTp02bfqMmbNm zZ4zZ+7cefMXLFy4aNHiJUuWLl22fPmKlatWr16zZu26devXb9i4cdOmzZu3bN26bdv2HUCwc9eu 3bv37N27b9/+A0Bw8OChw4ePHDly9OixY8dPnDh58tTp02fOnD137vz58xcuXASCS5cuXb585cqV q1evXb9+48aNm0Bw6/btO3fu3AWCe/fuPwCChyDw6NGjxyDw5MmTp0+fgcBzEHgBAi8h4BUEvH79 +g0IvIWDdzDw/gMS+AgHAAEGAPuW/aEKDQplbmRzdHJlYW0NZW5kb2JqDTUxIDAgb2JqWy9JbmRl eGVkIDQ2MiAwIFIgMjU1IDUyIDAgUl0NZW5kb2JqDTUyIDAgb2JqPDwvTGVuZ3RoIDU4Ni9GaWx0 ZXIvRmxhdGVEZWNvZGU+PnN0cmVhbQ0KSImMwlVvk2EAgNFdwQ0hhABBghM0uDsBgrsT3N0luLtL cHd3d3d5P6vL2q5d13btunVbZ+1DfwInB1EckYQohiiBKIkohSiNKIMoiyiHKI+ogKiIqISojKiC qIqohlQdqQZSTaRaSLWR6iDVRaqHVB+pAVJDpEZIjZGaIDVFbobcHLkFckvkVsitkdsgt0Vuh9we uQNyR+ROKJ1RuqB0RemG0h2lB0pPlF6ovVH7oPZF7YfaH3UA6kDUQaiDUYegDUUbhjYcbQTaSLRR aKPRjUE3Ft04dOPRTUA3Ed0k9JPRT0E/Ff009NPRz0A/E8MsDLMxzMEwF8M8DPMxLMC4EOMijIsx LsG4FNMyTMsxrcC0EvMqzKsxr8G8FvM6zOuxbMCyEcsmLJuxbMG6Fes2rNux7sC2E9subLux7cG2 F/s+7PuxH8B+EPshkg+TfITkoziO4TiO4wSOkzhP4TyN8wzOszjP4TqP6wKui7gukXKZlCukXMV9 Dfd13Ddw38R9C89tPHfw3MVzj9T7pD4g9SHeR3gf432C9ylpz0h7TtoLfC/xvcL3Gt8b/G/xv8P/ Hv8HAh8JfCLwmfQvpH8l/RvB7wR/EPxJ8Beh34T+EPpLhiBDIkMmrBBWCWuEdWTqyTSQZSTLRJaZ iIWIlYiNiJ3sxGSyHWQ7yUl0kZNCjptcD7mpRL1E04j6iPrJSwyQl05ekPzEEPkZ5IcpSMykIIvC CIXZFOZQlJhLUZSiPGL5xAqIFRJPLCIeIx6HRJL+2z8BBgDy8knjCg0KZW5kc3RyZWFtDWVuZG9i ag01MyAwIG9ialsvSW5kZXhlZCA0NjIgMCBSIDIzOCA0MiAwIFJdDWVuZG9iag01NCAwIG9iajw8 L0xlbmd0aCA2NDYvRmlsdGVyL0ZsYXRlRGVjb2RlPj5zdHJlYW0NCkiJxMKFVlMBAABQ/4kSkJBU GglBaaRLRUFKUEQ6FKS7GwxCKUHp1+vu7t7YQN/xJ7znOjkBzs6Aiwvg6gq4uQG3bwPu7oCHB+jp Cd65A3p5gd7eoI8P6OsL3r0L+vmB/v5gQAAYGAgFBUHBwdC9e9D9+1BICBQaCoWFQeHhcEQEHBkJ R0XB0dHwgwdwTAwcGwvHxSHx8cjDh0hCApKYiDx6hDx+jEeTktDkZDQlBU1NRdPS0PR0NCMDy8zE njzBsrKw7GwsJwfLzSXk5RHy8wkFBYTCQkJREaG4mFhSQnz6lPjsGfH5c2JpKenFC9LLl6SyMlJ5 OenVK3JFBbmyklxVRa6uJtfUUF6/ptTWUurqKG/eUN6+pdbXU9+9ozY0UN+/pzY20pqaaM3NtJYW emsrva2N3t5O7+igd3YyuroYHz4wPn5kdHcze3qYnz4xe3uZfX2s/n7WwABrcJA1NMQeHmaPjLBH R9ljY5zxcc7EBGdykjM1xZ2e5s7McGdneXNzvPl53sICb3GRv7TEX17mr6wIVlcFa2uC9XXh58/C L1+EX78Kv30TbWyINjdFW1vi7W3x9+/iHz/EOzuS3V3J3p5kf196cCD9+VN6eCg7OpL9+iX7/Vt+ fCw/OZGfnsrPzhTn54qLC7zy8lIJAEoQVEGQCoZVCKJGUTWGqQkENZGoIZE0ZLKWQtFSqVoaTUen 6xgMHZOpZ7H0bLaewzFwuQYeD2/k840CgVEoxJtEIpNYbJJIzFKpWSbDW+Ryi0JhUSqtKpVVrbZq NDat1qbT2fT6K4MBbzca7SaT3WzGOywWh9XqsNnw11dX13Y7/sbhuLm+vvnnD+7W//NXgAEA3ObD UQoNCmVuZHN0cmVhbQ1lbmRvYmoNNTUgMCBvYmpbL0luZGV4ZWQgNDYyIDAgUiAyNTUgNTQgMCBS XQ1lbmRvYmoNNTYgMCBvYmo8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnRCQm94Wy02OTggLTIw NyAxNjI1IDEwNjVdL0ZvbnROYW1lL1RhaG9tYS1Cb2xkL0ZsYWdzIDMyL1N0ZW1WIDE3MC9DYXBI ZWlnaHQgNzM0L1hIZWlnaHQgNTQ2L0FzY2VudCAxMDAwL0Rlc2NlbnQgLTIwNi9JdGFsaWNBbmds ZSAwL0ZvbnRGYW1pbHkoVGFob21hKS9Gb250U3RyZXRjaC9Ob3JtYWwvRm9udFdlaWdodCA3MDA+ Pg1lbmRvYmoNNTcgMCBvYmo8PC9UeXBlL0ZvbnQvRW5jb2RpbmcvV2luQW5zaUVuY29kaW5nL0Jh c2VGb250L1RhaG9tYS9GaXJzdENoYXIgNTgvTGFzdENoYXIgMTA1L1N1YnR5cGUvVHJ1ZVR5cGUv Rm9udERlc2NyaXB0b3IgNSAwIFIvV2lkdGhzWzM1NCAwIDAgMCAwIDAgMCA2MDAgNTg5IDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgNTUxIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgNTUzIDAgMCAwIDAgMjI5XT4+DWVuZG9iag01OCAwIG9iajw8L1R5cGUvRm9udC9FbmNv ZGluZy9XaW5BbnNpRW5jb2RpbmcvQmFzZUZvbnQvVGFob21hLUJvbGQvRmlyc3RDaGFyIDMyL0xh c3RDaGFyIDEyMC9TdWJ0eXBlL1RydWVUeXBlL0ZvbnREZXNjcmlwdG9yIDU2IDAgUi9XaWR0aHNb MjkzIDAgMCAwIDAgMCAwIDAgNDU0IDQ1NCAwIDAgMCA0MzEgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCA2ODUgNjg2IDAgMCA2MTUgMCAwIDc2NCA0ODMgMCAwIDU3MiA4OTMg MCAwIDY1NyAwIDcyNiA2MzMgNjEyIDczOSAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgNTk5IDAgNTI3 IDAgNTk0IDAgMCAwIDMwMiAwIDAgMzAyIDk1NCA2NDAgNjE3IDYyOSAwIDQzNCA1MTUgNDE2IDY0 MCAwIDAgNjA0XT4+DWVuZG9iag01OSAwIG9iajw8L1R5cGUvRm9udC9FbmNvZGluZy9XaW5BbnNp RW5jb2RpbmcvQmFzZUZvbnQvREhOR0RJK0hhcm1vbnlEaXNwbGF5LUl0YWxpYy9GaXJzdENoYXIg MzIvTGFzdENoYXIgMTE5L1N1YnR5cGUvVHJ1ZVR5cGUvRm9udERlc2NyaXB0b3IgNjAgMCBSL1dp ZHRoc1sxOTAgMCAwIDAgMCAwIDAgMCAyNDUgMjQ1IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDM2OCAwIDAgMCAwIDAgMCAwIDAgNTc5IDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDQ3MSAwIDM3NiA0NzAgNDI5IDI2MyAwIDQ4 NyAyMDUgMCAzOTYgMjQwIDcyNSA0ODggNDY5IDAgMCAyOTIgMzYwIDI5MSA0NzIgMCA2MzhdPj4N ZW5kb2JqDTYwIDAgb2JqPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250RmlsZTIgNjEgMCBSL0Zv bnRCQm94Wy0xMzQgLTI0MSA4NzAgODM4XS9Gb250TmFtZS9ESE5HREkrSGFybW9ueURpc3BsYXkt SXRhbGljL0ZsYWdzIDk2L1N0ZW1WIDY0LjkwNTAwNi9DYXBIZWlnaHQgNjI1L1hIZWlnaHQgMC9B c2NlbnQgODM3L0Rlc2NlbnQgLTI0MC9JdGFsaWNBbmdsZSAtMTUvRm9udEZhbWlseShIYXJtb255 IERpc3BsYXkpL0ZvbnRTdHJldGNoL05vcm1hbC9Gb250V2VpZ2h0IDQwMD4+DWVuZG9iag02MSAw IG9iajw8L0xlbmd0aCA0Mjk4L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGgxIDc0MjA+PnN0cmVh bQ0KSInsl11wE9cVx8+9q4/FNkY2BkyF4xWLDdR2XbDBfBgsJK0QVgj+gq4cT0eyZSMoBCUQPkIz kAkkQSTAhCnT+iFNmLSlnTa9orSjMJmUpMk004SmPLR9aNNAmkwyGeiQNJCUUm//dyV5DE37kteu 9dO995xzzz3nnqvdNTEimkz7SaGudb3NC59898ZiSP4MNgxtTaT//sGuXxLNSBGxA0M7d2hkX6wV tI+kN24t37flR0Q8TeTct3HLnpFvnKn4IRyeI3L/NjWcSL6xfm8v0axXMGlxCoKyUee3obuK8ZzU 1h27q15tvkGkVhEpp7ZsG0oEPauOE007Bv9/2JrYneZ3u7D2rGdhr92T2Dp8/+ubMJ5ZBvtvpbdt 32F9IuOpviz16fuG07kXn3mfqPQFxOQgxj9ix8iJ2EadC+CxLt8qT9MFxwqV81JHPh2kT3NpwrU5 vWMHMdKucufSsUoi1xl2RaZN/7++4OVf3tPdte6utXdGO9dEVoeNUDCwyt+xckX78mVLl7QtXtT8 labGefV1c/TZtdVVFZ4pk0tLJqlul9OhcEaNhh6Oa6I+Lhz1eiTSJMd6AoLEBEFcaBCFb7URWtw2 02619MNy5DZLf97SP27JPFo7tTc1aoauifMhXcux/m4T/SdCekwTV+z+WrvvqLcHkzHw+TBDM6pT IU2wuGaI8M5UxoiH4C9bWhLUg8MlTY2ULSlFtxQ9MU9PZ9m8lczu8HnGsiwndbJcVih1RiIpurpN I+T1+WK2jIK2L+EKCrftS9skY6bDWrbxXObxnIcG4w1lST2ZGDCFksCkjGJkMo+KigYxXw+J+Q+8 W42Uh0WjHjJEgw5n0Z7xBZhw1nl0LXONELx+5fKtkkRB4qrzXCPZlSmObxP0xT4hNkSI/Hw+Gcvh nJ8GMRD7u838WKNB72nyNzfEBI9LzbmiZtp6qdlf1IxPj+s+WSojXvjsTFWL/YNaUyN23/7U4QO9 JpT6+OBQSraJ4YweCuX3rc8U/hA6/kQhVyP71WbYJ+JIYpPchm5TNOtpUaUH8gYQaLIGm3pNe0ph mqgKCooPFWaJZiMk49KMTDyUD1D60rvN56nFupht1bw/a6FWisk4xPQgilJvZMzkiKiNe5M4nyOa 6fUJfwzbF9PN4Zisku4R8y9iOZ+9oj0Lud1mXTSWmbvrVM3kXiUmqwWBFsaXHmiHwoNy2UNZ0UC7 ZjIvFc2wSsFC9m7xg4FSF4xIlSKnBiNeX8yXv/5HSN5CTM46oU7w5YFgPKb8Ov81tLy1DGi+ZgyH JgR4i1NnIcCCt8+Pk8u9KCyMGaosZ6SoUurwy4WMw40tklWs1gR1aaY+rMd0nCF/lylzk3tt1zfa q0e7+0272oVT0nfLKK9fMq4r9Ip/WkbVo70ZaaMXVKRl1gjC4fPjZ7aksjUvDeM+lcmEdS2ciWcS OWv/oK559EzW78+kjbgM0sSG56yzh70i/HhMeOIptkz619ckM3qv2e61A+gxH/Q+EGuyn2GuM2NT 8Qy+a+yKdafr+n881T7EUzEpO+xggQu0gF2ng8pyWqqcpLDjr9Tn0GkRc9FByFV23VrNX6JHoVvO jlsv8xU0lx2nKl5GKmRx8DBoA1WgA0g/94ILICRl0l7OlT6K8I+pydVHPcpV6wcOThHlORpw7EN7 FAxQxLEZ45MUYW9ThJ+3XlN+D3kTRZwvQfc6OEMDyo/zLXKKKMeJK7+glONZSioXKOU8Rf3KWesZ ZR+lFGF9ijxeQ8wlaB/B+inlhPU9PkI55VXMPU0rFBnDr8A2rOdFXGeoRHkPsT8rGbuiNKC9THHn eeT4PkAc8H9NOQ/7DdTBL5GH91Gf8msahG2X00tdSpv1G+VF6x2lxPoX1v0dvWU9ifbnWL+TH6bt aI+CgKJaHypdNKqMIZ9d1IO4DgGf8znrJ8hP7ukM/hZtkziP0nzsRRP2z4Ha1SgnrS8rSXoIxB1n aZHzjzTgvITYsMeubXhT+hM9BfawUXoK7FFS1k95Gz0E4ohhPmqTtOt6yXrZfRf1Id8w1q4FBDr5 C7QH7XtgK79JJ/mI9Q76+2R8snY2qJ2sW7Eudg3kvn4ePL/HE8Gag3Jd4AULxvf3duTeToA/TSOO Tnra2YJ130Y8E86Xcsn61D6zOOPFOO0zcwI6WRN5LqRcnrdiezR/3iZi5yPnnSSzmFsRe52r1ONw gYdRi/wZdeCczJTnUZ4Je50XrQ+UHOr8Js4LzqI8D/idbZDwDrvtwdmRdNLHsDtJ2/2f7AqotTvB /UG1dgfYDu4D90KWBtvAPWAz2ARS0G0EI2AYJCEbAoMgAfpBDJjQfQ1sAOtBH2S9oAd0g7XgThCF rhOsARGwGrIwMEAIBFeptQGglxuzywxfiaGpRq3LuMNh1HBjFhlfUqvV6WqVWql61HK1TC1RVdWl OlSu4q5CjNEkhpcgmjcPd6PKCpX726Z05Bhlp7Nozm31RIXadbeZZexITFRGKdoXeB6TrINPBFhN VNT0miJeE4uK/ehQTXY6BWINeKkKnJ5RwR7TxOzujL5b+Ht2Z0u0x/C+tH53lrOAUGb5fAzPej04 0B9g0S4zq2JicCDfTvekV+ItRBNzjCHB8ZKB9wlfzkWxQVEZNL05TvGcgwb1YkeUNugxUYqnToke oI6O6gZPO2t2lQkXRG490PAFL+LyXq0ccKr4D86Ne3WFr2IGUA7cvJjkplO98ZlTTf7znMOP+7w6 dowPOGvIQ9TmmVrZNqOcuV18WlXlDHe9OnrkHy0bT3UY4eFk5ObfWD+bxSaJrsgrDx4a+8t3z459 dHf4Tbi3Vo8dY6N5H6yKu7l77krWVlnRyue2TWeja6PHPmvZ+P3AIemEi1NjbxwZuyG9fJOVs/az zGN74dRkfchzjr34z3MOYlk4raqc67MXta7krMpdzqYwfaq2qFWf7XLPXdyy8A5+Yp2npn5aF774 kr1LT3x9af9M9p23V6Zb/s1+9ce0cV/x7/fOd4bgOAHbGDcQn+3UTjCYwAX/CB2EQYAA4YcBhyQO 4cCGuPGvGkNCMgqkqmiSpSSL1LWZFC2UolTKqLR2LNO6SVm1ZZFW7Z91UTRFVZNt1ZDadJs2pSsc e9/zOQttlq37Y9ofu698977vvvfe5733ed87M9EXvBPdjjlvri0/uz13c342tfDagcIS5qfYeP+7 eYZh15bmpyHyBoQUMchRFqDmaYvGBD+eNtF3v37zxcHlnwfO3DrdQ7lItij/8iyTsSyhbIA9d4ye RXpkRUizzeU0lelpNdZp9Rar02VhLWYH5dLyZZWUS+PAFrOSbTg/g9GzJ1q0Onacwawica0yWG+d ntse9D6VY9ftKPpRohcXiwvvGMWSY294ip80dzt/VtR5tO/O9vhrYazIYOemyTsaPFP3wfMT4Hc9 X0YqRZyVAwa+LBfKRZzdvLt3QFF4qNr7nL/0zNn3nfstht1tlwYC+HnxdvGIPm9b4MV9n8zOrVUn 8o4fScdzg/EgNdoCdlcBh6ywq+ICV5WY+LqZBl9T/INEL3V46sKWh2M73/7uhKXaiGsfioCuWjr+ caIkHVyTuCD0sRlpBFUQlwrZAEEuROZM1ZlVUiYIE1xbbQ6ccs7pCBks5o9rvjrTUTvJ99h7nXlY FTjNnHm2+4WtWx3TDW9GMBqpvjw4QGlVlSXNUfOm3ffFH7uPePjy0infny53dd2c2LPVARn1gvvr TCPSIsRbNBYX78pJZ3Id5pWWuyenpnPObnT8eXOj2eTZcWxDwQ3NDdoUn8dZa9XD+oszcVKXKui1 YchgPkzMakop0YiXOKrTsmRaCeCpuu39rc61LafuTPUpWn+9XdhpZZU9J/0sS9uL94y1izbGs/zO ZfOOAxX5OyzL71Emi0d7geQH7ON5Rgt9kQ3SQ32hAdPY780usOnIyfDNUxcYbbvetjEbqL8xWxxb itHnJIQrn9KNgBCY82SZ0yUlEDJqs9okrJjHuUacS31bnb9OoSk0jFQyNnNRdf2p305N4edmxRr3 pkr70ywTyVAGs/r3J9eJPsazdAePiAeeCF7ZSzz0rizCn0EPykGIYQk6pwsMk7bgwSEernZepJlr U28ztCe70IB1X9MW5SmOf3bBYFrDExZIWWT8wIISmDgJo6HQcuos5iyclpRyQm18rjKVYz1dbt3V EVpS9ZwSGPrkB27vyV64DjS2bmg7tV+7lpnMzFREFrbudm6EN6uXr/ybpw7S+xWDPedl8W3RkJJ8 3bOijTIkfthU0XOlgG+wpyt7BDBtRMi0GorknvSCXGMVFFI596mzRfI4Dh6drwxWCHVWwmFSSHH+ gXmfTy6yzP0YeMhCBeBwPYlPR3rb6dIq2X90NyB///ZEl+/2uM93dnLyeuukv2xy4nrrCX8ZlYFt x0cXxFujx35x79VLroFze+/NzLgHzqbwU+fhK1VPcppm9kMhsEoeu8LXsvJUmzJUqvWfVDSlEsbg DAX1hxsUNU2Js2KFhNvcwYPF9bAHTQNeC+zQ0Knl2yQapUDqlWTb0GmBSjoJvc3Fx+K/9Nt9dn9L 18WDiTyn33bVf8XfcfDK+Jhlmr/gdem36uuTsSavMapWP9/q7qsbTbZ18wnw1Ame6hQvSV2ltJCN iH9AXavEL+hX4BhVp7nRsTaidxYorHXG/Z4qhtkHTWufstPn4mJGfaF/TdYza1SFxXv1TiO1IY4Z 8TNS2z7I/Di0hw72nDRTN8COR5lk+9enuhlm/r2SfVP+HeLsWFs3y9DnlheN27RXsYHKX74pnqhu ntaXG4m1tpVFpod+GRlgogfqYxI+raSlC69xaUh+6N6CZ353Wuw0lbszhb7fGD3b1OdPh6LvWkor svH0vXsUtXRxZz11+QOxtKqGDiyvu48XGvdL/790jxwutO9LjG98YXznS49FtIh12IfP4wUYvyfv espN7aVepX5Fp44iWqDP0VdhfPj/8bgh1ZUC7pBDC19qIGHYoTGL/uVBy9cs1SNvm9OC/Z8ZqEV1 9Q27UFMzamlta4f3YJdvTzdw5H/lUKBDcM6FL0oasYiDb5Mq+F4T0AAKoRgaRkdWVuA+hzbL+n5Y fxgliH7l7heHnOVHHZDKlT8+FosKvfTgeQEhWaZhZxJkWQHymCyzIL8iy0rkRt8jlVVkwuwn6CNZ xqgQvyHLFFLjW7JMIzf+UJYVyE0ZZZkFeY8sK1Gcmn6dawwmgpFRrlOIHhYSAa7U4/E4uNrgUGgw GgxwO4/2h4eHQiPB8Cg3EEtwncHwUDIhcDWxRDyWEJKhWJRrDkVCyWDAwVWHw5w3NHgoOcR5g0PB xAgoaxta6mt32RuERCQWHa0NDcXDwmjxrqQQDvX/p/dkJSdruZSWCw1xAgfgAsGIkDjMxQY+F5sD vQ6FbkRBKG8QRdAozDoh9VEouAC6AMxLkUcaDpBrYdUQ0GQQVgSluzvRUSBIGGhD9COgDUtWBoBK Ccka0QyhJMwEmNdI+rh0FkBLKBcFfTNIEfglJbvEVzU8F4arV/J3CO4MSTOCgOAdkVfWAklbUD1c d0FPNki4I5LVUdCFYHUc7AgwI88OAtKwtObff64YViRBCoO2/7/+3OqV3OfWcqvWctI9Tsp0KuMB qa7EwmHQxaAuj6+3A8lduIg6oB8C0B8U7BQlMENIZMalXRWn1swvXfrWwXVP/QVlZkgt+eZ2821y fcug/r74kahh/8q+JXUzlWrwvw8AdiHjkQoNCmVuZHN0cmVhbQ1lbmRvYmoNNjIgMCBvYmo8PC9D b3VudCAyMS9GaXJzdCA2MyAwIFIvTGFzdCA2NCAwIFI+Pg1lbmRvYmoNNjMgMCBvYmo8PC9QYXJl bnQgNjIgMCBSL0Rlc3RbNDYwIDAgUi9GaXRdL05leHQgODMgMCBSL1RpdGxlKP7/AEEAcABwAHIA bwBhAGMAaABlAHMAIAB0AG8AIABNAHUAbAB0AGkANik+Pg1lbmRvYmoNNjQgMCBvYmo8PC9QYXJl bnQgNjIgMCBSL0Rlc3RbNDAgMCBSL0ZpdF0vUHJldiA2NSAwIFIvVGl0bGUo/v8AUwBlAGMAdQBy AGkAdAB5ACAAQwBvAG4AcwBpAGQAZQByAGEAdABpAG8AbgBzKT4+DWVuZG9iag02NSAwIG9iajw8 L1BhcmVudCA2MiAwIFIvRGVzdFszOCAwIFIvRml0XS9OZXh0IDY0IDAgUi9QcmV2IDY2IDAgUi9U aXRsZSj+/wBDAG8AbQBtAG8AbgAgAEkAcwBzAHUAZQBzKT4+DWVuZG9iag02NiAwIG9iajw8L1Bh cmVudCA2MiAwIFIvRGVzdFszNiAwIFIvRml0XS9OZXh0IDY1IDAgUi9QcmV2IDY3IDAgUi9UaXRs ZSj+/wBDAG8AbQBtAG8AbgAgAEkAcwBzAHUAZQBzKT4+DWVuZG9iag02NyAwIG9iajw8L1BhcmVu dCA2MiAwIFIvRGVzdFszNCAwIFIvRml0XS9OZXh0IDY2IDAgUi9QcmV2IDY4IDAgUi9UaXRsZSj+ /wBDAG8AbQBtAG8AbgAgAEkAcwBzAHUAZQBzKT4+DWVuZG9iag02OCAwIG9iajw8L1BhcmVudCA2 MiAwIFIvRGVzdFszMiAwIFIvRml0XS9OZXh0IDY3IDAgUi9QcmV2IDY5IDAgUi9UaXRsZSj+/wBD AG8AbQBtAG8AbgAgAEkAcwBzAHUAZQBzKT4+DWVuZG9iag02OSAwIG9iajw8L1BhcmVudCA2MiAw IFIvRGVzdFszMCAwIFIvRml0XS9OZXh0IDY4IDAgUi9QcmV2IDcwIDAgUi9UaXRsZSj+/wBNAG8A ZABpAGYAaQBlAGQAIABIAG8AcwB0ACAALwAgAFMAaQB0AGUAIABFAHgAaQB0ACAAUgBvAHUAdABl AHIAIABpAG4AdABlAHIAYQBjAHQAaQBvAG4pPj4NZW5kb2JqDTcwIDAgb2JqPDwvUGFyZW50IDYy IDAgUi9EZXN0WzI4IDAgUi9GaXRdL05leHQgNjkgMCBSL1ByZXYgNzEgMCBSL1RpdGxlKP7/AFAA cgBvAHAAbwBzAGEAbAAgAGYAbwByACAAYQAgAE0AbwBkAGkAZgBpAGUAZAAgAEkAUAAgAEwAYQB5 AGUAcik+Pg1lbmRvYmoNNzEgMCBvYmo8PC9QYXJlbnQgNjIgMCBSL0Rlc3RbMjYgMCBSL0ZpdF0v TmV4dCA3MCAwIFIvUHJldiA3MiAwIFIvVGl0bGUo/v8AUAByAG8AcABvAHMAYQBsACAAZgBvAHIA IABhACAATQBvAGQAaQBmAGkAZQBkACAAIABUAHIAYQBuAHMAcABvAHIAdAAgAFAAcgBvAHQAbwBj AG8AbCk+Pg1lbmRvYmoNNzIgMCBvYmo8PC9QYXJlbnQgNjIgMCBSL0Rlc3RbMjQgMCBSL0ZpdF0v TmV4dCA3MSAwIFIvUHJldiA3MyAwIFIvVGl0bGUo/v8AUAByAG8AcABvAHMAYQBsAHMAIABmAG8A cgAgAGEAIABuAGUAdwAgAFAAcgBvAHQAbwBjAG8AbAAgAEUAbABlAG0AZQBuAHQpPj4NZW5kb2Jq DTczIDAgb2JqPDwvUGFyZW50IDYyIDAgUi9EZXN0WzIyIDAgUi9GaXRdL05leHQgNzIgMCBSL1By ZXYgNzQgMCBSL1RpdGxlKP7/AFAAcgBvAHAAbwBzAGEAbABzACAAZgBvAHIAIABhACAAbgBlAHcA IABQAHIAbwB0AG8AYwBvAGwAIABFAGwAZQBtAGUAbgB0KT4+DWVuZG9iag03NCAwIG9iajw8L1Bh cmVudCA2MiAwIFIvRGVzdFsyMCAwIFIvRml0XS9OZXh0IDczIDAgUi9QcmV2IDc1IDAgUi9UaXRs ZSj+/wBDAG8AbQBtAG8AbgAgAEkAcwBzAHUAZQBzKT4+DWVuZG9iag03NSAwIG9iajw8L1BhcmVu dCA2MiAwIFIvRGVzdFsxOCAwIFIvRml0XS9OZXh0IDc0IDAgUi9QcmV2IDc2IDAgUi9UaXRsZSj+ /wBOAG8AbgBlACAAbwBmACAAdABoAGUAIABhAGIAbwB2AGUAOgBNAGEAcABwAGkAbgBnACAAdABv ACAASQBQAHYANAAgAFMAdABhAHQAdQBzACAAUQB1AG8AIAB0AG8AIABJAFAAdgA2KT4+DWVuZG9i ag03NiAwIG9iajw8L1BhcmVudCA2MiAwIFIvRGVzdFsxNiAwIFIvRml0XS9OZXh0IDc1IDAgUi9Q cmV2IDc3IDAgUi9UaXRsZSj+/wBNAG8AZABpAGYAaQBlAGQAIABIAG8AcwB0ACAALwAgAFIAbwB1 AHQAZQByACAASQBuAHQAZQByAGEAYwB0AGkAbwBuKT4+DWVuZG9iag03NyAwIG9iajw8L1BhcmVu dCA2MiAwIFIvRGVzdFsxNCAwIFIvRml0XS9OZXh0IDc2IDAgUi9QcmV2IDc4IDAgUi9UaXRsZSj+ /wBNAG8AZABpAGYAaQBlAGQAIABQAHIAbwB0AG8AYwBvAGwAIABFAGwAZQBtAGUAbgB0ACAAQgBl AGgAYQB2AGkAbwB1AHIpPj4NZW5kb2JqDTc4IDAgb2JqPDwvUGFyZW50IDYyIDAgUi9EZXN0WzEy IDAgUi9GaXRdL05leHQgNzcgMCBSL1ByZXYgNzkgMCBSL1RpdGxlKP7/AFAAcgBvAHQAbwBjAG8A bAAgAEUAbABlAG0AZQBuAHQAIABJAG0AcABsAGUAbQBlAG4AdABhAHQAaQBvAG4pPj4NZW5kb2Jq DTc5IDAgb2JqPDwvUGFyZW50IDYyIDAgUi9EZXN0WzEwIDAgUi9GaXRdL05leHQgNzggMCBSL1By ZXYgODAgMCBSL1RpdGxlKP7/AE4AZQB3ACAAUAByAG8AdABvAGMAbwBsACAARQBsAGUAbQBlAG4A dCk+Pg1lbmRvYmoNODAgMCBvYmo8PC9QYXJlbnQgNjIgMCBSL0Rlc3RbOCAwIFIvRml0XS9OZXh0 IDc5IDAgUi9QcmV2IDgxIDAgUi9UaXRsZSj+/wBBAHAAcAByAG8AYQBjAGgAZQBzADopPj4NZW5k b2JqDTgxIDAgb2JqPDwvUGFyZW50IDYyIDAgUi9EZXN0WzYgMCBSL0ZpdF0vTmV4dCA4MCAwIFIv UHJldiA4MiAwIFIvVGl0bGUo/v8ARgB1AG4AYwB0AGkAbwBuAGEAbAAgAFIAZQBxAHUAaQByAGUA bQBlAG4AdABzKT4+DWVuZG9iag04MiAwIG9iajw8L1BhcmVudCA2MiAwIFIvRGVzdFszIDAgUi9G aXRdL05leHQgODEgMCBSL1ByZXYgODMgMCBSL1RpdGxlKP7/AFQAaABlACAAUAByAG8AYgBsAGUA bQAgAFMAcABhAGMAZSk+Pg1lbmRvYmoNODMgMCBvYmo8PC9QYXJlbnQgNjIgMCBSL0Rlc3RbMSAw IFIvRml0XS9OZXh0IDgyIDAgUi9QcmV2IDYzIDAgUi9UaXRsZSj+/wBUAGgAZQAgAE8AYgBqAGUA YwB0AGkAdgBlKT4+DWVuZG9iag04NCAwIG9iajw8L0xlbmd0aCAyMDA0L0ZpbHRlci9GbGF0ZURl Y29kZS9UeXBlL09ialN0bS9GaXJzdCA4ODQvTiAxMDA+PnN0cmVhbQ0KeNq0WV1vYzUQ/Sv+A+Re j78lVGkrQKAtUG0XeKj6ULphqSjNKmQR++85Yx+nTbK5KCR96bjOeDwfZ4597y3RjKYkI76Yko1P EMUEl4wdRxPSCGlNHB2kmOg9pDMpF0hvso+QwZRgIXWcRP8YK15nMgZFTUDdwbS1+MerEYufQ4Ci xYKYsdRii6R2LH7OQWeCsUV0Bv+UCEWLBaVg2mYjY7VTMMiYkdFINY8FIqIuCAYRVsVhgKjgFOIM OhM0YFWORgKmLRZIqMqwHIouh+UUoONgOUfMOFgumgkHy8VpTLBcEnZ33rhRY3LBOBth0EXjRP1F Kp1oXC5joJtipXO6qR+N8wk6SJaLTnMjxqWMSL0zLqvPCNIVWLU+GD8mXRWNb4lMGGgFPApn66pi vNPawW/vdAYbe0xhIBhodRC/D1qr4DGA46iD8TGjVki6z151YLkU1ckm1MoEgELN2whUWE14tCaI VgeFAV50xpngUQeNP3iYtzFgULA8RhOCFgV5DDGrDixn3T3CcsUPsBZKhk4C4LQOFu7GmszkTBTg 0SL+6BAKkIKBojBFRaX+lDBQjKVsYqhoKhgoDrFfjBpOhuWsNUVqMIG9MsA8ak2zx0BritjSqOEA lKniFD4lTbZFjpKusNg4AVIA42iSU4PFYqCwKWKSB1Iswk5e61VgOaCeFsBNEU325ZfD208f5sPV avnxbvV2OZ+/WSxWw+trxeZo3hjtkCodJaqtUitaZWzzAE+TcKVK29ZLiU2mpie0K66tF9v00TlV ahhVprbO0r6ip0rX9tF2gbwZLm+X88fquXIHpp7N/DD/Z/V6/gmbDG8WD/Pvbz8osUDn7AyB//Dx z7+uR+WYarCyTHWl8kwNojJNDbtyjY5CZRsdNb7RUaqMo6NcKUdHpXJOtdxYpw5t5Z0WQGWeFlPl njr0lX1axJV/WhIqA7W8VA6qw1xZqGWt8lBLZGUizU2N8i1ycL74Z/jq/u/h6vdb1Pqb+/cfl/Ph W9R9+XD/+MdwoX9+nt+tFkv+eHZ27X0mAJrraFTK6vTNtWcl0NyUVPRjV+AKZynHLSlNUZunppu1 d4XpL8RYcZTEWgmUkZLYa8WFpCcsqGc5fS8mS+lZSM8y+lZEOJS4ceLGBK9SS5PcOHHjlLkwcCLQ k8DIIiOLjCzKMRIbMemOSXeeG3hu4LnAMwLf2zQcI7GxcAPhBsINhBsIF0g8UqZjJBxlRzr2o2M3 urETFDNmiWcho0kmQ2UyVg6UZLKcKNlwRK8QvUL0SmGt9OCvE6QyiTQYaTDSYKTBSIOJjSQsnrAY 4rmQnCtsVWGrClv1v6Xdkn1DFllYZGGRhUUWFllYLGHyRegID4H/lGSCtWzzcIAUJ+S3AyUMsOWF LS9seWHLC1teiJL/KW+u9RxvZEwCJ3os0WOJHps7aZOxMynDsuqWVbepH4A0nAgjS26x5BZLbrGR VbO+nyF0gbCxhI0lbKxnkizLYJl+6/p5REPOdcV+ZlGh4eIGx8trMw6vrjH4cbi4/bT4uBp+Wd6v 7h/ff794Nx8ulm9/rSfQq4f794+4ZdwuV+3vd4/vcEjjyJ7lFIavH99xAhWchbMznOv1Iqzn+dVw OVy+N43h6pn22tj6e+bvF+eLd592dKTquEkdRnJMCHBz5jZiwBE/w8TVh9u7+fn8t8VybsYZHhZK SdUS1b5w42zsofru5nfNs2tG1yNoWqFrrd1v6y77fQi/8cBfm+n3pdDNlK55hSN/bWicNtRrf9pM lTiTIxN1Yvy54NZ7ufwcfy5v46+dvc+xtaFT8dfQtlfHVR07qePrXn5Sh616VHVC3u5FdyiMXdiB MS8oTEQPtgfUVsVtWNPOZb/u78Ka9x+u3Q/rMm2oc99pYV1BdFziOhmftqLOHl3RfjqcHGrH+vVy PBBkgwfiNg+E3d6MGzxwTKpc3AJXsPs4s7s77nW30k0Ik+5WuglxUidU2sqTOrxmnBYneDKvM4dA xZcdUgq8EYV+I8prMlpn72KtvH2dKk/K9vPsFHiB4oV6Hzu1C9t+Q2tofcavfs07LXNJCocyRHA7 DNEunCdmCJ9mxxa+X4FP61nMNYnHefZy7BXDBh34bfaKu63ut28xMU3qVFqJdlKHjyknPs+yO/QC GWWHDWJ/1circoukabvtrovrno3+883Px3uu3dv8IU0b6g96J342cWV2ZML6k+eJS1kO7u9dz16u i9LGs2i7Aj3vorT7LCAvdwfA9Wcv53SHw16Ha7vmcdLhegtIblKHryZOi4N06E0w7T465/4K5enR OYXtYz3lrfctTw8kac+zNF/30tjezm5vdPYbWqPlM37190An7vpSZvFAokx5p+/TCzySlDyzcmTF T/0OKuFQ4V7FbrTRzjuosnuZ3nkHVeKkTm3HkiZ1ajuWPKlTL+WlTOpE6Mg4Tuqk4VX9rEiElq7d vh5tap8D1NcyysxL9jg/k5Y3jmPS1+SzEnz9ihriTDxm5eapRM8rsF61cavSm6gfJQ+XD8DGn5gc zh8Wd3/0buR7dltk443qvq5sL2o3Itpqb35msuWJCfaq8oznFyiWr5eol6GnupmSjU4/8jzYRGxI 069qvprfLZa3q/vFY/3a+xNW6ae/eQf5+gF3nazjmT26nbY69K1Ief5o8a8AAwC9sYiSDQplbmRz dHJlYW0NZW5kb2JqDTg1IDAgb2JqPDwvTGVuZ3RoIDE3OTkvRmlsdGVyL0ZsYXRlRGVjb2RlL1R5 cGUvT2JqU3RtL0ZpcnN0IDg4OC9OIDEwMC9FeHRlbmRzIDg0IDAgUj4+c3RyZWFtDQp42txawY4c txEdH3yLgXwCj84hPSSrikUahgAtkINgGVlYMnwY6yBLE0WIsmsIY0D+P/9IfiTOK05zNdOzS3vS vbCtBXab3XwkH1+RVcXuDSU570JRF4RwzY58wrU4Tt5F710KhGtwmjKu0eWccCVXYsSVXRF7Lq4U xhVtPVlDdOjrk+xCrF0UFKzPgPGiVYXgAkW0DhGFHJzhQMOq2IVkAwVxIZOiYKyyFezXG8ZaJvQc iovRmkf0TvYn4oYEGOPIalXACUjFiKfCuIuCglpTDJMwToyoTmJg9JxsrIhqtaaYEnnGYwqOyAal 6IgzOiNyJAQgeJOoVYmjZGNRQqFi1FHGXSToW4rRhMCBUcXecSwYnYNjtiE4mvbAgCUrrBKB46wG FselgCEnJ974sqJgfNBSPMwWuTgJZJPzKNjcMSVhE1yikww7RHQqxcwEjaRkA4tL3oSUhIINKgrT B2uVXYpmfCkusakBKyZRUyu4pJAkpuhSzlZFTr1ZJ7HTYHZIgoIYOKFQDKNOq7ToVK0+puKUsMai ehTM3OCtZGJqdCpmItxo8vYEPaeKQc9JrQo9K5ZVBCfN1qFml70tEBg4B/Qas3eZzPhYKJmNfMZa TjBjBO+sYhi21Y1WUCQXmwWWYC5sVYqCjZWzKz5Yq4KC2QvmLN6sDMOUYMuvRBQgZMRsS50y1C9U wdgoDFN//vn6C1vZ2HxfrR9ucPv39ePnP17/sFt/8/b17vXVqy+vX27Xj98+/W79dPtu9/DN61dX 6ye75293+7+Prl5ur3bYEzKQyvpvVy/HJ0JDlPWT75+/2F5s/3H9duv8gP1citaORtRfyQ/+wYNn 60tnBI3Fk/XjRw8ejMR4NrFEQz4ilsug84nJ8sRCSUswS/dgy0WI6X1IBiKzl5mfQ6rohJPmIUXZ D2bRZj/Y5fryFTar3TVBrB47eCRzcf3yxxNMrBjqYqhiuIvhipEeZgPP6+BdHOIjIiNiYny2flgj qLW6rCF03/7JP59/v520v7i4frdBKB2yeI/wm2QIGTEYYQqliKhsQVgG8cF7ffZe7EMtW6MDNROl AbHGR0zzDYz8bzxcX7y5fvGvkfYocY3n9errBjD1S2qEty92TVG49+l8zLyg3xDhFxCb0WrNMk39 pnA1/J6NiX0zcJy7/jHVwR9oAwduS+2c1d8md7D6LYmaS4z9cLQFUnUgc3nx0rw4DwvQksVp2e08 Vsu6sCzQaRwr+iMPlg48BhIlh9zQVc9RnUXIbeuEcuIs0rGzgCMeGJkNWfo0FLZkmrkMBZkc2zMa UmHsrTucRWt07HrJCxKtu3xFHH1E0K6PCOlkGsc+Ylm5Kb+Xm+hIbp4GDEonTpynAYO0i6kBg3IX UwMGlS5GDMO+i0kVE7oYrZjYw2wOwxLOZnWxMTUrUTxabA/f7D7978+rp6vt6t1qt3Kri9U1Sp+h 9Gh1ufqVP+6z1Uerj1H4aPXn+uAdSv9Z/enm+nv++faT1V9ORLRjLVfpKJwv3derx79WvA9Nun1y Q3EQ8h4nRvgZ5BHeTrcpDR7nXZx2Q4L3QYjOdzqs1uowvVF4OcVJLt3lsmjMMWjMMeKY7pDvurB4 auFJmkPSR2xGX9P8SfMZzS+0vd/2d9vDezfG0/Qnzk5/gvJw5Dc5WT50TuAkOQnnkRbnRerPzstu Y8bLK5bl7MzsNmbzUyCf7PXAoS0XMGVanhYvopcuT+zctxi38sqzeZEer7CoswXbe9sUBk2l5ENv S4zlm0sRtldD2GPp7rPkrd5WjB3feZi8x7xO+Civi9O8Tk5ztjjN6yR3MTWvk9LF1Lwu+S6m5nUp 9DCbw1cFVFOKFFs4EbqHbGz1E37/8CnFoYTvX7HI/yHdGdnYhybdb5mNyZiFiYzXMQWS0M3GmE8s PMnGJPURm9FDNC/QdnrbzW3H7p2NTLMvnv++Osf6qvUwBPGZr/jbLA9jEM8P2oFqunXwWljy2QnY bdR0eWrp/ITiNmb5Hpjtw9dcZmV5ZhLPzA2nvD6cjELoZpIqRxmFn2YUevqmyE8zCtUupmYUmruY mlFo6WJqRpF9F1PfFOXQxdQ3RdrH2Lfbua4O7mPynQnb9rwlqHGyNTajQZroTdgmXhOoidAmuu+N pg5db3IG5dvjhY4hat/2ztCUqN9R/YQ+V9DxVHD44Y7O9jYnktaP+ovbWmVYgFhanliiYT4vvQ9b +iUUy8srFokXkKwsLxkhmaLZmi383ZotvxsHK3oYXMLxd+vfYtQarspJKAonX8JL6WIsXOHY0MVI xYQuJlVM7GK0YqiLyRXDXUypGOligq+T7w9m/xG0+CbjyGcn24VPomMZo+Hefs1GzQ5N66Zn06zp 0qa+7/3k+FNuzl83MfAmyP1PgAEAUav13A0KZW5kc3RyZWFtDWVuZG9iag04NiAwIG9iajw8L0xl bmd0aCAxNjg4L0ZpbHRlci9GbGF0ZURlY29kZS9UeXBlL09ialN0bS9GaXJzdCA4ODgvTiAxMDAv RXh0ZW5kcyA4NCAwIFI+PnN0cmVhbQ0KeNrMWdtuGzcQ/RX+QFcczoUkUBiwgT4ETVEjDtAHIQ9u rKZBUzswXCD5+56hdhVpJW8q7Brog70j7uFwOEOeGXJTtRBDqjlwxaOEkvCAyBo4xsCl4ElBhfBM waq3cyiKd1ECRfzjqIFIKwQLxOQtOZBwglAgmCupgdTBFCEIuhNByAYhBbIEMHGgLBxcBeXqGGgu yXtBc1HoIWiu6MpUQormAsxN6MoJM2GDgYlCUvRgKE3G6J4YQoZC6Eo5+iuFIBg0GYQMzSmHVFoL NLchkk+JIbDPtqCX/yCMwz43TANCGxj+82HY7XHXKbVfgc28F16X5K8wTPUh4G2JPh04QmIFGA4W 8nHwWsh7wRGS4HMWgeBdRSFkB1sQ78qSg4gPKiWIRsdAs/oQiJA09yo0m7hR0Jw91ArNFUDGBJQQ XlYNmtR7GWKNALPmoKoulKCW/VUNmn0IixBglM9Wc4EZloIWd7gxhNYiwaJrRjwsivcyCFhebDkY NXCBYDADf+bRY0TIJKMX/swQNMbAljOMzxysVG+B5ooQMVqtmrdAc63ekkOOHhCEE0H2lhoy+XRg U07u8EIhe6gREAjuusIhS1vrAsHDWDRk9XDjL2df+gWa2+jYDyWKd6+hEHYKY5kWX6dcCYLvi5og FG/BRhGfFwJcRL1FIaDHjz+ufl77tovhDRab+vPd6jq07fhmdbO62bx/urjYwmBpg8HQHpZ2uLeb L09XD1+2UF+/rf1yjZ+/rl7ffn3452n12+PHp4/3H355uNusXj++/b11uvz08cP96ubp9vFp+//V /d3m/ilQyh1cu/rp/q5v0Zg6Xd18vn2/udr88fC4CbHDzGvNTVGP+oFjFy8uttZJb93rVzvDdLZh WrpyYJhEWsAwewHDKHdxtmF5ecOIapfnu6y8gMuSdJbmm1ZfYP1bXMBp2PSLOy2ZNVvnmkYvsNKM O5odzzjHqJpHNnH1JbYdzEuM7WDXq+sPMNd/9aNSe58HY64e7r4eYVLDlEkMN0ydxIhjUpzE6Oqy FUmOuW5VUp8j/rz9vBmhr5AM1qgaOkEuMM9acAIysdc2uasqFbxCal0StKZ333y777pdrz3vWVFs A4mprK4/Iah/o3F19enh/V99nupd2oq27ZMm0lorFsczOsxmTN9BrPsoDZEYvD14dBtoHZy7G3g+ s1ruDtirnMf3w8z2lrpXynOtqhVmfLMqx3PZ4aRddWm7VM+lhlN2UVzaLhxUZodxWcYS2mMsjgeM JWPGYj5iERkzFsskpjEW6ySmMRbbFGaNyjzkUALOfDjt4ZwHorls56B+P6d6xGH7/f0giCOgOrP5 gQ+HSBzyYlOSyn9S0ogQR55OCiLoB9WuCuEAKhk8hvMCDgMJ/k2GA1B+hgd3vfZ5EG0ZVT/Jczy4 DVQ7LG7JyPpnnuTDREcTG/Ehp2nEul8DQ5yHWA7x2i4jGvNhSnN3EpLJuDTJ55Zzw+z293ji2ZYh lR2WczjZnrnLTxkmy7tMuJvvMH0Bh6GUK3meaW03UikdaYxxfzuiSkCtAl3cXFJ9O8oZ21GrdhHb MdLp7bgwI6e6m6OUAz5OYz5WOuLINOZjTZOYxsfKk5jGxyqTGG0YncRYw9gUZn3I6aHRdCNl2VVq ko9IOY2q05Q6QigjeZ2ZIkW/MRPtGEyNiVDxo6BXn89Xp9te+6ysfmxDdcrPsbL0JaL0JaLoJBtz OZrRiI01TiPW/QoYojxEcojWEJHB69tFVcfszAvUX9YdMqB2Z3KzxiOqkdn1V0rlsC6Us3nmlF20 uL8yLeGvtLi/creAu3hxd5Uz7wtPmiVLe4tttlULpxIue9W96UE2ieNsYsd3DXGcTaxOYlo2yXES 07JJpinMc9W98cCHJkc5IP4vcoD1hGt9RW5pMgdoPprRKAfYdxDrPm5DbAb/Dz7eht7GnK+z7wJS uxvfv705l8IsH21KnZ2KEvMhhdkCZllc2iwUoraAXbS4u2gBuxa+ooj7t6qF91msjEmsHJWpZcxh RacgjcKKTUEag5U8BWnlcClTkFYN5zppS36B7yAJIT63CCrjRLXuHT14c3DZ4Jdh8sMMt1qO7gXK rsAt6TS5lb6gLdM3vTlNK2pfdxf/bpOlm+nH9rF58RD7pRTn+abpC7js3AvQU3a9wAdVJj43T5yy LC/vMauzPbYsH1NF4t+OJUT7bDz+xCV0xMbjL1xCOgXhBrEpiDRInoJog5QpiDVIfQbyrwADAP7c 9rkNCmVuZHN0cmVhbQ1lbmRvYmoNODcgMCBvYmo8PC9MZW5ndGggMTA4MC9GaWx0ZXIvRmxhdGVE ZWNvZGUvVHlwZS9PYmpTdG0vRmlyc3QgNTE3L04gNjAvRXh0ZW5kcyA4NCAwIFI+PnN0cmVhbQ0K eNrMWG1vGzcM/iv6A7uTRFIvQGEgAfahWIYFTYF9CPIhTdw0WGYXgQe0/34PdbrEPsc3OHcGViCV TveIfEiRMnmUg7GGcjQkGJKJ+pSNs2LYWuPYYXTGxYjRG+8IIxnPGSMbnxSHrV5xAVIUB2lZcckI 63M2AXN21gT2GJ0JCfudN9EDB5lR9zk2KTJGgX6vC8E4lywm0TgCQ3YJlMpecAwMsAfJCOIMBi4L aHilCS4M2d4HXQFRlcpejJeA7T4YH71uj7AhKjgZsgRdPhtyCbTwQER4RQ6TpBMPA2E1ExkK0MPE mIi+gg+i1V1wQiSQxx82QSAldbCuqM9gNLNV52GleDfpile6kMOkVLCstpFyZlHpeGJVk2Cp7hTd wXgIWXdBctKjEUjOgldwhNgMOXgQD5tYCBPdDllC6l4RTOCfDx/a30xsL4szrfnUXrUX5+v7n+3l g9Hw+LRYFEgqEDcGyQXixyDOFgyNYlzB8CjGF4yMYqhgwiiGCyaOYqRg0igmFEwexRQv21Fdmkb6 +uwaj3+0F7c/1/9s2j+fHzePq4ff1/fL9uL585f28/LH5uzp8WHVXm1unzfd/x9X98vVxnC0TYrS /rq671eoLFx9v71bni+/rp+XxjYu418skirsF7KNXSxuCssXaz92zK6rI3tn9Q7pje4N63a/+OHF rE7eZbkHuneq+Xz9oxfvXCfG+Sou9+Jyf4JXy7tNFUgpjwssF8t/qeSqUupYLXTVQlctdNXCLkH6 LOhDvQ/nPmT7sCyecH7gCcp26gE7HxvaOWBc2s1x5+tocL6Q4SYTkzSMvOgbO5mYPwGxkBrnp/uM TkDNpyZOZ8bzMxOXjr5I3qImJ3BadnM4LczPjDjNkALxBC4jasIMKZBOkwJzBFo+xY2Wm8lO0+L6 /5kCWu7Pz8zxDJetdiBTSyPKw1/OY3+f9gqj0hHNXrIlO71kKz3a7Mxwa8xATE5AzB6bmPtFrjVo 8m7as9LJ1eqR+kbk6tvt96UW7LRd1E8xIseBDT57vZMrP+rbm8uhVp6ilUSGarHyqpUOaiW/55RB SU21lKZaEpMdq+K1uR4TeI7JNdr5RhJn1KdO4B4XLC4HIa2SxCKSJDrYk1FX3Lx6ZPdG6rdt24wA ct4GQuf2hJj5G4vt+dP67q9Kzs56smhYwLe6mHcO1u2E02Xp9Qct4jakdL4cxyCl8WU3BtHPELP3 IXz8rcV+r9Hk2oZxbcM6Qzo0DRtLfglJPhCSXEOy23s4FOO4oPIpZ3aP1TiZ5LHybWl2ZhKP/s3e ZzYph5JeStsZi56tVyW8nUEc7PuuZAjfUelRqYQdpXL420lPxR+m4t9PRQLNSoUmUImDk5jE5Fo/ WJaMlJqZUr+ryGuiC72dzFI/sXTyDyYzv3xuelPQuz0RQihZsd0PHKo69jyxWPwrwAC81HIoDQpl bmRzdHJlYW0NZW5kb2JqDTg4IDAgb2JqPDwvTnVtc1swIDg5IDAgUl0+Pg1lbmRvYmoNODkgMCBv Ymo8PC9TL0Q+Pg1lbmRvYmoNOTAgMCBvYmo8PC9Db3VudCAyMS9LaWRzWzkxIDAgUiA5MiAwIFIg OTMgMCBSXS9UeXBlL1BhZ2VzPj4NZW5kb2JqDTkxIDAgb2JqPDwvQ291bnQgMTAvS2lkc1s0NjAg MCBSIDEgMCBSIDMgMCBSIDYgMCBSIDggMCBSIDEwIDAgUiAxMiAwIFIgMTQgMCBSIDE2IDAgUiAx OCAwIFJdL1R5cGUvUGFnZXMvUGFyZW50IDkwIDAgUj4+DWVuZG9iag05MiAwIG9iajw8L0NvdW50 IDEwL0tpZHNbMjAgMCBSIDIyIDAgUiAyNCAwIFIgMjYgMCBSIDI4IDAgUiAzMCAwIFIgMzIgMCBS IDM0IDAgUiAzNiAwIFIgMzggMCBSXS9UeXBlL1BhZ2VzL1BhcmVudCA5MCAwIFI+Pg1lbmRvYmoN OTMgMCBvYmo8PC9Db3VudCAxL0tpZHNbNDAgMCBSXS9UeXBlL1BhZ2VzL1BhcmVudCA5MCAwIFI+ Pg1lbmRvYmoNOTQgMCBvYmo8PC9MZW5ndGggMzUwOS9UeXBlL01ldGFkYXRhL1N1YnR5cGUvWE1M Pj5zdHJlYW0NCjw/eHBhY2tldCBiZWdpbj0n77u/JyBpZD0nVzVNME1wQ2VoaUh6cmVTek5UY3pr YzlkJz8+Cjw/YWRvYmUteGFwLWZpbHRlcnMgZXNjPSJDUkxGIj8+DQo8eDp4bXBtZXRhIHhtbG5z Ong9J2Fkb2JlOm5zOm1ldGEvJyB4OnhtcHRrPSdYTVAgdG9vbGtpdCAyLjkuMS0xMywgZnJhbWV3 b3JrIDEuNic+DQo8cmRmOlJERiB4bWxuczpyZGY9J2h0dHA6Ly93d3cudzMub3JnLzE5OTkvMDIv MjItcmRmLXN5bnRheC1ucyMnIHhtbG5zOmlYPSdodHRwOi8vbnMuYWRvYmUuY29tL2lYLzEuMC8n Pg0KPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9J3V1aWQ6ZDI2Mjg1NGItZDUzMi00ZGU3LWFi ZDQtY2Q2Yzc5OGQ4MmZhJyB4bWxuczpwZGY9J2h0dHA6Ly9ucy5hZG9iZS5jb20vcGRmLzEuMy8n IHBkZjpQcm9kdWNlcj0nQWNyb2JhdCBEaXN0aWxsZXIgNi4wLjEgKFdpbmRvd3MpJz48L3JkZjpE ZXNjcmlwdGlvbj4NCjxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSd1dWlkOmQyNjI4NTRiLWQ1 MzItNGRlNy1hYmQ0LWNkNmM3OThkODJmYScgeG1sbnM6cGRmeD0naHR0cDovL25zLmFkb2JlLmNv bS9wZGZ4LzEuMy8nIHBkZng6Q29tcGFueT0nJy8+DQo8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91 dD0ndXVpZDpkMjYyODU0Yi1kNTMyLTRkZTctYWJkNC1jZDZjNzk4ZDgyZmEnIHhtbG5zOnhhcD0n aHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wLycgeGFwOk1vZGlmeURhdGU9JzIwMDQtMDMtMDJU MTI6MjA6MDIrMTE6MDAnIHhhcDpDcmVhdGVEYXRlPScyMDA0LTAzLTAyVDEyOjE5OjIwKzExOjAw JyB4YXA6Q3JlYXRvclRvb2w9J0Fjcm9iYXQgUERGTWFrZXIgNi4wIGZvciBQb3dlclBvaW50JyB4 YXA6TWV0YWRhdGFEYXRlPScyMDA0LTAzLTAyVDEyOjIwOjAyKzExOjAwJz48L3JkZjpEZXNjcmlw dGlvbj4NCjxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSd1dWlkOmQyNjI4NTRiLWQ1MzItNGRl Ny1hYmQ0LWNkNmM3OThkODJmYScgeG1sbnM6eGFwTU09J2h0dHA6Ly9ucy5hZG9iZS5jb20veGFw LzEuMC9tbS8nIHhhcE1NOkRvY3VtZW50SUQ9J3V1aWQ6MGYyZDA3ZTEtMmRkYi00MGQzLTkzMmUt OWRmYjdiZjQ1ZTE0Jy8+DQo8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0ndXVpZDpkMjYyODU0 Yi1kNTMyLTRkZTctYWJkNC1jZDZjNzk4ZDgyZmEnIHhtbG5zOmRjPSdodHRwOi8vcHVybC5vcmcv ZGMvZWxlbWVudHMvMS4xLycgZGM6Zm9ybWF0PSdhcHBsaWNhdGlvbi9wZGYnPjxkYzp0aXRsZT48 cmRmOkFsdD48cmRmOmxpIHhtbDpsYW5nPSd4LWRlZmF1bHQnPkFwcHJvYWNoZXMgdG8gTXVsdGk2 PC9yZGY6bGk+PC9yZGY6QWx0PjwvZGM6dGl0bGU+PGRjOmNyZWF0b3I+PHJkZjpTZXE+PHJkZjps aT5ub25lPC9yZGY6bGk+PC9yZGY6U2VxPjwvZGM6Y3JlYXRvcj48L3JkZjpEZXNjcmlwdGlvbj4N CjwvcmRmOlJERj4NCjwveDp4bXBtZXRhPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAg ICAgICAgICAgICAgICAgICAgICAgIAo8P3hwYWNrZXQgZW5kPSd3Jz8+DQplbmRzdHJlYW0NZW5k b2JqDTk1IDAgb2JqPDwvTW9kRGF0ZShEOjIwMDQwMzAyMTIyMDAyKzExJzAwJykvQ3JlYXRpb25E YXRlKEQ6MjAwNDAzMDIxMjE5MjArMTEnMDAnKS9UaXRsZShBcHByb2FjaGVzIHRvIE11bHRpNikv Q3JlYXRvcihBY3JvYmF0IFBERk1ha2VyIDYuMCBmb3IgUG93ZXJQb2ludCkvUHJvZHVjZXIoQWNy b2JhdCBEaXN0aWxsZXIgNi4wLjEgXChXaW5kb3dzXCkpL0F1dGhvcihub25lKS9Db21wYW55KCk+ Pg1lbmRvYmoNeHJlZg0KMCA0NTYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAyNjQzMSAwMDAw MCBuDQowMDAwMDI2ODIxIDAwMDAwIG4NCjAwMDAwMjc3MjQgMDAwMDAgbg0KMDAwMDAyODEyNCAw MDAwMCBuDQowMDAwMDM4ODcyIDAwMDAwIG4NCjAwMDAwMzkwOTMgMDAwMDAgbg0KMDAwMDAzOTQ4 MyAwMDAwMCBuDQowMDAwMDQxMDAwIDAwMDAwIG4NCjAwMDAwNDEzOTAgMDAwMDAgbg0KMDAwMDA0 MjQ0MCAwMDAwMCBuDQowMDAwMDQyODQzIDAwMDAwIG4NCjAwMDAwNDQ1ODQgMDAwMDAgbg0KMDAw MDA0NDk4NyAwMDAwMCBuDQowMDAwMDQ2ODYwIDAwMDAwIG4NCjAwMDAwNDcyNjMgMDAwMDAgbg0K MDAwMDA0OTU0MCAwMDAwMCBuDQowMDAwMDQ5OTMyIDAwMDAwIG4NCjAwMDAwNTIwMTMgMDAwMDAg bg0KMDAwMDA1MjQwNSAwMDAwMCBuDQowMDAwMDUzNDI5IDAwMDAwIG4NCjAwMDAwNTM4MjIgMDAw MDAgbg0KMDAwMDA1NDg3NSAwMDAwMCBuDQowMDAwMDU1Mjc5IDAwMDAwIG4NCjAwMDAwNTcwNjMg MDAwMDAgbg0KMDAwMDA1NzQ2NyAwMDAwMCBuDQowMDAwMDU5MzcxIDAwMDAwIG4NCjAwMDAwNTk3 NzUgMDAwMDAgbg0KMDAwMDA2MTM4MyAwMDAwMCBuDQowMDAwMDYxNzg3IDAwMDAwIG4NCjAwMDAw NjM1NDYgMDAwMDAgbg0KMDAwMDA2MzkzOSAwMDAwMCBuDQowMDAwMDY2MTU2IDAwMDAwIG4NCjAw MDAwNjY1NjAgMDAwMDAgbg0KMDAwMDA2NzU5MSAwMDAwMCBuDQowMDAwMDY3OTg0IDAwMDAwIG4N CjAwMDAwNjg3OTcgMDAwMDAgbg0KMDAwMDA2OTIwMSAwMDAwMCBuDQowMDAwMDcwMTkyIDAwMDAw IG4NCjAwMDAwNzA1ODUgMDAwMDAgbg0KMDAwMDA3MTYyOSAwMDAwMCBuDQowMDAwMDcyMDIyIDAw MDAwIG4NCjAwMDAwNzI4NjcgMDAwMDAgbg0KMDAwMDA3MzU2MiAwMDAwMCBuDQowMDAwMDc0MTM1 IDAwMDAwIG4NCjAwMDAwNzQzMjggMDAwMDAgbg0KMDAwMDA3NDQ1MCAwMDAwMCBuDQowMDAwMDgx MDQyIDAwMDAwIG4NCjAwMDAwODEyODEgMDAwMDAgbg0KMDAwMDA4MzkyMiAwMDAwMCBuDQowMDAw MDg0NTkwIDAwMDAwIG4NCjAwMDAwODUxNDQgMDAwMDAgbg0KMDAwMDA4NTE4OSAwMDAwMCBuDQow MDAwMDg1ODQ0IDAwMDAwIG4NCjAwMDAwODU4ODkgMDAwMDAgbg0KMDAwMDA4NjYwNCAwMDAwMCBu DQowMDAwMDg2NjQ5IDAwMDAwIG4NCjAwMDAwODY4NzcgMDAwMDAgbg0KMDAwMDA4NzEyOCAwMDAw MCBuDQowMDAwMDg3NTE1IDAwMDAwIG4NCjAwMDAwODc5MDEgMDAwMDAgbg0KMDAwMDA4ODE3NSAw MDAwMCBuDQowMDAwMDkyNTU2IDAwMDAwIG4NCjAwMDAwOTI2MTAgMDAwMDAgbg0KMDAwMDA5Mjcy NCAwMDAwMCBuDQowMDAwMDkyODQzIDAwMDAwIG4NCjAwMDAwOTI5NTQgMDAwMDAgbg0KMDAwMDA5 MzA2NSAwMDAwMCBuDQowMDAwMDkzMTc2IDAwMDAwIG4NCjAwMDAwOTMyODcgMDAwMDAgbg0KMDAw MDA5MzQ2MCAwMDAwMCBuDQowMDAwMDkzNjA5IDAwMDAwIG4NCjAwMDAwOTM3ODAgMDAwMDAgbg0K MDAwMDA5MzkzNyAwMDAwMCBuDQowMDAwMDk0MDk0IDAwMDAwIG4NCjAwMDAwOTQyMDUgMDAwMDAg bg0KMDAwMDA5NDM5NCAwMDAwMCBuDQowMDAwMDk0NTQ3IDAwMDAwIG4NCjAwMDAwOTQ3MDIgMDAw MDAgbg0KMDAwMDA5NDg0OSAwMDAwMCBuDQowMDAwMDk0OTc0IDAwMDAwIG4NCjAwMDAwOTUwODAg MDAwMDAgbg0KMDAwMDA5NTIxMCAwMDAwMCBuDQowMDAwMDk1MzI4IDAwMDAwIG4NCjAwMDAwOTU0 MzggMDAwMDAgbg0KMDAwMDA5NzU0MCAwMDAwMCBuDQowMDAwMDk5NDUyIDAwMDAwIG4NCjAwMDAx MDEyNTMgMDAwMDAgbg0KMDAwMDEwMjQ0NSAwMDAwMCBuDQowMDAwMTAyNDgwIDAwMDAwIG4NCjAw MDAxMDI1MDQgMDAwMDAgbg0KMDAwMDEwMjU3MSAwMDAwMCBuDQowMDAwMTAyNjk4IDAwMDAwIG4N CjAwMDAxMDI4MjggMDAwMDAgbg0KMDAwMDEwMjg5NCAwMDAwMCBuDQowMDAwMTA2NDgwIDAwMDAw IG4NCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1 NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAw IDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAw MDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAw MDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQow MDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBm DQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUz NSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2 NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAw MCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAw MDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAw MDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0K MDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUg Zg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1 MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAg NjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAw MDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAw MDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAw MDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYN CjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1 IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1 NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAw IDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAw MDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAw MDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQow MDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBm DQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUz NSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2 NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAw MCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAw MDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAw MDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0K MDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUg Zg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1 MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAg NjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAw MDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAw MDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAw MDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYN CjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1 IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1 NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAw IDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAw MDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAw MDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQow MDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBm DQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUz NSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2 NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAw MCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAw MDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAw MDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0K MDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUg Zg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1 MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAg NjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAw MDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAw MDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAw MDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYN CjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1 IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1 NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAw IDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAw MDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAw MDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQow MDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBm DQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUz NSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2 NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAw MCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAw MDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAw MDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0K MDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUg Zg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1 MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAg NjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAw MDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAw MDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAw MDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYN CjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1 IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1 NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAw IDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAw MDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAw MDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQow MDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBm DQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUz NSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2 NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAw MCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAw MDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAw MDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0K MDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUg Zg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1 MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAg NjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAw MDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAw MDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAw MDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYN CjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1 IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1 NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAw IDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAw MDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAw MDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQow MDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBm DQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUz NSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2 NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAw MCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAw MDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAw MDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0K MDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUg Zg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1 MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAg NjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAw MDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAw MDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAw MDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYN CjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1 IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1 NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAw IDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAw MDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAw MDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQow MDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBm DQowMDAwMDAwMDAwIDY1NTM1IGYNCnRyYWlsZXINCjw8L1NpemUgNDU2Pj4NCnN0YXJ0eHJlZg0K MTE2DQolJUVPRg0K --=====================_4420235==_ Content-Type: text/plain; charset="us-ascii"; format=flowed --=====================_4420235==_-- From owner-multi6@ops.ietf.org Mon Mar 1 21:13:40 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23056 for ; Mon, 1 Mar 2004 21:13:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AxzOK-0007Tc-Di for multi6-data@psg.com; Tue, 02 Mar 2004 02:12:16 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.30; FreeBSD) id 1AxzOI-0007T3-PQ for multi6@ops.ietf.org; Tue, 02 Mar 2004 02:12:15 +0000 Received: (qmail 38820 invoked from network); 2 Mar 2004 02:11:30 -0000 Received: from cfw2-mohta.wired.ietf59.or.kr (HELO necom830.hpcl.titech.ac.jp) (218.37.209.67) by necom830.hpcl.titech.ac.jp with SMTP; 2 Mar 2004 02:11:30 -0000 Message-ID: <4043EE01.1020402@necom830.hpcl.titech.ac.jp> Date: Tue, 02 Mar 2004 11:14:25 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Geoff Huston CC: Multi6 List Subject: Re: DRAFT of the architecture presentation for the WG session this week References: <2C4F5D6C-67BA-11D8-997E-000A95CD987A@muada.com> <6.0.1.1.2.20040302122144.01c94d38@localhost> In-Reply-To: <6.0.1.1.2.20040302122144.01c94d38@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Geoff; > In the interests of allowing everyone to come armed with the appropriate > weapons for > this agenda topic, I've attached a PDF of the current version of the draft. Thanks. > I may (will) change the presentation between now depending on the response > from this list,, but I would obviously prefer a little shaking out in > the wg on the > more generic topic of "is this architectural taxonomy on the right > track" and > "have I missed an architectural taxonomy element?" Well, Modify the Transport or IP layer of the stack in the host is generic enough to include Insert a new level in the protocol stack (identity element) and Modify the behaviour of the host/site exit interaction that it is no good for classification. Moreover, the classification is rather rhetorical (API) than architectural. That is, most, if not all, approaches of: Modify the Transport or IP layer of the stack in the host can have some API to make it: Insert a new level in the protocol stack (identity element) as demonstrated by my 8plus8 draft: 4.3 8+8 Adaptation Layers for Applications over TCP and DNS So, it is better if your presentation is titled: A Rhetorical View of Multi6 proposals Masataka Ohta From owner-multi6@ops.ietf.org Mon Mar 1 22:09:48 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26015 for ; Mon, 1 Mar 2004 22:09:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ay0Gu-000JrD-Vv for multi6-data@psg.com; Tue, 02 Mar 2004 03:08:40 +0000 Received: from [203.50.0.6] (helo=kahuna.telstra.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Ay0Gr-000JqV-RB for multi6@ops.ietf.org; Tue, 02 Mar 2004 03:08:38 +0000 Received: from gih505.telstra.net (kahuna.telstra.net [203.50.0.6]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id i2237ruX049110; Tue, 2 Mar 2004 14:08:00 +1100 (EST) (envelope-from gih@telstra.net) Message-Id: <6.0.1.1.2.20040302140158.01c8c4d0@localhost> X-Sender: gih@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Tue, 02 Mar 2004 14:07:44 +1100 To: Masataka Ohta From: Geoff Huston Subject: Re: DRAFT of the architecture presentation for the WG session this week Cc: Multi6 List In-Reply-To: <4043EE01.1020402@necom830.hpcl.titech.ac.jp> References: <2C4F5D6C-67BA-11D8-997E-000A95CD987A@muada.com> <6.0.1.1.2.20040302122144.01c94d38@localhost> <4043EE01.1020402@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Thanks for your comments. Obviously I do see a distinction between a distinct protocol element that reaches some form of state synchronisation with its peer and a modification of a protocol element where there are additional behaviours added to the element, but within an overall synchronized state of an existing protocol element. But as with any architectural model the precise places where the lines are drawn can involve some level of judgement. Regards, Geoff From owner-multi6@ops.ietf.org Mon Mar 1 23:25:37 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29328 for ; Mon, 1 Mar 2004 23:25:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ay1RE-0007tY-6g for multi6-data@psg.com; Tue, 02 Mar 2004 04:23:24 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.30; FreeBSD) id 1Ay1RD-0007tL-1Z for multi6@ops.ietf.org; Tue, 02 Mar 2004 04:23:23 +0000 Received: (qmail 39228 invoked from network); 2 Mar 2004 04:22:39 -0000 Received: from unknown (HELO necom830.hpcl.titech.ac.jp) (210.93.162.110) by necom830.hpcl.titech.ac.jp with SMTP; 2 Mar 2004 04:22:39 -0000 Message-ID: <40440CA2.8060204@necom830.hpcl.titech.ac.jp> Date: Tue, 02 Mar 2004 13:25:06 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Geoff Huston CC: Multi6 List Subject: Re: DRAFT of the architecture presentation for the WG session this week References: <2C4F5D6C-67BA-11D8-997E-000A95CD987A@muada.com> <6.0.1.1.2.20040302122144.01c94d38@localhost> <4043EE01.1020402@necom830.hpcl.titech.ac.jp> <6.0.1.1.2.20040302140158.01c8c4d0@localhost> In-Reply-To: <6.0.1.1.2.20040302140158.01c8c4d0@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_RFCI autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Geoff; > Thanks for your comments. Obviously I do see a distinction > between a distinct protocol element that reaches some form > of state synchronisation with its peer and a modification > of a protocol element where there are additional behaviours > added to the element, but within an overall synchronized > state of an existing protocol element. Huh? The properties you mentioned are not orthogonal that that's not a classification. For example, how about a modification of a protocol element where there are additional behaviours added to the element not within an overall synchronized state of an existing protocol element? Masataka Ohta From owner-multi6@ops.ietf.org Mon Mar 1 23:46:52 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00576 for ; Mon, 1 Mar 2004 23:46:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ay1n6-000BwI-1U for multi6-data@psg.com; Tue, 02 Mar 2004 04:46:00 +0000 Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Ay1mw-000Bua-UX for multi6@ops.ietf.org; Tue, 02 Mar 2004 04:45:50 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i224jmi5011713; Mon, 1 Mar 2004 21:45:49 -0700 (MST) Received: from bobo (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i224jjQ03655; Tue, 2 Mar 2004 05:45:45 +0100 (MET) Date: Mon, 1 Mar 2004 20:45:50 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: DRAFT of the architecture presentation for the WG session this week To: Geoff Huston Cc: Multi6 List In-Reply-To: "Your message with ID" <6.0.1.1.2.20040302122144.01c94d38@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk > I may (will) change the presentation between now depending on the response > from this list,, but I would obviously prefer a little shaking out in the > wg on the > more generic topic of "is this architectural taxonomy on the right track" and > "have I missed an architectural taxonomy element?" Overall I think this is on the right track. While in the fullness of time we want session persistence I think we need to look carefully at what is needed to introduce multihoming when the peers are not upgraded to use something new. I don't know if that is what the question mark after "session persistence" on page 11. Drilling down into the "defining a new protocol element" set there seems to be two classes: - those that define a new namespace (HIP, SIM, ...) - those that use an existing name space such as FQDNs (MAST, NOID, CB64, ...) With that split in mind it seems odd to clumb together the proposals on page 13; SIM is much closer to HIP (with the biggest difference being that the payload packets are not encrypted by SIM whereas HIP encrypts everything.) So understanding which proposals provide a new ID name space to applications would be useful. Erik From owner-multi6@ops.ietf.org Tue Mar 2 00:07:36 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01827 for ; Tue, 2 Mar 2004 00:07:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ay27A-000GZC-CX for multi6-data@psg.com; Tue, 02 Mar 2004 05:06:44 +0000 Received: from [203.50.0.6] (helo=kahuna.telstra.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Ay279-000GYz-7H for multi6@ops.ietf.org; Tue, 02 Mar 2004 05:06:43 +0000 Received: from gih505.telstra.net (kahuna.telstra.net [203.50.0.6]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id i2256WuX057264; Tue, 2 Mar 2004 16:06:39 +1100 (EST) (envelope-from gih@telstra.net) Message-Id: <6.0.1.1.2.20040302160302.01ccba68@localhost> X-Sender: gih@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Tue, 02 Mar 2004 16:06:25 +1100 To: Erik Nordmark From: Geoff Huston Subject: Re: DRAFT of the architecture presentation for the WG session this week Cc: Multi6 List In-Reply-To: References: <"Your message with ID" <6.0.1.1.2.20040302122144.01c94d38@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Thanks Eric - The ? was shorthand for "how do you..." i.e.I was intending to pose this as a question! - the distinction about the characteristics of the identity token space is useful, and I've added an additional slide to call this out, as there are certainly some implications about structured and unstructured spaces in terms of lookup and referral that need to be called out, I agree. regards, Geoff At 03:45 PM 2/03/2004, Erik Nordmark wrote: > > I may (will) change the presentation between now depending on the response > > from this list,, but I would obviously prefer a little shaking out in the > > wg on the > > more generic topic of "is this architectural taxonomy on the right > track" and > > "have I missed an architectural taxonomy element?" > >Overall I think this is on the right track. > >While in the fullness of time we want session persistence I think we need >to look carefully at what is needed to introduce multihoming when the >peers are not upgraded to use something new. I don't know if >that is what the question mark after "session persistence" on page 11. > >Drilling down into the "defining a new protocol element" set there >seems to be two classes: > - those that define a new namespace (HIP, SIM, ...) > - those that use an existing name space such as FQDNs (MAST, NOID, CB64, > ...) > >With that split in mind it seems odd to clumb together the proposals on page >13; SIM is much closer to HIP (with the biggest difference being that the >payload packets are not encrypted by SIM whereas HIP encrypts everything.) > >So understanding which proposals provide a new ID name space to applications >would be useful. > > Erik From owner-multi6@ops.ietf.org Tue Mar 2 02:55:33 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23900 for ; Tue, 2 Mar 2004 02:55:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ay4iP-000LjH-6A for multi6-data@psg.com; Tue, 02 Mar 2004 07:53:21 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Ay4iO-000Liu-1G for multi6@ops.ietf.org; Tue, 02 Mar 2004 07:53:20 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i227rdrq020320; Tue, 2 Mar 2004 08:53:39 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <6.0.1.1.2.20040302122144.01c94d38@localhost> References: <2C4F5D6C-67BA-11D8-997E-000A95CD987A@muada.com> <6.0.1.1.2.20040302122144.01c94d38@localhost> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Multi6 List From: Iljitsch van Beijnum Subject: Re: DRAFT of the architecture presentation for the WG session this week Date: Tue, 2 Mar 2004 08:53:16 +0100 To: Geoff Huston X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 2-mrt-04, at 2:32, Geoff Huston wrote: > In the interests of allowing everyone to come armed with the > appropriate weapons for this agenda topic, I've attached a PDF of the > current version of the draft. Geoff, is there any reason my two recent drafts (draft-van-beijnum-multi6-odt-00.txt and draft-van-beijnum-multi6-cbhi-00.txt, which isn't on Kurtis' list) aren't included in your analysis? From owner-multi6@ops.ietf.org Tue Mar 2 03:04:58 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24559 for ; Tue, 2 Mar 2004 03:04:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ay4sp-000PlN-Fx for multi6-data@psg.com; Tue, 02 Mar 2004 08:04:07 +0000 Received: from [212.68.5.99] (helo=n97.nomadiclab.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Ay4sn-000Phl-OB for multi6@ops.ietf.org; Tue, 02 Mar 2004 08:04:05 +0000 Received: from [127.0.0.1] (polle.local.nikander.com [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 942618; Tue, 2 Mar 2004 10:16:43 +0200 (EET) In-Reply-To: <6.0.1.1.2.20040302122144.01c94d38@localhost> References: <2C4F5D6C-67BA-11D8-997E-000A95CD987A@muada.com> <6.0.1.1.2.20040302122144.01c94d38@localhost> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2AE23D08-6C20-11D8-8A26-000393CE1E8C@nomadiclab.com> Content-Transfer-Encoding: 7bit Cc: Multi6 List From: Pekka Nikander Subject: Re: DRAFT of the architecture presentation for the WG session this week Date: Tue, 2 Mar 2004 17:04:02 +0900 To: Geoff Huston X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-3.8 required=5.0 tests=AWL,BAYES_00, NEW_DOMAIN_EXTENSIONS autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Geoff, Mostly as FYI but maybe useful for your presentation, below is a copy of a message that started a brief private discussion with Erik, Dave and some others in last October. It really considers only wedge approaches, but goes into some more detail than your current slides. Some of the information may already be stale, given that it is five months since this discussion. --Pekka Nikander I think that I am starting to see components. There are a couple of things that seem to be more or less ubiquitous over the various solutions: 1. A wedge layer between IP and the transport layers, translating IDs to locators and back. 2. A modified resolver library that returns IDs instead of locators. Then we seem to have a number of possible solutions that allow the recipient to map incoming packets on the right ID pairs: 3a. A new extension header that provides an ephemeral 32-bit ID that acts as a pointer to a specific ID pair. 3b. An ESP extension header that provides a 32-bit SPI that acts as a pointer to a specific ID pair. 3c. A single bit stolen from the IP header that indicates that the incoming locator pair must be mapped to an ID pair. 3d. Conceptually steal a bit in the IP header, but implement it with clever encoding. 3e. An implicit assumption that if two hosts communicate, they always communicate either with or without the new semantics. Hence, each incoming locator pair can be matched against known and cached locator pairs, and if a match is found, the locator pair can be mapped to an ID pair. 3a and 3b allow multiple IDs behind a single address. 3c, 3d and 3e do not. 3e does not allow locator rewriting by routers. So far I think that the solution space is pretty clear. Next we seem to reach muddier waters. We seem to need a method to prevent redirection attacks (both connection hijacking and flooding). 4a. Rely on some variant of return routability 4b. Rely on forward and reverse DNS. The next thing is the context creation protocol. This seems to require a 4-way handshake, consisting of a trigger, request, response, and confirm. What is noteworthy is that both TCP and SCTP can be piggybacked over this context creation, since neither TCP SYN nor SCTP INIT requires state to be created at the responder. There are multiple dimensions on how the context creation protocols differ. Time: 5a. The context is created immediately. 5b. Context creation may be delayed. Security strength of identifiers: 6a. The context is not associated with any strong identifier. 6b. The context is authenticated with a strong identifier. Actual mechanism: 7a. A simple tag is shared during context creation, and this tag is later used as a weak means of authentication. 7b. A simple secret is shared during context creation, and this secret is later used to authenticate changes to the context. 7c. A D-H protocol is run immediately, and the thereby created shared secret is used. 7d. A D-H protocol may be run later. 7e. A pair of hash chain anchors are exchanged during context creation, and the previous hashes from the hash chain are later used to authenticate changes to the context. From owner-multi6@ops.ietf.org Tue Mar 2 03:18:11 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25507 for ; Tue, 2 Mar 2004 03:18:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ay55X-00024x-Sc for multi6-data@psg.com; Tue, 02 Mar 2004 08:17:15 +0000 Received: from [218.37.229.253] (helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Ay55X-00024l-0m for multi6@ops.ietf.org; Tue, 02 Mar 2004 08:17:15 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id B29303023BF; Tue, 2 Mar 2004 09:17:32 +0100 (CET) In-Reply-To: References: <2C4F5D6C-67BA-11D8-997E-000A95CD987A@muada.com> <6.0.1.1.2.20040302122144.01c94d38@localhost> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=fixed Message-Id: <0A2C3984-6C22-11D8-B4D0-000A95928574@kurtis.pp.se> Content-Transfer-Encoding: 7bit Cc: Multi6 List , Geoff Huston From: Kurt Erik Lindqvist Subject: Re: DRAFT of the architecture presentation for the WG session this week Date: Tue, 2 Mar 2004 09:17:26 +0100 To: Iljitsch van Beijnum X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-03-02, at 08.53, Iljitsch van Beijnum wrote: > On 2-mrt-04, at 2:32, Geoff Huston wrote: > >> In the interests of allowing everyone to come armed with the >> appropriate weapons for this agenda topic, I've attached a PDF of the >> current version of the draft. > > Geoff, is there any reason my two recent drafts > (draft-van-beijnum-multi6-odt-00.txt and > draft-van-beijnum-multi6-cbhi-00.txt, which isn't on Kurtis' list) > aren't included in your analysis? They are now...(I knew I had missed some...) - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQERDG6arNKXTPFCVEQKDWACg2oj318A+T50p9daxYrP63jf/RnMAoMh7 hD5PxX/kAckgRZ4el00o80EM =s3Ez -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Tue Mar 2 03:37:36 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26296 for ; Tue, 2 Mar 2004 03:37:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ay5Nx-0005Db-QD for multi6-data@psg.com; Tue, 02 Mar 2004 08:36:17 +0000 Received: from [203.50.0.6] (helo=kahuna.telstra.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Ay5Nw-0005DF-HU for multi6@ops.ietf.org; Tue, 02 Mar 2004 08:36:16 +0000 Received: from gih505.telstra.net (kahuna.telstra.net [203.50.0.6]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id i228ZsuX068262; Tue, 2 Mar 2004 19:36:03 +1100 (EST) (envelope-from gih@telstra.net) Message-Id: <6.0.1.1.2.20040302191738.01bf0440@localhost> X-Sender: gih@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Tue, 02 Mar 2004 19:20:06 +1100 To: Iljitsch van Beijnum From: Geoff Huston Subject: Re: DRAFT of the architecture presentation for the WG session this week Cc: Multi6 List In-Reply-To: References: <2C4F5D6C-67BA-11D8-997E-000A95CD987A@muada.com> <6.0.1.1.2.20040302122144.01c94d38@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk The use of specific proposals is as examples in the context of the presentation, as they are intended to be examples of the various styles of approach. This was to constrain the length of time for the presentation as a more exhaustive enumeration in the presentation would not really add an awful lot to the taxonomy but would take a lot of time. As I understand the overall plan the to-be-written-document would attempt to analyse all the proposals using this architectural taxonomy, regards, Geoff At 06:53 PM 2/03/2004, Iljitsch van Beijnum wrote: >On 2-mrt-04, at 2:32, Geoff Huston wrote: > >>In the interests of allowing everyone to come armed with the appropriate >>weapons for this agenda topic, I've attached a PDF of the current version >>of the draft. > >Geoff, is there any reason my two recent drafts >(draft-van-beijnum-multi6-odt-00.txt and >draft-van-beijnum-multi6-cbhi-00.txt, which isn't on Kurtis' list) aren't >included in your analysis? From owner-multi6@ops.ietf.org Tue Mar 2 08:55:18 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10086 for ; Tue, 2 Mar 2004 08:55:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AyAJx-000EcY-DC for multi6-data@psg.com; Tue, 02 Mar 2004 13:52:29 +0000 Received: from [195.212.29.155] (helo=mtagate6.de.ibm.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AyAJv-000EcM-6o for multi6@ops.ietf.org; Tue, 02 Mar 2004 13:52:27 +0000 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by mtagate6.de.ibm.com (8.12.10/8.12.10) with ESMTP id i22DqLJW083254; Tue, 2 Mar 2004 13:52:21 GMT Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay02.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i22DqMEY268998; Tue, 2 Mar 2004 14:52:22 +0100 Received: from zurich.ibm.com (sig-9-145-139-114.de.ibm.com [9.145.139.114]) by collon.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id OAA48974; Tue, 2 Mar 2004 14:52:17 +0100 Message-ID: <404491B3.B45EAD40@zurich.ibm.com> Date: Tue, 02 Mar 2004 14:52:51 +0100 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: Noel Chiappa CC: multi6@ops.ietf.org Subject: Re: draft-savola-multi6-asn-pi-01.txt References: <20040301192854.8CF2186AF0@mercury.lcs.mit.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit below... Noel Chiappa wrote: > > > From: Brian E Carpenter > > >> If people want a namespace which *doesn't* have those properties, > >> because they find those properties *inconvenient*, then they can get > >> off their tailbones and add one. > > > As a matter of fact, this is today's practice. The trouble is, that in > > order to preserve a rational and uniform *internal* addressing plan, it > > is achieved by using NAT at each ISP access point. > > In light of my immediately preceeding comment, this seems to me to be an > obvious sign that we have too few namespaces *in the current system*. > > > The tricky bit is to achieve the same effect without NAT and without > > horrendous address administration busy-work. > > Were such another namespace (e.g of host ID's) available, so that the > routing-names of these machines would be less "interesting" (and possibly > assigned automatically, e.g. by concatenating an "interface ID" with the > routing-name of the physical network they connect to - and yes, I know > there's lots of other needed springs and gears, like getting those addresses > into something like the DNS), do you think we would not see this focus on the > routing-names? > > In other words, is the situation you describe (where people have one > addressing scheme internally, and another externally, with NAT to map between > them) caused precisely by having too few name-spaces - or would the same > thing happen even if we also have an additional namespace of host identifiers? This is a very good question. My feeling is that it's caused by today's overloading of an address as both a locator and as an identifier - so a solution such as NOID seems to avoid the problem without forcing us to create a truly independent name space. And since NOID would in practice allow locator-addresses to be chosen topologically, and identifier-addresses to be chosen arbitrarily, I think it's a proof-of-concept that with two namespaces (even if they are multiplexed out of a single address space) we can evade the topological argument for NAT. > > If the latter, that's something I'd like to understand - because clearly, > unless the system as a whole somehow provides whatever it is that people > think they need here, they will continue to use NAT boxes... Well, if we dispose of the topological argument for NAT, there are still others to be disposed of in turn. But I don't think that argument belongs here. Brian From owner-multi6@ops.ietf.org Tue Mar 2 10:30:21 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15162 for ; Tue, 2 Mar 2004 10:30:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AyBpK-0005mQ-7c for multi6-data@psg.com; Tue, 02 Mar 2004 15:28:58 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.30; FreeBSD) id 1AyBpG-0005m1-Hu for multi6@ops.ietf.org; Tue, 02 Mar 2004 15:28:55 +0000 Received: (qmail 41521 invoked from network); 2 Mar 2004 15:28:19 -0000 Received: from unknown (HELO necom830.hpcl.titech.ac.jp) (210.93.162.110) by necom830.hpcl.titech.ac.jp with SMTP; 2 Mar 2004 15:28:19 -0000 Message-ID: <4044A897.3080903@necom830.hpcl.titech.ac.jp> Date: Wed, 03 Mar 2004 00:30:31 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Geoff Huston CC: Iljitsch van Beijnum , Multi6 List Subject: Re: DRAFT of the architecture presentation for the WG session this week References: <2C4F5D6C-67BA-11D8-997E-000A95CD987A@muada.com> <6.0.1.1.2.20040302122144.01c94d38@localhost> <6.0.1.1.2.20040302191738.01bf0440@localhost> In-Reply-To: <6.0.1.1.2.20040302191738.01bf0440@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_RFCI autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Geoff; > The use of specific proposals is as examples in the context of the > presentation, > as they are intended to be examples of the various styles of approach. > This was to constrain the length of time for the presentation as a more > exhaustive enumeration in the presentation would not really add an > awful lot to the taxonomy but would take a lot of time. Wrong. The proper way to let your classification understood by people submitting their proposals is to classify their proposals. It can also act as an evidense that you do read and understand the proposals. Do that. > As I understand the overall plan the to-be-written-document would attempt > to analyse all the proposals using this architectural taxonomy, I already showed that your taxonomy is no good for architectural discussions. If you disagree, classify 8plus8 proposal after reading section 4.3 of the proposal. Masataka Ohta From owner-multi6@ops.ietf.org Tue Mar 2 19:12:02 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11696 for ; Tue, 2 Mar 2004 19:12:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AyJxJ-000NlH-VT for multi6-data@psg.com; Wed, 03 Mar 2004 00:09:45 +0000 Received: from [140.239.227.17] (helo=portal.hamachi.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AyJxG-000Nkz-La for multi6@ops.ietf.org; Wed, 03 Mar 2004 00:09:42 +0000 Received: from unknown.hamachi.org (localhost [127.0.0.1]) by portal.hamachi.org (Postfix) with ESMTP id 4E78317921; Tue, 2 Mar 2004 19:09:40 -0500 (EST) Received: from unknown.hamachi.org (sommerfeld@localhost) by unknown.hamachi.org (8.12.5+Sun/8.8.8) with ESMTP id i22NwPxm016558; Wed, 3 Mar 2004 08:58:25 +0900 (JST) Message-Id: <200403022358.i22NwPxm016558@unknown.hamachi.org> From: Bill Sommerfeld To: Pekka Nikander Cc: Geoff Huston , Multi6 List Subject: Re: DRAFT of the architecture presentation for the WG session this week In-Reply-To: Message from Pekka Nikander of "Tue, 02 Mar 2004 17:04:02 +0900." <2AE23D08-6C20-11D8-8A26-000393CE1E8C@nomadiclab.com> Reply-To: sommerfeld@orchard.arlington.ma.us Date: Wed, 03 Mar 2004 08:58:24 +0900 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk > What is noteworthy is that both TCP and SCTP can be > piggybacked over this context creation, since neither TCP SYN > nor SCTP INIT requires state to be created at the responder. This is a common assertion but it is factually incorrect with respect to TCP. If the 3rd packet of the 3-way handshake is lost, *and* the application protocol is one in which the server is the first to send data (e.g., a connection banner), the client will move the connection to ESTABLISHED state and quietly hang waiting for data to arrive, while the server will have no record of the connection.... The SYN-ACK must be retransmitted if not acked. - Bill From owner-multi6@ops.ietf.org Tue Mar 2 20:04:01 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15991 for ; Tue, 2 Mar 2004 20:04:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AyKmo-0008tD-54 for multi6-data@psg.com; Wed, 03 Mar 2004 01:02:58 +0000 Received: from [66.35.230.237] (helo=smtp02-w.exodus.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AyKmn-0008sy-6V for multi6@ops.ietf.org; Wed, 03 Mar 2004 01:02:57 +0000 Received: from ms101.mail1.com (ms101.mail1.com [209.1.5.174]) by smtp02-w.exodus.net (8.12.8/8.12.8) with ESMTP id i22MBbEv027095 for ; Tue, 2 Mar 2004 16:11:38 -0600 Received: from [172.16.27.253] (unverified [218.37.224.104]) by accounting.espmail.com (Rockliffe SMTPRA 5.2.5) with ESMTP id for ; Tue, 2 Mar 2004 17:02:56 -0800 Mime-Version: 1.0 X-Sender: margaret@thingmagic.com@ms101.mail1.com Message-Id: Date: Tue, 2 Mar 2004 19:58:43 -0500 To: multi6@ops.ietf.org From: Margaret Wasserman Subject: Comments on WIMP and MTU Handling Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk As I just discussed at the meeting mic, some of the multi6 proposals that involve a mid-Internet layer wedge (including WIMP and NOID) have an issue with IP fragmentation and reassembly. If an ID/Loc layer will exist conceptually below the fragmentation/reassembly function, it is problematic for it to add optional bytes to the packet (such as a header or IP option that may or may not be included). There are some possibilities for dealing with this: - Run the ID/Loc separation between the Network and Transport layers instead. - Reduce the MTU presented to upper layers, so that there is always room for the optional header. If you choose the second option, though, there is no advantage to mechanisms that try to avoid the need to add a header (such as the special next header values used in NOID). WIMP also adds another twist on this problem by forbidding fragmentation of packets that contain WIMP headers. There is no indication of how/if the upper layers will cooperate to make this possible, or what impacts this requirement might have on Path MTU discovery. Margaret From owner-multi6@ops.ietf.org Tue Mar 2 20:43:45 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19135 for ; Tue, 2 Mar 2004 20:43:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AyLOq-000H4f-4T for multi6-data@psg.com; Wed, 03 Mar 2004 01:42:16 +0000 Received: from [204.127.202.64] (helo=sccrmhc13.comcast.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AyLOo-000H4N-V8 for multi6@ops.ietf.org; Wed, 03 Mar 2004 01:42:15 +0000 Received: from dfnjgl21 (dfnjgl21.wireless.ietf59.or.kr[218.37.225.240]) by comcast.net (sccrmhc13) with SMTP id <20040303014213016000373je> (Authid: sdawkins@comcast.net); Wed, 3 Mar 2004 01:42:14 +0000 Message-ID: <03ce01c400c0$c31b17b0$f0e125da@DFNJGL21> Reply-To: "Spencer Dawkins" From: "Spencer Dawkins" To: "Multi6 Mailing List" References: Subject: Re: Comments on WIMP and MTU Handling Date: Wed, 3 Mar 2004 10:42:14 +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.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Exactly - as if we needed application interaction for multi6, like you had for ipv6 itself... Spencer ----- Original Message ----- From: "Margaret Wasserman" To: Sent: Wednesday, March 03, 2004 9:58 AM Subject: Comments on WIMP and MTU Handling > > As I just discussed at the meeting mic, some of the multi6 proposals > that involve a mid-Internet layer wedge (including WIMP and NOID) > have an issue with IP fragmentation and reassembly. If an ID/Loc > layer will exist conceptually below the fragmentation/reassembly > function, it is problematic for it to add optional bytes to the > packet (such as a header or IP option that may or may not be > included). There are some possibilities for dealing with this: > > - Run the ID/Loc separation between the Network and Transport > layers instead. > - Reduce the MTU presented to upper layers, so that there is > always room for the optional header. > > If you choose the second option, though, there is no advantage to > mechanisms that try to avoid the need to add a header (such as the > special next header values used in NOID). > > WIMP also adds another twist on this problem by forbidding > fragmentation of packets that contain WIMP headers. There is no > indication of how/if the upper layers will cooperate to make this > possible, or what impacts this requirement might have on Path MTU > discovery. > > Margaret > > > From owner-multi6@ops.ietf.org Tue Mar 2 21:36:57 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22521 for ; Tue, 2 Mar 2004 21:36:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AyMF3-0002Rq-A0 for multi6-data@psg.com; Wed, 03 Mar 2004 02:36:13 +0000 Received: from [131.228.20.27] (helo=mgw-x4.nokia.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AyMF2-0002RL-50 for multi6@ops.ietf.org; Wed, 03 Mar 2004 02:36:12 +0000 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i232aAC08514 for ; Wed, 3 Mar 2004 04:36:10 +0200 (EET) X-Scanned: Wed, 3 Mar 2004 04:35:59 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i232Zx1O003307 for ; Wed, 3 Mar 2004 04:35:59 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00szVJfP; Wed, 03 Mar 2004 04:35:58 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i232Zw725386 for ; Wed, 3 Mar 2004 04:35:58 +0200 (EET) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 3 Mar 2004 04:35:58 +0200 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: on the point of mobility & multihoming Date: Wed, 3 Mar 2004 04:35:57 +0200 Message-ID: Thread-Topic: Comments on WIMP and MTU Handling thread-index: AcQAu58OPBdxtAPRRaO/ashLI/qD7wAC/LEg From: To: X-OriginalArrivalTime: 03 Mar 2004 02:35:58.0483 (UTC) FILETIME=[42A5AE30:01C400C8] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.4 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable From today's session, Dave & Geoff discussed multihoming vs. mobility. = In a working group I chair, we've had similar discussions and from a = transport layer, maintaining a session during a multihoming change and a mobility = change can be quite similar. I second Dave's comment that trying to solve two things at once can be never-ending. He also mentioned that solving two problems seperately can lead to incompatible or extremely complex = solutions that don't interoperate well. Could we restrict ourselves to = multihoming, but perhaps the authors of the proposals add a section on Mobility = Considerations, so we don't run into incompatiple solutions? thanks, John From owner-multi6@ops.ietf.org Tue Mar 2 22:10:13 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24411 for ; Tue, 2 Mar 2004 22:10:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AyMl8-0009RE-ID for multi6-data@psg.com; Wed, 03 Mar 2004 03:09:22 +0000 Received: from [131.228.20.26] (helo=mgw-x3.nokia.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AyMl7-0009Qt-FI for multi6@ops.ietf.org; Wed, 03 Mar 2004 03:09:21 +0000 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2339JS27566 for ; Wed, 3 Mar 2004 05:09:19 +0200 (EET) X-Scanned: Wed, 3 Mar 2004 05:09:16 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i2339Glq013305 for ; Wed, 3 Mar 2004 05:09:16 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00dugzmK; Wed, 03 Mar 2004 05:08:54 EET Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2338r710328 for ; Wed, 3 Mar 2004 05:08:53 +0200 (EET) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 3 Mar 2004 05:08:51 +0200 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: SCTP Multihoming experiences Date: Wed, 3 Mar 2004 05:08:50 +0200 Message-ID: Thread-Topic: Comments on WIMP and MTU Handling thread-index: AcQAu58OPBdxtAPRRaO/ashLI/qD7wAC/LEgAAE595A= From: To: X-OriginalArrivalTime: 03 Mar 2004 03:08:51.0368 (UTC) FILETIME=[DA940A80:01C400CC] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.4 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi all, Since this is in the OPS area, does the working think that writing up = some information on operation experiences gained in the use / deployment of SCTP? Erik = Nordmark mentioned that SCTP is interesting because it has some deployment. I = also know that there is a pretty decent NS2 implementation of it as well. Lode & = I could pull together some info on this. This may help with other proposals as = well. John From owner-multi6@ops.ietf.org Tue Mar 2 23:00:19 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27432 for ; Tue, 2 Mar 2004 23:00:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AyNX7-000HNQ-3A for multi6-data@psg.com; Wed, 03 Mar 2004 03:58:57 +0000 Received: from [203.50.0.6] (helo=kahuna.telstra.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AyNX5-000HND-IZ for multi6@ops.ietf.org; Wed, 03 Mar 2004 03:58:55 +0000 Received: from gih505.telstra.net (kahuna.telstra.net [203.50.0.6]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id i233wbua070093 for ; Wed, 3 Mar 2004 14:58:53 +1100 (EST) (envelope-from gih@telstra.net) Message-Id: <6.0.1.1.2.20040303145646.01dd7758@localhost> X-Sender: gih@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Wed, 03 Mar 2004 14:58:05 +1100 To: multi6@ops.ietf.org From: Geoff Huston Subject: My slide pack as presented to the WG session today in Seoul (architectural taxonomy) In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk http://www.potaroo.net/presentations/multi6-arch.pdf regards, Geoff From owner-multi6@ops.ietf.org Wed Mar 3 00:01:56 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01165 for ; Wed, 3 Mar 2004 00:01:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AyOUU-0001cK-FN for multi6-data@psg.com; Wed, 03 Mar 2004 05:00:18 +0000 Received: from [218.37.226.186] (helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AyOUL-0001WQ-C4 for multi6@ops.ietf.org; Wed, 03 Mar 2004 05:00:09 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id 2C2FC305886; Wed, 3 Mar 2004 06:00:28 +0100 (CET) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=fixed Message-Id: Content-Transfer-Encoding: 7bit Cc: From: Kurt Erik Lindqvist Subject: Re: on the point of mobility & multihoming Date: Wed, 3 Mar 2004 06:00:19 +0100 To: X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 (chair hat off) John, I would argue the same. I think that it's to early on in the process in order to try and think of overlaps or additional usage for the proposals. I would like to argue that we solve this step by step and concentrate on the multihoming approach. The mobility aspect is a "nice to have", but let's look at that later on. Best regards, - - kurtis - On 2004-03-03, at 03.35, wrote: > From today's session, Dave & Geoff discussed multihoming vs. mobility. > In > a working group I chair, we've had similar discussions and from a > transport > layer, maintaining a session during a multihoming change and a > mobility change > can be quite similar. I second Dave's comment that trying to solve two > things at once can be never-ending. He also mentioned that solving two > problems seperately can lead to incompatible or extremely complex > solutions > that don't interoperate well. Could we restrict ourselves to > multihoming, > but perhaps the authors of the proposals add a section on Mobility > Considerations, > so we don't run into incompatiple solutions? > > thanks, > John > -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQEVmaKarNKXTPFCVEQJK4gCdFicVP+wvkhoaYXAlC7LRASTX80IAoMo7 yDY9zay7lsMEGPsoPNe6de4d =bLTs -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Wed Mar 3 00:02:18 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01206 for ; Wed, 3 Mar 2004 00:02:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AyOVj-0001vK-WB for multi6-data@psg.com; Wed, 03 Mar 2004 05:01:35 +0000 Received: from [218.37.226.186] (helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AyOVb-0001uD-3R for multi6@ops.ietf.org; Wed, 03 Mar 2004 05:01:27 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id AF2113058B7; Wed, 3 Mar 2004 06:01:46 +0100 (CET) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=fixed Message-Id: Content-Transfer-Encoding: 7bit Cc: From: Kurt Erik Lindqvist Subject: Re: SCTP Multihoming experiences Date: Wed, 3 Mar 2004 06:01:42 +0100 To: X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 John, On 2004-03-03, at 04.08, wrote: > Hi all, > > Since this is in the OPS area, does the working think that writing up > some information > on operation experiences gained in the use / deployment of SCTP? Erik > Nordmark > mentioned that SCTP is interesting because it has some deployment. I > also know > that there is a pretty decent NS2 implementation of it as well. Lode > & I could > pull together some info on this. This may help with other proposals as > well. I do think that operational experiences from SCPT would be interesting even without multi6. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQEVmuaarNKXTPFCVEQKYTwCg9GGU8T52WVvDFvhX5wfprqCZfj8An0T1 QknIiYkqPYFDYqzo0WZnOHZR =/u5w -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Wed Mar 3 00:08:19 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01594 for ; Wed, 3 Mar 2004 00:08:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AyObY-0009ye-09 for multi6-data@psg.com; Wed, 03 Mar 2004 05:07:36 +0000 Received: from [163.117.136.121] (helo=smtp01.uc3m.es) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AyObU-0009ay-C1 for multi6@ops.ietf.org; Wed, 03 Mar 2004 05:07:32 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 7902B108C0; Wed, 3 Mar 2004 06:07:31 +0100 (CET) Received: from lolo (vpn-252-215.uc3m.es [163.117.252.215]) by smtp01.uc3m.es (Postfix) with SMTP id 9DCDB108BF; Wed, 3 Mar 2004 06:07:29 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Margaret Wasserman" , Subject: RE: Comments on WIMP and MTU Handling Date: Wed, 3 Mar 2004 14:05:26 +0900 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) x-mimeole: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Margaret, [...] > If you choose the second option, though, there is no advantage to > mechanisms that try to avoid the need to add a header (such as the > special next header values used in NOID). I am not sure i understand this argument... i mean, if you present a reduced mtu to the upper layers, but the additional header is not included, you are actually sending less bytes, which means that you are consuming less bandwidth, so others can use it. so i do see a benefit on this approach, since you are saving some bandwidth am i missing something? regards, marcelo From owner-multi6@ops.ietf.org Wed Mar 3 00:19:48 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02157 for ; Wed, 3 Mar 2004 00:19:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AyOn6-000Hae-UA for multi6-data@psg.com; Wed, 03 Mar 2004 05:19:32 +0000 Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AyOn5-000HaS-Ua for multi6@ops.ietf.org; Wed, 03 Mar 2004 05:19:31 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i235JSi5004531; Tue, 2 Mar 2004 22:19:29 -0700 (MST) Received: from bobo (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i235JPQ19026; Wed, 3 Mar 2004 06:19:25 +0100 (MET) Date: Tue, 2 Mar 2004 21:19:28 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: draft-savola-multi6-asn-pi-01.txt To: Brian E Carpenter Cc: Noel Chiappa , multi6@ops.ietf.org In-Reply-To: "Your message with ID" <404491B3.B45EAD40@zurich.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk > > In other words, is the situation you describe (where people have one > > addressing scheme internally, and another externally, with NAT to map between > > them) caused precisely by having too few name-spaces - or would the same > > thing happen even if we also have an additional namespace of host identifiers? > > This is a very good question. My feeling is that it's caused by today's > overloading of an address as both a locator and as an identifier - so > a solution such as NOID seems to avoid the problem without forcing us > to create a truly independent name space. And since NOID would in practice > allow locator-addresses to be chosen topologically, and identifier-addresses > to be chosen arbitrarily, I think it's a proof-of-concept that with > two namespaces (even if they are multiplexed out of a single address space) > we can evade the topological argument for NAT. Isn't there an issue about needing to support N global locators (used for external communication) plus at least one local locator? In the case of NOID, would it make sense to store the local locator together with the global locators in the (global) DNS? If you can't put them in the same lookup service, then you need some mechanism to (securely) discover locators that are not in the lookup service. (As an aside, if you have such a mechanism you could also use it to share care-of addresses with your peer when being mobile.) But I haven't found a way to do this with acceptable security in a scheme like NOID. I was hoping that the hash chains in WIMP could be used for this in NOID, but I think Jari convinced me that this has problems. It can be done securely when there is a new namespace as in HIP, SIM, etc. Erik From owner-multi6@ops.ietf.org Wed Mar 3 00:20:54 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02233 for ; Wed, 3 Mar 2004 00:20:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AyOoK-000HmF-Tx for multi6-data@psg.com; Wed, 03 Mar 2004 05:20:48 +0000 Received: from [140.239.227.17] (helo=portal.hamachi.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AyOoK-000Hlt-0Z for multi6@ops.ietf.org; Wed, 03 Mar 2004 05:20:48 +0000 Received: from unknown.hamachi.org (localhost [127.0.0.1]) by portal.hamachi.org (Postfix) with ESMTP id A0F5017921; Wed, 3 Mar 2004 00:20:46 -0500 (EST) Received: from unknown.hamachi.org (sommerfeld@localhost) by unknown.hamachi.org (8.12.5+Sun/8.8.8) with ESMTP id i235IQMR018375; Wed, 3 Mar 2004 14:18:26 +0900 (JST) Message-Id: <200403030518.i235IQMR018375@unknown.hamachi.org> From: Bill Sommerfeld To: mbagnulo@ing.uc3m.es Cc: "Margaret Wasserman" , multi6@ops.ietf.org Subject: Re: Comments on WIMP and MTU Handling In-Reply-To: Message from "marcelo bagnulo" of "Wed, 03 Mar 2004 14:05:26 +0900." Reply-To: sommerfeld@orchard.arlington.ma.us Date: Wed, 03 Mar 2004 14:18:25 +0900 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk > i mean, if you present a reduced mtu to the upper layers, but the additional > header is not included, you are actually sending less bytes, which means > that you are consuming less bandwidth, so others can use it. huh? if you shrink the MTU, you're putting more of your available link capacity into packet headers because you now need more packets to carry a given payload. - Bill From owner-multi6@ops.ietf.org Wed Mar 3 00:29:13 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02666 for ; Wed, 3 Mar 2004 00:29:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AyOwL-000J7w-Cf for multi6-data@psg.com; Wed, 03 Mar 2004 05:29:05 +0000 Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AyOwK-000J7i-Ip for multi6@ops.ietf.org; Wed, 03 Mar 2004 05:29:04 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i235T2i5007610 for ; Tue, 2 Mar 2004 22:29:03 -0700 (MST) Received: from bobo (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i235T0Q19219 for ; Wed, 3 Mar 2004 06:29:00 +0100 (MET) Date: Tue, 2 Mar 2004 21:29:03 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Source address selection insufficient? To: multi6@ops.ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk When reading draft-huitema-multi6-hosts-03.txt (which is good because it works out enough details to raise questions) I wonder if address selection can solve ingress filtering. Taking the canonical picture from the draft /-- ( A ) ---( ) --- ( C ) --\ X (site X) ( IPv6 ) (Site Y) Y \-- ( B ) ---( ) --- ( D ) --/ This has 4 locator pairs: A:X-C:Y A:X-D:Y B:X-C:Y B:X-D:Y The set of locator pairs that work when sending out from site X might be A:X-C:Y and B:X-D:Y but the set of locator pairs that work when sending from site Y might be the other two: A:X-D:Y and B:X-C:Y. Thus the intersection of the two ingress filtering constraints is the empty set. This can happen due to normal routing as far as I can tell. The constraints for X appear if X routes packet to C out through A and packets to D out through B. The constraints for Y appear if Y routes packets to A out through D and packets to B out through C. Am I missing something? If the above is true it seems like we need something other than source address selection (relaxed filtering, source-based routing, or locator rewriting). Erik From owner-multi6@ops.ietf.org Wed Mar 3 00:43:30 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03460 for ; Wed, 3 Mar 2004 00:43:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AyP9y-000M8w-E9 for multi6-data@psg.com; Wed, 03 Mar 2004 05:43:10 +0000 Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AyP9x-000M8f-Es for multi6@ops.ietf.org; Wed, 03 Mar 2004 05:43:09 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i235h7i5012425; Tue, 2 Mar 2004 22:43:08 -0700 (MST) Received: from bobo (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i235h4Q23338; Wed, 3 Mar 2004 06:43:05 +0100 (MET) Date: Tue, 2 Mar 2004 21:43:08 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Comments on WIMP and MTU Handling To: Margaret Wasserman Cc: multi6@ops.ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk > - Run the ID/Loc separation between the Network and Transport > layers instead. > - Reduce the MTU presented to upper layers, so that there is > always room for the optional header. > > If you choose the second option, though, there is no advantage to > mechanisms that try to avoid the need to add a header (such as the > special next header values used in NOID). If I understand you correctly the issue appears when the shim adds different amount of headers depending on its state. For instance, in the NOID case it would add bytes to the packet when establishing the host-pair context state but once that state is established there are no bytes added. One can view this as an artifact of the piggybacking of the ULP messages on the state establishment protocol. There are multiple approaches to this that do not require moving the shim above fragmentation: - Make the piggybacking dynamic. If the ULP message plus the shim message fit in one packet do the piggybacking. Otherwise send two separate packets. (If the context is created due to a TCP open exchange this will piggyback since the SYN packets are small.) - Make the interface between the transports and IP handle more dynamic MTUs. The transport packetization could ask IP "how large packet can I send now" where the answer is a function of the state of the host-pair context in the shim layer. - As you suggest, lower the MTU that the transport sets to take into account the maximum amount of shim-layer header that might be added by the shim. But this is more pessimistic than the above two choices. Erik From owner-multi6@ops.ietf.org Wed Mar 3 01:13:57 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05500 for ; Wed, 3 Mar 2004 01:13:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AyPcj-0001vB-W0 for multi6-data@psg.com; Wed, 03 Mar 2004 06:12:53 +0000 Received: from [208.184.79.7] (helo=joy.songbird.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AyPcg-0001uk-Rh for multi6@ops.ietf.org; Wed, 03 Mar 2004 06:12:50 +0000 Received: from BBFUJIP.brandenburg.com (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i236Ldd13134; Tue, 2 Mar 2004 22:21:39 -0800 Date: Wed, 3 Mar 2004 15:12:44 +0900 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <581566651.20040303151244@brandenburg.com> To: multi6@ops.ietf.org CC: Geoff Huston Subject: Wedge between transport and ULP MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-3.7 required=5.0 tests=AWL,BAYES_00,PRIORITY_NO_NAME autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Folks, Geoff mention an architectural choice that is not currently represented by any proposals. It places a multiaddressing wedge layer between the transport layer and the applications layer. Some MAST discussions explored this issue a bit, as did early BEEP discussions. For what they are worth, here are some observations: The wedge fits rather nicely into that realm the OSI folks like to call 'session layer'. Things put at that layer tend to need to replicate control (eg, reliability) mechanisms already done in transport. This will be particularly true if the layer is expected to work across multiple transport associations. Pekka N. noted the compelling requirement for having transport state NOT cross machine boundaries. This suggests that the kind of multiaddressing being discussed here belongs no higher than the bottom of transport. An application that wants to exists as a single logical entity, but live across more than one machine, needs something like a session-level multiaddressing feature. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-multi6@ops.ietf.org Wed Mar 3 01:43:10 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06230 for ; Wed, 3 Mar 2004 01:43:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AyQ5Y-0006az-Qi for multi6-data@psg.com; Wed, 03 Mar 2004 06:42:40 +0000 Received: from [131.107.3.124] (helo=mail2.microsoft.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AyQ5X-0006an-9d for multi6@ops.ietf.org; Wed, 03 Mar 2004 06:42:39 +0000 Received: from mail6.microsoft.com ([157.54.6.196]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Tue, 2 Mar 2004 22:42:31 -0800 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 2 Mar 2004 22:42:37 -0800 Received: from 157.54.8.155 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 02 Mar 2004 22:42:37 -0800 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 2 Mar 2004 22:42:36 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 2 Mar 2004 22:42:48 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 2 Mar 2004 22:42:13 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7165.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Source address selection insufficient? Date: Tue, 2 Mar 2004 22:42:31 -0800 Message-ID: Thread-Topic: Source address selection insufficient? thread-index: AcQA4Lin8lZ1CylhTD24ZXNBY1q6CAAB/kwQ From: "Christian Huitema" To: "Erik Nordmark" , X-OriginalArrivalTime: 03 Mar 2004 06:42:13.0141 (UTC) FILETIME=[A9079450:01C400EA] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > When reading draft-huitema-multi6-hosts-03.txt (which is good because > it works out enough details to raise questions) I wonder > if address selection can solve ingress filtering. >=20 > Taking the canonical picture from the draft > /-- ( A ) ---( ) --- ( C ) --\ > X (site X) ( IPv6 ) (Site Y) Y > \-- ( B ) ---( ) --- ( D ) --/ >=20 > This has 4 locator pairs: > A:X-C:Y > A:X-D:Y > B:X-C:Y > B:X-D:Y >=20 > The set of locator pairs that work when sending out from site X > might be A:X-C:Y and B:X-D:Y > but the set of locator pairs that work when sending from site Y might > be the other two: A:X-D:Y and B:X-C:Y. >=20 > Thus the intersection of the two ingress filtering constraints is the > empty set. Correct. If the only thing you do is try the four pairs, it may happen that no pair works. It is somewhat unlikely in practice, since sites tend to have a "default" provider, and the pair default-default ends up working. But it is definitely a possibility, in a "shoot your-self in the foot" kind of way. > If the above is true it seems like we need something other than > source address selection (relaxed filtering, source-based routing, > or locator rewriting). Locator rewriting supposes that both sites (X and Y) cooperate. If that is the case, you can also implement an end-to-end solution, e.g. X sends "A:X-C:Y", Y replies A:X-D:Y, and both decide to agree on the result. Relaxed filtering and source-based routing are "local" solutions: they make no hypothesis on the behavior of the remote site. Relaxed filtering is by far the simplest solution for the site. It would "just work". It is probably the solution of choice for sites of any significant size. Note that in the example it is sufficient to relax ingress filtering on one of the provider links to eliminate the "double ingress failure". One can easily imagine a medium-size making "relaxed filtering" a condition for buying service from a second provider. Source based routing is trivial to implement in single-subnet sites. -- Christian Huitema From owner-multi6@ops.ietf.org Wed Mar 3 02:11:24 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20404 for ; Wed, 3 Mar 2004 02:11:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AyQWY-000Brm-95 for multi6-data@psg.com; Wed, 03 Mar 2004 07:10:34 +0000 Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AyQWX-000BrJ-Ac for multi6@ops.ietf.org; Wed, 03 Mar 2004 07:10:33 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i237AVi5016691; Wed, 3 Mar 2004 00:10:31 -0700 (MST) Received: from bobo (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i237AQQ28698; Wed, 3 Mar 2004 08:10:27 +0100 (MET) Date: Tue, 2 Mar 2004 23:10:30 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: Source address selection insufficient? To: Christian Huitema Cc: Erik Nordmark , multi6@ops.ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk > Correct. If the only thing you do is try the four pairs, it may happen > that no pair works. It is somewhat unlikely in practice, since sites > tend to have a "default" provider, and the pair default-default ends up > working. But it is definitely a possibility, in a "shoot your-self in > the foot" kind of way. Does this mean that we can remove the two solutions in your draft (solution 2 and 7) which use source address selection as the means to avoid ingress filtering issues? > Locator rewriting supposes that both sites (X and Y) cooperate. If that > is the case, you can also implement an end-to-end solution, e.g. X sends > "A:X-C:Y", Y replies A:X-D:Y, and both decide to agree on the result. Not only that - it also assumes that the peer host has been modified to be able to handle locators that are rewritten. Thus it would take longer to deploy etc. etc. > Relaxed filtering and source-based routing are "local" solutions: they > make no hypothesis on the behavior of the remote site. Agreed. > Source based routing is trivial to implement in single-subnet sites. Yep. But it becomes a lot more complex as the site grows. If we decide that source-based routing only applies to a subset of the sites, e.g. due to large sites being able to use relaxed filtering, then the incentive for wide-spread implementation of these more complex techniques might be a challenge. Erik From owner-multi6@ops.ietf.org Wed Mar 3 02:39:46 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07379 for ; Wed, 3 Mar 2004 02:39:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AyQxg-000GVm-AK for multi6-data@psg.com; Wed, 03 Mar 2004 07:38:36 +0000 Received: from [131.107.3.122] (helo=mail4.microsoft.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AyQxf-000GVZ-8J for multi6@ops.ietf.org; Wed, 03 Mar 2004 07:38:35 +0000 Received: from mail5.microsoft.com ([157.54.6.156]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 2 Mar 2004 23:38:42 -0800 Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(6.0.3790.1039); Tue, 2 Mar 2004 23:38:20 -0800 Received: from 157.54.8.155 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 02 Mar 2004 23:38:33 -0800 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 2 Mar 2004 23:38:32 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 2 Mar 2004 23:38:48 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 2 Mar 2004 23:38:34 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7165.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Source address selection insufficient? Date: Tue, 2 Mar 2004 23:38:08 -0800 Message-ID: Thread-Topic: Source address selection insufficient? thread-index: AcQA7qEfF/G+4LEKSwC8yupvdLDJJgAAcgUQ From: "Christian Huitema" To: "Erik Nordmark" Cc: X-OriginalArrivalTime: 03 Mar 2004 07:38:34.0104 (UTC) FILETIME=[883D9780:01C400F2] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > > Correct. If the only thing you do is try the four pairs, it may happen > > that no pair works. It is somewhat unlikely in practice, since sites > > tend to have a "default" provider, and the pair default-default ends up > > working. But it is definitely a possibility, in a "shoot your-self in > > the foot" kind of way. >=20 > Does this mean that we can remove the two solutions in your draft > (solution 2 and 7) which use source address selection as the means > to avoid ingress filtering issues? Source address selection will work in a lot of practical cases, e.g. whenever there is a "default" route. Source address selection is also adequate in some very practical multi-homing cases, where the different site exits lead to disjoint subsets of the Internet -- back-door routing scenarios. > > Locator rewriting supposes that both sites (X and Y) cooperate. If that > > is the case, you can also implement an end-to-end solution, e.g. X sends > > "A:X-C:Y", Y replies A:X-D:Y, and both decide to agree on the result. >=20 > Not only that - it also assumes that the peer host has been modified > to be able to handle locators that are rewritten. > Thus it would take longer to deploy etc. etc. >=20 > > Relaxed filtering and source-based routing are "local" solutions: they > > make no hypothesis on the behavior of the remote site. >=20 > Agreed. >=20 > > Source based routing is trivial to implement in single-subnet sites. >=20 > Yep. But it becomes a lot more complex as the site grows. There is value in having a simple solution that works for a large fraction of the sites. For example, we could make that an extension of automatic address configuration. "If host X configures the address A:X after hearing an announcement from router RA, then it should use router RA as the next hop when the source address is set to A:X." Then, you can add another simple rule for routers, "A router must not advertise an address configuration prefix if it cannot safely route packets whose source address is derived from that prefix."=20 These two rules have very simple fall-back conditions: a host that configures only one address must always use the advertising router as default router; a router that cannot perform source-based routing must advertise at most one prefix. > If we decide that source-based routing only applies to a subset of the > sites, e.g. due to large sites being able to use relaxed filtering, then=20 > the incentive for wide-spread implementation of these more complex > techniques might be a challenge. Whatever we do for connection survival, we should have a special effort dedicated to ingress-filtering, and come up with a simple recommendation. -- Christian Huitema From owner-multi6@ops.ietf.org Wed Mar 3 03:10:40 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09748 for ; Wed, 3 Mar 2004 03:10:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AyRSC-000Nor-Ba for multi6-data@psg.com; Wed, 03 Mar 2004 08:10:08 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AyRSA-000NoZ-Ej for multi6@ops.ietf.org; Wed, 03 Mar 2004 08:10:06 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i238A2411656; Wed, 3 Mar 2004 10:10:02 +0200 Date: Wed, 3 Mar 2004 10:10:02 +0200 (EET) From: Pekka Savola To: Erik Nordmark cc: multi6@ops.ietf.org Subject: Re: Source address selection insufficient? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 2 Mar 2004, Erik Nordmark wrote: > Taking the canonical picture from the draft > /-- ( A ) ---( ) --- ( C ) --\ > X (site X) ( IPv6 ) (Site Y) Y > \-- ( B ) ---( ) --- ( D ) --/ > > This has 4 locator pairs: > A:X-C:Y > A:X-D:Y > B:X-C:Y > B:X-D:Y > > The set of locator pairs that work when sending out from site X > might be A:X-C:Y and B:X-D:Y > but the set of locator pairs that work when sending from site Y might > be the other two: A:X-D:Y and B:X-C:Y. I think what you're assuming that ingress filtering is recursive: it's done further down the IPv6 cloud from the both sides, rather than only at the edge. This is done today, and is feasible. (dtaft-savola-bcp38-multihoming-update-03.txt, in RFC ed queue), discusses this a bit. But I see no problem. You're assuming that someone down towards the IPv6 cloud has broken ingress filtering (such a case would be noticed today as well). When the correctly-sourced packet has went from the edge site to the first ISP, it already has the correct address, corresponding the address block of the ISP. If an ISP's upstream does not allow the ISP to send traffic from its own addresses, the upstream ISP is hosed. So, I don't see the problem here -- could you elaborate? Maybe I didn't understand your scenario? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Wed Mar 3 03:16:47 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10027 for ; Wed, 3 Mar 2004 03:16:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AyRYF-000Orl-Tp for multi6-data@psg.com; Wed, 03 Mar 2004 08:16:23 +0000 Received: from [208.184.79.7] (helo=joy.songbird.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AyRYD-000OrM-4p for multi6@ops.ietf.org; Wed, 03 Mar 2004 08:16:21 +0000 Received: from BBFUJIP.brandenburg.com (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i238Oxd19125; Wed, 3 Mar 2004 00:25:01 -0800 Date: Wed, 3 Mar 2004 17:15:55 +0900 From: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <782830032.20040303171555@brandenburg.com> To: john.loughney@nokia.com CC: multi6@ops.ietf.org Subject: Re: on the point of mobility & multihoming In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-3.7 required=5.0 tests=AWL,BAYES_00,PRIORITY_NO_NAME autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit john, jlnc> that don't interoperate well. Could we restrict ourselves to multihoming, jlnc> but perhaps the authors of the proposals add a section on Mobility Considerations, jlnc> so we don't run into incompatiple solutions? The reasons that -- for this topic -- I think it is quite important to look at mobility and multihoming together are: 1. My own perusal is convincing me that they have more in common than they have different 2. Focusing only on one leads to assumptions that can be overly restrictive. For example, one might think of multhoming addresses as being too stable. Or one might think of mobility as only a trade from one address to another. In his typically frustrating style, of raising really good, basic points, Geoff pointed out that one can be mobile AND multihomed. If we focus on one and not the other, we are not likely to deal with this breadth and overlap adequately. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-multi6@ops.ietf.org Wed Mar 3 05:51:06 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17823 for ; Wed, 3 Mar 2004 05:51:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AyTwK-0003yp-5G for multi6-data@psg.com; Wed, 03 Mar 2004 10:49:24 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AyTwG-0003yB-Nk for multi6@ops.ietf.org; Wed, 03 Mar 2004 10:49:20 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i23AnGE14310; Wed, 3 Mar 2004 12:49:17 +0200 Date: Wed, 3 Mar 2004 12:49:16 +0200 (EET) From: Pekka Savola To: Erik Nordmark cc: multi6@ops.ietf.org Subject: Re: Source address selection insufficient? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Sorry -- I was confused, reading "source address based routing" rather than "source address selection". Policy-based routing works, has been widely implemented (multiple for v6 as well), and works quite well. You don't even have to do that on other than site border routers unless you want to. On Wed, 3 Mar 2004, Pekka Savola wrote: > On Tue, 2 Mar 2004, Erik Nordmark wrote: > > Taking the canonical picture from the draft > > /-- ( A ) ---( ) --- ( C ) --\ > > X (site X) ( IPv6 ) (Site Y) Y > > \-- ( B ) ---( ) --- ( D ) --/ > > > > This has 4 locator pairs: > > A:X-C:Y > > A:X-D:Y > > B:X-C:Y > > B:X-D:Y > > > > The set of locator pairs that work when sending out from site X > > might be A:X-C:Y and B:X-D:Y > > but the set of locator pairs that work when sending from site Y might > > be the other two: A:X-D:Y and B:X-C:Y. > > I think what you're assuming that ingress filtering is recursive: it's > done further down the IPv6 cloud from the both sides, rather than only > at the edge. > > This is done today, and is feasible. > (dtaft-savola-bcp38-multihoming-update-03.txt, in RFC ed queue), > discusses this a bit. > > But I see no problem. You're assuming that someone down towards the > IPv6 cloud has broken ingress filtering (such a case would be noticed > today as well). When the correctly-sourced packet has went from the > edge site to the first ISP, it already has the correct address, > corresponding the address block of the ISP. If an ISP's upstream does > not allow the ISP to send traffic from its own addresses, the upstream > ISP is hosed. > > So, I don't see the problem here -- could you elaborate? Maybe I > didn't understand your scenario? > > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Wed Mar 3 06:04:05 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18480 for ; Wed, 3 Mar 2004 06:03:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AyUAC-0007hR-4H for multi6-data@psg.com; Wed, 03 Mar 2004 11:03:44 +0000 Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AyUAB-0007hC-3v for multi6@ops.ietf.org; Wed, 03 Mar 2004 11:03:43 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i23B3ci5004690; Wed, 3 Mar 2004 04:03:39 -0700 (MST) Received: from bobo (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i23B3ZQ22629; Wed, 3 Mar 2004 12:03:36 +0100 (MET) Date: Wed, 3 Mar 2004 03:03:40 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Source address selection insufficient? To: Pekka Savola Cc: Erik Nordmark , multi6@ops.ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk > I think what you're assuming that ingress filtering is recursive: it's > done further down the IPv6 cloud from the both sides, rather than only > at the edge. No, it's about the ingress filtering at site X and site Y. The initiator at site X can explore using all 4 locator combinations (e.g. for the TCP SYN) and 2 of those pairs will make it out pasts the ingress filtering of X's ISPs. There is no filtering between those ISPs and site Y thus the SYN makes it to the peer. But the peer responds (with the SYN ACK) and has no choice on the addresses - it must respond using the addresses that was in the SYN. When these (SYN ACK) packets hit the ingress filter in Y's ISPs they are filtered out. As a result none of the 4 locator pairs work. Erik From owner-multi6@ops.ietf.org Wed Mar 3 06:09:20 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18686 for ; Wed, 3 Mar 2004 06:09:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AyUF3-0008tO-Vg for multi6-data@psg.com; Wed, 03 Mar 2004 11:08:45 +0000 Received: from [163.117.136.121] (helo=smtp01.uc3m.es) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AyUF3-0008t6-0U for multi6@ops.ietf.org; Wed, 03 Mar 2004 11:08:45 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 2A701106A4; Wed, 3 Mar 2004 12:08:44 +0100 (CET) Received: from lolo (vpn-252-215.uc3m.es [163.117.252.215]) by smtp01.uc3m.es (Postfix) with SMTP id DDCAA10694; Wed, 3 Mar 2004 12:08:41 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: Cc: "Margaret Wasserman" , Subject: RE: Comments on WIMP and MTU Handling Date: Wed, 3 Mar 2004 20:06:39 +0900 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) x-mimeole: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <200403030518.i235IQMR018375@unknown.hamachi.org> Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Bill, > > i mean, if you present a reduced mtu to the upper layers, but > the additional > > header is not included, you are actually sending less bytes, which means > > that you are consuming less bandwidth, so others can use it. > > huh? > > if you shrink the MTU, you're putting more of your available link > capacity into packet headers because you now need more packets to > carry a given payload. I agree with you. There are three different scenarios, IMHO. The best case, the complete MTU is presented to the upper layer, so it can be used complete The second case, is when a reduced MTU is presented but the additional header is not included, so less bytes are transmited. The worst case is when a reduced MTU is presented and the header is included in the packet. My point was about that the second and the third are different and that the second case was better than the third one. Is this correct? Regards, marcelo > > - Bill > > From owner-multi6@ops.ietf.org Wed Mar 3 06:11:33 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18749 for ; Wed, 3 Mar 2004 06:11:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AyUHb-0009Ut-Pp for multi6-data@psg.com; Wed, 03 Mar 2004 11:11:23 +0000 Received: from [192.18.42.14] (helo=nwkea-mail-2.sun.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AyUHa-0009Uf-Vz for multi6@ops.ietf.org; Wed, 03 Mar 2004 11:11:23 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i23BBLdO004088; Wed, 3 Mar 2004 03:11:21 -0800 (PST) Received: from bobo (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i23BBIQ22891; Wed, 3 Mar 2004 12:11:18 +0100 (MET) Date: Wed, 3 Mar 2004 03:11:23 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: Source address selection insufficient? To: Christian Huitema Cc: Erik Nordmark , multi6@ops.ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk > Source address selection will work in a lot of practical cases, e.g. > whenever there is a "default" route. Source address selection is also > adequate in some very practical multi-homing cases, where the different > site exits lead to disjoint subsets of the Internet -- back-door routing > scenarios. Let me make an analogy regarding TCP checksums: In most practical cases the packets are not corrupted, and of those few corruptions that occur practically all are caught by L2 CRCs. Hence, by analogy, we don't need any checksums in TCP?? When engineering solutions to ingress filtering I'd prefer if be pick solutions which work indendently of what the routing tables look like. Erik From owner-multi6@ops.ietf.org Wed Mar 3 06:22:21 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19180 for ; Wed, 3 Mar 2004 06:22:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AyURm-000Bzj-1w for multi6-data@psg.com; Wed, 03 Mar 2004 11:21:54 +0000 Received: from [131.228.20.27] (helo=mgw-x4.nokia.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AyURc-000BxN-Vp for multi6@ops.ietf.org; Wed, 03 Mar 2004 11:21:45 +0000 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i23BLhC10157; Wed, 3 Mar 2004 13:21:43 +0200 (EET) X-Scanned: Wed, 3 Mar 2004 13:20:32 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i23BKWeE013586; Wed, 3 Mar 2004 13:20:32 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00FHyPCC; Wed, 03 Mar 2004 13:20:30 EET Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i23BKT726532; Wed, 3 Mar 2004 13:20:29 +0200 (EET) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 3 Mar 2004 13:20:30 +0200 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: on the point of mobility & multihoming Date: Wed, 3 Mar 2004 13:20:29 +0200 Message-ID: Thread-Topic: on the point of mobility & multihoming thread-index: AcQA99xixN+mwYV+QkW5igz33SbaqwAGRo8g From: To: Cc: X-OriginalArrivalTime: 03 Mar 2004 11:20:30.0161 (UTC) FILETIME=[893AA410:01C40111] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.4 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Dave, > The reasons that -- for this topic -- I think it is quite important > to look at mobility and multihoming together are: >=20 > 1. My own perusal is convincing me that they have more in common > than they have different >=20 > 2. Focusing only on one leads to assumptions that can be overly > restrictive. For example, one might think of multhoming addresses as > being too stable. Or one might think of mobility as only a trade > from one address to another. >=20 > In his typically frustrating style, of raising really good, basic > points, Geoff pointed out that one can be mobile AND multihomed. >=20 > If we focus on one and not the other, we are not likely to deal with > this breadth and overlap adequately. If we try to kill 2 birds with one stone, we'll probably miss both. I think we should be aware of the mobility side of the topic, but I am not so sure we should make sure we explicitly state that we will solve both. I do think we should be aware of the mobility properties of any possible solutions, but I have my doubts that the IETF can solve problems that are less than extra-crispily defined. =20 thanks, John From owner-multi6@ops.ietf.org Wed Mar 3 06:35:45 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19717 for ; Wed, 3 Mar 2004 06:35:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AyUeX-000FE8-Vh for multi6-data@psg.com; Wed, 03 Mar 2004 11:35:05 +0000 Received: from [163.117.136.121] (helo=smtp01.uc3m.es) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AyUeO-000F5p-VW for multi6@ops.ietf.org; Wed, 03 Mar 2004 11:34:57 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 6296310B73; Wed, 3 Mar 2004 12:34:56 +0100 (CET) Received: from lolo (vpn-252-215.uc3m.es [163.117.252.215]) by smtp01.uc3m.es (Postfix) with SMTP id B3E3410B6A; Wed, 3 Mar 2004 12:34:53 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Erik Nordmark" , "Brian E Carpenter" Cc: "Noel Chiappa" , Subject: RE: draft-savola-multi6-asn-pi-01.txt Date: Wed, 3 Mar 2004 20:32:50 +0900 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) x-mimeole: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Isn't there an issue about needing to support N global locators (used > for external communication) plus at least one local locator? I may be not following, but my understanding is that Brian is proposing to use a non routable address as identifier, so that it can be assigned independently from the topology. This location independent identifier would be have a global meaning, not local, as i understand it. The problem is that it cannot be used as a locator. IMHO you could store it in the DNS, as long as you make sure that it is not used as a locator. Perhaps a new RR could be defined to store this id. regards, marcelo > In the case of NOID, would it make sense to store the local > locator together > with the global locators in the (global) DNS? > > If you can't put them in the same lookup service, then you need some > mechanism to (securely) discover locators that are not in the lookup > service. (As an aside, if you have such a mechanism you could also use > it to share care-of addresses with your peer when being mobile.) > > But I haven't found a way to do this with acceptable security in a scheme > like NOID. I was hoping that the hash chains in WIMP could be > used for this > in NOID, but I think Jari convinced me that this has problems. > > It can be done securely when there is a new namespace as in HIP, SIM, etc. > > Erik > > > From owner-multi6@ops.ietf.org Wed Mar 3 06:36:06 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19721 for ; Wed, 3 Mar 2004 06:36:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AyUfK-000FJw-FQ for multi6-data@psg.com; Wed, 03 Mar 2004 11:35:54 +0000 Received: from [192.44.77.17] (helo=laposte.rennes.enst-bretagne.fr) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AyUfJ-000FJd-5r for multi6@ops.ietf.org; Wed, 03 Mar 2004 11:35:53 +0000 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i23BZmS03567; Wed, 3 Mar 2004 12:35:48 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i23BZmSj061352; Wed, 3 Mar 2004 12:35:48 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200403031135.i23BZmSj061352@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pekka Savola cc: Erik Nordmark , multi6@ops.ietf.org Subject: Re: Source address selection insufficient? In-reply-to: Your message of Wed, 03 Mar 2004 12:49:16 +0200. Date: Wed, 03 Mar 2004 12:35:48 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk In your previous mail you wrote: Policy-based routing works, has been widely implemented (multiple for v6 as well), and works quite well. => I disagree a little because Cisco policy-based routing and Juniper filter-based forwarding share the same problem: they are based on ACLs and lack of dynamic capabilities. In fact they are only useful in the ingress filtering context. Regards Francis.Dupont@enst-bretagne.fr PS: I can share my experience of this. As far as I know, there is no concrete available examples... From owner-multi6@ops.ietf.org Wed Mar 3 06:47:45 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20232 for ; Wed, 3 Mar 2004 06:47:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AyUqM-000Ijk-VK for multi6-data@psg.com; Wed, 03 Mar 2004 11:47:18 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AyUqJ-000IjD-Fa for multi6@ops.ietf.org; Wed, 03 Mar 2004 11:47:15 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i23Bl3315390; Wed, 3 Mar 2004 13:47:03 +0200 Date: Wed, 3 Mar 2004 13:47:03 +0200 (EET) From: Pekka Savola To: Francis Dupont cc: Erik Nordmark , Subject: Re: Source address selection insufficient? In-Reply-To: <200403031135.i23BZmSj061352@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 3 Mar 2004, Francis Dupont wrote: > In your previous mail you wrote: > > Policy-based routing works, has been widely implemented (multiple for > v6 as well), and works quite well. > > => I disagree a little because Cisco policy-based routing and Juniper > filter-based forwarding share the same problem: they are based on ACLs > and lack of dynamic capabilities. In fact they are only useful in the > ingress filtering context. What kind of dynamic capabilities would you looking for? Reaction to the routing table? But this is out of scope, so maybe you should follow up off-list. The point is that you can match against the source prefix, which is what is required here. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Wed Mar 3 07:55:26 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23451 for ; Wed, 3 Mar 2004 07:55:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AyVsi-0007XR-Br for multi6-data@psg.com; Wed, 03 Mar 2004 12:53:48 +0000 Received: from [192.44.77.17] (helo=laposte.rennes.enst-bretagne.fr) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AyVsg-0007X6-Eg for multi6@ops.ietf.org; Wed, 03 Mar 2004 12:53:46 +0000 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i23CrdS09631; Wed, 3 Mar 2004 13:53:39 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i23CrdSj061610; Wed, 3 Mar 2004 13:53:39 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200403031253.i23CrdSj061610@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pekka Savola cc: Erik Nordmark , multi6@ops.ietf.org Subject: Re: Source address selection insufficient? In-reply-to: Your message of Wed, 03 Mar 2004 13:47:03 +0200. Date: Wed, 03 Mar 2004 13:53:39 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk In your previous mail you wrote: > => I disagree a little because Cisco policy-based routing and Juniper > filter-based forwarding share the same problem: they are based on ACLs > and lack of dynamic capabilities. In fact they are only useful in the > ingress filtering context. What kind of dynamic capabilities would you looking for? Reaction to the routing table? => exactly. This can save existing connections on some limited but important in some cases (after some previous arrangements with your ISPs). But this is out of scope, so maybe you should follow up off-list. => I agree.. The point is that you can match against the source prefix, which is what is required here. => my concern is that it is very hard or impossible to get more :-( Regards Francis.Dupont@enst-bretagne.fr From owner-multi6@ops.ietf.org Wed Mar 3 15:34:44 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25102 for ; Wed, 3 Mar 2004 15:34:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ayd1c-000917-OX for multi6-data@psg.com; Wed, 03 Mar 2004 20:31:28 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Ayd1Z-00090u-8H for multi6@ops.ietf.org; Wed, 03 Mar 2004 20:31:25 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i23KVhrq050405; Wed, 3 Mar 2004 21:31:43 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: multi6@ops.ietf.org From: Iljitsch van Beijnum Subject: Re: Comments on WIMP and MTU Handling Date: Wed, 3 Mar 2004 21:31:23 +0100 To: Margaret Wasserman X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 3-mrt-04, at 1:58, Margaret Wasserman wrote: > If an ID/Loc layer will exist conceptually below the > fragmentation/reassembly function, it is problematic for it to add > optional bytes to the packet (such as a header or IP option that may > or may not be included). There are some possibilities for dealing > with this: > - Run the ID/Loc separation between the Network and Transport > layers instead. As opposed to network and link or transport and application??? Doing address agility first and then fragmentation makes implementing the former in a middlebox much harder, if not impossible. > - Reduce the MTU presented to upper layers, so that there is > always room for the optional header. Also problematic. What if the MTU already is 1280 or not much larger, and the new MTU would be lower than 1280? But ignoring this for a moment, it should be just fine to have the transport learn a small MTU at one point in time (because a large option needs to be added) and then at a later time the full MTU is available because there is no need for an option at this time. An alternative would be to fragment the segment coming from the transport layer without telling the transport layer about this, and then add the option to one of the fragments. This makes it necessary for the part of the stack doing the fragmenting to be aware of the multihoming solution, though. Another way to get around this is to send the options as independent messages. However, since firewalls won't recognize these packets they may not make it to the destination host. Solution for that would be to add a transport layer header without any payload data so firewalls can see which session the packet belongs to (if any). From owner-multi6@ops.ietf.org Wed Mar 3 16:03:41 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26206 for ; Wed, 3 Mar 2004 16:03:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AydVs-000HCq-MU for multi6-data@psg.com; Wed, 03 Mar 2004 21:02:44 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AydVp-000H5e-V7 for multi6@ops.ietf.org; Wed, 03 Mar 2004 21:02:42 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i23L2srq050820; Wed, 3 Mar 2004 22:02:56 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1827B216-6D56-11D8-A08E-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: From: Iljitsch van Beijnum Subject: Re: on the point of mobility & multihoming Date: Wed, 3 Mar 2004 22:02:34 +0100 To: X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 3-mrt-04, at 3:35, wrote: >> From today's session, Dave & Geoff discussed multihoming vs. >> mobility. In > a working group I chair, we've had similar discussions and from a > transport > layer, maintaining a session during a multihoming change and a > mobility change can be quite similar. I second Dave's comment that > trying to solve two things at once can be never-ending. He also > mentioned that solving two > problems seperately can lead to incompatible or extremely complex > solutions > that don't interoperate well. Multiaddress mulithoming and mobility solutions must incorporate the following mechanisms: 1. multiplexing in the presence of more than one address pair 2. adding/removing addresses 3. for multihoming: failover 4. for mobility: rendezvous It would be stupid to have two sets of mechanisms for 1. and 2., as the complexity of having to implement them both such that they can work reliably in the presence of the other is sure to be much worse than simply sharing them between mobility and multihoming. Unfortunately the ways in which current MIPv6 does these are sub-par, so we need to have something better. The logical conclusion is that the MIP people will have to throw their stuff out and use the new mechanisms, but I don't think we're ready to have that fight quite yet. From owner-multi6@ops.ietf.org Wed Mar 3 20:32:46 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12931 for ; Wed, 3 Mar 2004 20:32:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AyhhU-0004JQ-Eu for multi6-data@psg.com; Thu, 04 Mar 2004 01:31:00 +0000 Received: from [68.6.19.244] (helo=fed1mtao01.cox.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AyhhS-0004J7-B8 for multi6@ops.ietf.org; Thu, 04 Mar 2004 01:30:58 +0000 Received: from momo ([68.2.220.20]) by fed1mtao01.cox.net (InterMail vM.5.01.06.08 201-253-122-130-108-20031117) with SMTP id <20040304013057.KHUM50.fed1mtao01.cox.net@momo>; Wed, 3 Mar 2004 20:30:57 -0500 From: "Kanchei Loa" To: Cc: "Iljitsch van Beijnum" Subject: RE: on the point of mobility & multihoming Date: Wed, 3 Mar 2004 18:30:53 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <1827B216-6D56-11D8-A08E-000A95CD987A@muada.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit If a multihoming host is assigned an unstructured identity tokens (opportunistic tokens), then it needs rendezvous. If a mobile host keeps more than one locator for redundancy, then it needs failover. So, what is the difference between multihoming and mobility except the time scale of the updating rate ? -------- Kanchei Loa loa@ieee.org -----Original Message----- From: owner-multi6@ops.ietf.org [mailto:owner-multi6@ops.ietf.org]On Behalf Of Iljitsch van Beijnum Sent: Wednesday, March 03, 2004 2:03 PM To: john.loughney@nokia.com Cc: multi6@ops.ietf.org Subject: Re: on the point of mobility & multihoming - comparsion between mutihome and moblity On 3-mrt-04, at 3:35, wrote: >> From today's session, Dave & Geoff discussed multihoming vs. >> mobility. In > a working group I chair, we've had similar discussions and from a > transport > layer, maintaining a session during a multihoming change and a > mobility change can be quite similar. I second Dave's comment that > trying to solve two things at once can be never-ending. He also > mentioned that solving two > problems seperately can lead to incompatible or extremely complex > solutions > that don't interoperate well. Multiaddress mulithoming and mobility solutions must incorporate the following mechanisms: 1. multiplexing in the presence of more than one address pair 2. adding/removing addresses 3. for multihoming: failover 4. for mobility: rendezvous It would be stupid to have two sets of mechanisms for 1. and 2., as the complexity of having to implement them both such that they can work reliably in the presence of the other is sure to be much worse than simply sharing them between mobility and multihoming. Unfortunately the ways in which current MIPv6 does these are sub-par, so we need to have something better. The logical conclusion is that the MIP people will have to throw their stuff out and use the new mechanisms, but I don't think we're ready to have that fight quite yet. From owner-multi6@ops.ietf.org Wed Mar 3 20:53:26 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14454 for ; Wed, 3 Mar 2004 20:53:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ayi26-0009Xq-Oa for multi6-data@psg.com; Thu, 04 Mar 2004 01:52:18 +0000 Received: from [163.117.136.121] (helo=smtp01.uc3m.es) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Ayi25-0009XR-PN for multi6@ops.ietf.org; Thu, 04 Mar 2004 01:52:17 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 58E0610A25; Thu, 4 Mar 2004 02:52:16 +0100 (CET) Received: from lolo (vpn-252-215.uc3m.es [163.117.252.215]) by smtp01.uc3m.es (Postfix) with SMTP id D562310A32; Thu, 4 Mar 2004 02:52:13 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Iljitsch van Beijnum" , Cc: Subject: RE: on the point of mobility & multihoming Date: Thu, 4 Mar 2004 10:50:10 +0900 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: <1827B216-6D56-11D8-A08E-000A95CD987A@muada.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Iljitsch, > Multiaddress mulithoming and mobility solutions must incorporate the > following mechanisms: > > 1. multiplexing in the presence of more than one address pair > 2. adding/removing addresses Well, there is a difference in the requirements in this point in mobility and multihoming. Both needs a handover mechanism, to stop using a locator and start using an alternative one, but strictly speaking, the locator set involved in a multihoming solution can be fixed, becuase it is known a priori, for instance consider noid. In mobility, this is not so, because you don't know which will be your future locators. Regards, marcelo > 3. for multihoming: failover > 4. for mobility: rendezvous > > It would be stupid to have two sets of mechanisms for 1. and 2., as the > complexity of having to implement them both such that they can work > reliably in the presence of the other is sure to be much worse than > simply sharing them between mobility and multihoming. Unfortunately the > ways in which current MIPv6 does these are sub-par, so we need to have > something better. The logical conclusion is that the MIP people will > have to throw their stuff out and use the new mechanisms, but I don't > think we're ready to have that fight quite yet. > > From owner-multi6@ops.ietf.org Wed Mar 3 23:19:34 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24949 for ; Wed, 3 Mar 2004 23:19:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AykJQ-000Hqv-JT for multi6-data@psg.com; Thu, 04 Mar 2004 04:18:20 +0000 Received: from [208.184.79.7] (helo=joy.songbird.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AykJM-000HqV-Hi for multi6@ops.ietf.org; Thu, 04 Mar 2004 04:18:16 +0000 Received: from BBFUJIP.brandenburg.com (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i244R6d08456 for ; Wed, 3 Mar 2004 20:27:07 -0800 Date: Thu, 4 Mar 2004 13:18:10 +0900 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <34012983.20040304131810@brandenburg.com> To: multi6@ops.ietf.org Subject: Re: on the point of mobility & multihoming In-Reply-To: References: <1827B216-6D56-11D8-A08E-000A95CD987A@muada.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.7 required=5.0 tests=AWL,BAYES_00,PRIORITY_NO_NAME autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Folks,, KL> If a multihoming host is assigned an unstructured identity tokens KL> (opportunistic tokens), then it needs rendezvous. If a mobile host keeps KL> more than one locator for redundancy, then it needs failover. So, what is KL> the difference between multihoming and mobility except the time scale of the KL> updating rate ? exactly. Last week, Geoff Huston suggested an interesting scenario: You take your laptop to the park. Nearby is a very strong, high-speed link at a coffee shop. Some distance away is a much weaker/slower link. Traffic driving by disconnects constantly changes your preferred access point. This is mobile multihoming. Although a park venue might not be the norm, it strikes me as a pretty typical scenario for quite a few likely situations. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-multi6@ops.ietf.org Wed Mar 3 23:44:38 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26704 for ; Wed, 3 Mar 2004 23:44:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AykiM-000MxY-Hs for multi6-data@psg.com; Thu, 04 Mar 2004 04:44:06 +0000 Received: from [218.37.229.253] (helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AykiI-000MwT-OP for multi6@ops.ietf.org; Thu, 04 Mar 2004 04:44:02 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id 4915630A718 for ; Thu, 4 Mar 2004 05:44:23 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v612) Content-Transfer-Encoding: 7bit Message-Id: <99299254-6D96-11D8-B4D0-000A95928574@kurtis.pp.se> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=fixed To: Multi6 List From: Kurt Erik Lindqvist Subject: Minutes from the multi6 WG at IETF59 Date: Thu, 4 Mar 2004 05:44:18 +0100 X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thanks to Marcelo for taking the minutes!!! - - kurtis - Multi6 working group ==================== Wednesday 3 March Agenda: 1. Agenda bashing and Administrativia, chair 2. Charter review, chair 3. Short intros to NEW drafts draft-ohta-multi6-threats-00.txt, Masataka Ohta draft-ohta-multi6-8plus8-00.txt , Masataka Ohta draft-ohira-multi6-multilink-auto-prefix-assign-00.txt, Kenji Ohira draft-arifumi-multi6-tlc-fm-00.txt, Arifumi Matsumoto draft-ylitalo-multi6-wimp-00.txt, Vessa Torvinen draft-nikander-multi6-hip-00.txt, Pekka Nikander draft-coene-multi6-sctp-00.txt, Lode Coene draft-crocker-celp-00.txt, Avri Doria draft-toyama-multi6-operational-site-multihoming-00, K. Toyama 4. draft-lear-multi6-things-to-think-about-00.txt, Eliot Lear 5. Architectural analysis, Geoff Huston 6. Other issues 1. Agenda bashing and Administrativia ===================================== Brian Carpenter is not here today, so only Kurt Erik Lindqvist will chair the session. Session is broadcasted. Comments on the updated charter by Kurt Erik Lindqvist. Some modifications have been proposed to the charter. The updated charter has been sent to the IESG. The IESG then made some comments and those are being solved. There are new milestones, including: - Architectural evaluation for Feb. 04, which is expected to be based in the work done by Geoff Huston. April timeframe was considered. This draft will be used then to classify and evaluate proposals. - Informational draft about current multihoming practices in IPv4, as confirmed in the Vienna meeting. A draft exist covering this issue, but is to be updated. No much feedback about the draft yet. The chairs may need to find an editor for this. - Operational draft containing practical questions. The proposal is to base it on draft-lear-multi6-things-to-think-about-00.txt by Elliot Lear. The proposal is to obtain more discussion on this and then send it to last call. - Threats draft. The proposal is to base it on draft-nordmark-multi6-threats-00.txt. Questions: Pekka Savola: I am concerned about ID about current IPv4 multihoming today, there are still big issues with it. Is it already submitted? Kurt Erik Lindqvist: It has not been submitted yet, the chairs need to decide how to move forward with this. Decisions/Outcomes ================== 1. Adopted draft-lear-multi6-things-to-think-about-00.txt as a working group item. 2. Geoff Huston will produce a draft containing the architectural analysis. 3. Erik Nordmark will update the security threats draft 4. Possible interim meeting to be defined. 00 Draft Presentations ====================== Threats Relating to Transport Layer Protocols Handling Multiple Addresses - ------------------------------------------------------------------------ - - Masataka Ohta Multiple addresses assigned to homes in multihomed sites are needed in order to preserve global BGP routing table small. A session is something that needs state, so it is not at the IP layer, since no per connection state exists in IP. The connection state resides at the transport layer. So, this draft analyses the threats in transport layers managing multiple addresses. Threats: - Connection hijacking: it is not a new threat, since MITM in DNS queries/replies or rewriting an URL in HTTP can cause similar effects. The solution for this is to protect with cookies and this solution is already considered. - DDOS: The problem is amplification, This is not new threat, since it is similar to, for instance, what happens in the DNS, where the reply is longer than query. A multihoming solution should not generate answers that are longer than requests. However, new DOS opportunity can be caused by the usage of public key crypto in multihoming solutions, because public key crypto is costly. Cookie based solutions are not so expensive. - Privacy in the identification: A multihoming solution should allow to hide the identity information, so it should be allowed identifiers to be temporal. 8+8 Addressing for IPv6 End to End Multihoming - ---------------------------------------------- Masataka Ohta 8+8 addresses is an old concept, and it is based are composed by 8 bytes locators (used for routing) and 8 bytes identifiers (used for identification). For multihoming support with multiple addresses, the support cannot be provided by the IP layer, because IP is stateless. This proposal does not change IP. 8+8 addresses the issue of interoperability with legacy hosts. For this it is necessary to discover when to use 8+8 capabilities i.e. whether the other end of the communication supports 8+8. The proposed solution is to use the group bit in the identifier to signal if the the node supports 8+8 mode. Question: ??: Are you proposing to use the group bit for this? Masataka Ohta: this bit it is not used today. Continue with presentation: A problem is how to distribute identifiers, in this case identifiers can be assigned like DNS names, since you can base the identifiers in the locators. Locator selection is not a problem because the global routing table is used for that. Source locator is not an issue, since source address is ignored. In the case that some issues related with ingress filtering compatibility appear, they can be solved through a modification in the IGP (such as OSPF modification). There are no problems with Mobility. The solutions proposes to modify TCP, but in a fashion that it is compatible with old TCP. The solutions presents all the desirable properties presented in RFC 3582. Hierarchical IPv6 Subnet ID Autoconfiguration for Multi-Address Model... - ------------------------------------------------------------------------ K. Ohira Multiaddresses is proposed in several solutions This solution proposes an address assignment protocol to assign multiple addresses to host in multi-link multihomed sites. It is assumed that source address based routing will be used to select the exit. Transport survival is out of scope. The protocol proposed to assign addresses is the following: - Assign subnet identities to each link, by dividing the subnet field in the IP address - The top level router i.e. the one connection to the ISP, obtains a /48, and splits it downwards. RFC 3582 assessment slide TLC-FM : Transport Layer Common Framework for Multihoming - --------------------------------------------------------- Arifumi Matsumoto Fate sharing based classification of different type of solutions: - SCTP, TCP-MH and DCCP: each layer has its own multihoming information which is not shared with other transport layers. - Wedge solutions: the multihoming information affects all the sessions in the host. The problem with this approach is that each application cannot choose its own paths TLC-FM proposes to use an intermediate level of fate sharing (information shared). Each transport shares the information with other transport layers. However, each transport chooses the path for its packets, and it also is responsible to detect outages in the currently used path. The information that is shared is the path information, where a path is defined as a destination address, a source address and a next hop. Next hop information is especially relevant for multilink hosts . The information about the quality of the path should also be shared because it is useful when selecting a path to avoid network failures. Failure detection is performed by each transport using different mechanisms: - TCP: data retransmission - UDP: received ICMP messages (Destination unreachable, Time exceeded) and it can also use some help from applications (requiring a new API to notify outages) TLC-FM needs a control channel to inform about the addresses available. Questions: Pekka Nikander: It is an interesting proposal. Isn't similar to CELP? Perhaps it should be joined with CELP? Arifumi Matsumoto: It is similar to CELP. The difference is the policy since each transport can have a different path. Erik Nordmark: How do you apply this to SCTP considering that SCTP test its own path? You probably want to share the path test information too for performance benefits. Arifumi Matsumoto: The problem is that such feature is not available in other protocols. Weak Identifier Multihoming Protocol (WIMP) - ------------------------------------------- V. Torvinen The basic assumption is that there are lighter operations than public key crypto. The basic operations are much faster. WIMP has two main components: a context establishment phase and a readdressing protocol. WIMP uses non routable endpoint identifiers. Identifiers are hashes of strings (fqdn,and ephemeral identifiers). The reason for that is not to allow the attacker to steal the identifier. Basic cryptographic concepts used: - Hash chains: recursive calculation of hash starting from a random number and then feeding the next hash with the output of the previous hash. The main characteristic of this chain of values is that it is impossible to know the next value from the previous one, but you can verify the previous value. - Secret splitting: it is used to send parts of the spit secret through multiple paths, assuming that no one attacker can intercept all the paths during a readdressing operation. Basic operation: 4 way handshake is used to establish context. The anchor values of the initiator and responder hash chains are exchanged during this handshake. It is vulnerable to MITM attacks at the initial exchange. Major comments received are about endpoint identifiers and flow identifiers. Questions: Elliot Lear: This looks similar to Purpose Build Keys? Is it similar? Pekka Nikander: The goal is the same, but WIMP uses hash operations instead of public key crypto, which provides same functionality with better performance Masataka Ohta: Sequence numbers can also be hashed with a key and it is just as good, and why do you split keys? V. Torvinen: We split the secret to make return routability to the new addresses. Masataka Ohta: This can be easily snooped. Erik Nordmark: Return Routability test is used to verify that the end is at the address that it is claiming. Margaret Wasserman: Good draft, but about secret splitting usage, it seems that you have to reach the host at the previous address, what happens when the host is no longer available at the previous address? V. Torvinen: We haven't considered mobility. In the considered case, the initiator informs about the locators he wants to use. Pekka Nikander: Just to clarify about this, there are two options here. One is to run the address exchange protocol before loosing the path, so when the path is gone there are no problems. The other option is to split the secret in such a way that it is good enough to obtain only some of the parts of the secret. Margaret Wasserman: How fragmentation and PMTU discovery are handled? More comments on the list. Lightweight hip with delayed setup - ---------------------------------- Pekka Nikander The biggest criticism received when trying to apply HIP to multihoming is that hip is too heavy. HIP in opportunistic mode provides protection against everything but initial MITM attack. The proposal is to preserve current level of security with less cost, by combining WIMP and HIP. The idea is to combine initial 4-way exchange of HIP and WIMP, so that initial messages carry both HITs and MAC of the anchors. The receiver then can choose to use HIP or WIMP. So the communicating nodes can continue to use WIMP as long as they want, but they feel that they are facing an attack you, then they can run full HIP to protect themselves. Still more in depth analysis of the potential introduced vulnerabilities is required. Questions: Richard Graveman: IKEv2 provides same features and also protects from initial MITM Pekka Nikander: You need PKI to protect initial MITM, since in opportunistic mode you can't protect initial MITM attack. ??: do you use IPSec in light mode? Pekka Nikander: no. Multihoming: the SCTP solution - ------------------------------ L. Coene This draft essentially asses the SCTP multihoming solution with draft-lear-multi6-things-to-think-about-00.txt - No rendez vous for mobility are considered, since SCTP only performs the handover. - No additional latency, because data and control traffic are transmitted together. - No problems with DNS since it is only used to get an initial address. - For authentication: the proposal is to use PBK, and it seems that it will work. - How does the host knows its own ids? SCTP tries a subset of the IP addresses assigned to the host. - No extra load for DNS. - No extra upstream ISP support required. - The solution impact on the different sizes of sites from SCTP perspective is none since, SCTP doesn't care about the amount of addresses being handled. - About referrals: Question: Elliot Lear: the referral point is related to applications like FTP. Margaret Wasserman: Referral is not only about A telling B how to contact C, but also about A telling B how to contact A two hours later. L. Coene: I will review the referral aspects. Continue with the presentation: - No application changes are required - IP issues are solved in Christian's draft Questions: Margaret Wasserman: how does the draft addresses the point included in the goals draft? L. Coene: I forgot to include these points. MW: the goals draft require TCP and UDP support, how do you deal with that? LC: It is not supported Kurt Erik Lindqvist: RFC 3582 is a goals document, not a requirement document. Continue with presentation: Conclusions: - Some applications may be migrated to SCTP. - Reports about ADDIP messages in next meetings. - Deploy SCTP in carrier networks with multihoming support. - There is some work going on about multipath. Questions: Erik Nordmark: Is there some experience about selecting locator and paths available? LC: We are trying to collect the information. If IP is not working properly, there are problems. We are trying to collect more information about this. Framework for Common Endpoint Locator Pools - ------------------------------------------- Avri Doria There are multiple multiaddressing schemes, so we are looking for commonalities between them, so that they can share the work done by the other mechanisms available in a host, sort of an opportunistic use of other's information. The goal is to reduce transaction cost. There are two types of schemes identified : transport approaches and wedge approaches. Each approach has its benefits, but not all them solve all the problems. The proposed approach is to create common locator pools, so that both transport and wedge solutions can contribute to it. Different granularities are proposed for the stored information: host, flows, protocols, ToS The next step is to look at each multiaddress solution to see what they can provide. Each solution can insert information into the pool, and also benefit from the information available in it. There are several issues but the idea is to start with a simplified mechanisms and then go to more complex solutions. There are also some security issue related with how do manage when multiple solutions with different levels of security insert information into the pool. Other issues related to names used to identify locators pools. The next steps are: resolve the security and naming issues above. Go through other proposals, as stated earlier. Identify near term issues and longer term issues. All proposals have value and probably many of them will de accepted. Questions: M. Ohta: Different protocols have different ideas about the availability of paths, retransmission times and so on. Since this information is protocol independent, so you cannot share the information. AD: Different attributes for different pools can characterize that, and the administration of the pool is complex, so that for each protocol you need specific information. M.O.: But if you make it protocol wise, you don't have shared information then. Kurt Erik Lindqvist: Take it to the list. Operational Approach to achieve IPv6 multihomed network - ------------------------------------------------------- K. Toyama In IPv6, it is assumed that only aggregated routes will be advertised globally. This is a routing based solution, wihtout affecting the global routing table. It is proposed that a /32 and an AS number is assigned to the multihomed costumers of a group of ISPs, and that a /48 of this /32 assigned to each multihomed site. Peering relationships are established between the involved ISPs that serve the multihomed clients, so that each ISP injects the complete aggregate to the Internet. So the ISPs cooperate. The request is to allow the allocation of the resources required by the solution. Questions: Erik Nordmark: what happens if one of the ISPs goes down completely? K.T.: The other one provides backup. Elliot Lear: this solution can be implemented wihtout changes, but have you talked to ISPs about how do they feel about implementing this? K.T.: Not all pair of ISPs will want to cooperate. Francis Dupont: I have published something similar a long time ago. Peter Lothberg: There is not a single cloud which is the global Internet. End of 00 presentations - ----------------------- Presentations about specific charter items ========================================== Things MULTI6 Developers should think about - ------------------------------------------- Elliot Lear This is not a requirements document. It contains things beyond multi6 scope. It is not an architectural draft, it is about operational issues. It is not a position paper. It is a collection of operational questions, several of them are interrelated. For instance performance and security issues are considered in all the document. Key issues considered in the document: - Protocol on the wire: packet format changes introduced? and in which layer? Why that layer was selected? Impact on transport layer (pseudo header)?. Required changes on fragmentation? Additional latency? Are the changes required by all hosts or only multihomed hosts? - Security: How do you secure the binding between different names involved? Are there any new DOS opportunities created? Do you rely on other security infrastructure? - name/binding issues: Which is the lifetime of the binding? How is the binding updated? Do you introduce a new namespace? if yes, then, how does it looks like and how is it managed? Which is the relation with DNS?Is there any upstream ISP support required? Are there any dependencies on middle boxes? if yes, then what if they fail? - If the DNS is used: are there any circular dependencies between DNS and the routing system. Are there any new RRs? Is the FQDN goes in every packet? How is two faced DNS supported? Question: Pekka Savola: circular dependencies are more general than only to the DNS. E.L.: Yes. Continue with presentation: How does a host knows its own identifiers? Does the solution place an additional load in the DNS? Is DNSSec performance an issue? - Application implications: is it a new interface required? How do you support referrals like ftp, sip? - Backward compatibility: How the solution works with old IPv6? Can old IPv6 devices benefit from the solution? Do non-multihomed sites have to make changes? Changes are required on hosts, routers, both? Are there any changes in the management model? Two tests are suggested: how do you implement your solution in an IETF conference network? Have you tried in a lab? - Legal stuff: Do you create a new mnemonic namespace? How do you manage it? The goal of the draft is to compare results between proposals, creating a matrix to compare results. Perhaps even to merge similar solutions. Question to the Working Group: How many people have read the draft? Many hands. Do you think it needs more detail? M. Wasserman: It should be a living document, since changes will be introduced in the future. One thing I like to see added, about have delayed setup. When I start talking, do I need to know if the other end supports the multihoming solution? Another issue is, do we know which are the right answers? E. Lear: We should determine the set of important questions. Kurt Erik Lindqvist: Application people input is required. Security issues are listed, so the idea is to list the goals for security in each proposal. We don't want the document to contain the answers of the questions, we leave this for later. Pekka Savola: Some issues should be expanded, like what are the critical things. Some of the answers for this questions provided by the solutions are missing the point, so perhaps we should clarify. M. Ohta: The draft is very good, the checksumming issue should be included. K. Lindqvist: This is one of the new charter items, so Question to the Working Group: Who wants this as a working group item? Many hand for yes and no hand for no. An Architectural View of Multi6 proposals - ----------------------------------------- Geoff Huston Clarification: specific proposals are used just as examples. There is a very large amount of proposals and some look similar. The goal is to try to make a taxonomy based on the architectural goals of the proposals. Problem space is a multihomed site. Note that there may be more that two ISPs, and that communications don't only involve 2 parties always. Exit routers and hosts appear because they are included in several proposals. Presentations of the goals presented in RFC 3582 and some of the questions of Elliot's draft. There are three mayor approaches: - Wedge a new layer in the stack: Based on Soch's work (who, where and how) while in IP only the IP address is used for all of them. These proposals are trying to disambiguate the who from where and how. - Modify the stack, whether transport or IP - Modify the local interaction: Destination based forwarding algorithm is modified to select the right exit. Wedge solutions. Can be placed above IP or above the transport layers. Most proposal are below transport. ULP deal with an identity token and IP deals with locators. The hosts control the locators set but the ULP are not aware of the changes. There is an identity peering between the communicating hosts. There are many ways to do this: - Conventional: add a new OSI layer -> new header trailer, communication in band. - New control channel (out of band): can communicate even without data. It has its own triggers. - Refer to a third party, like the DNS. While architecturally all are the same, there are changes in the implementation. Modification to existent layers. - Fatter transport: SCTP example where pools of locators managed by transport. A new transport is needed. - Modified IP: One IP address is an alias for identity and the other IP address is an alias for location. Modified host/router interaction - Doesn't fit the layer model nicely. - The problem solved is that when a source address is selected and the wrong ISP is used, the packet is discarded - This means that when selection the source address implies a topological decision. IPv4 multihoming style: not an option? Common issues identified: - Required locator selection mechanisms by the host. - One's source locator is the other's destination, so this selection imposes the reverse path. - How is the selection among different destination locators? - How do you change locators once that the selection is made? when a change is needed? how are network failure detected? Some examples of analysis for proposals: - HIP: Shim layer between transport and IP. A stable identifier is presented to transport layer. Multiple locators are bound to a fixed identifier. So, locators can change in a session. - SIM, NOID and CB64: Shim layer approaches. NOID is referential, SIM uses protocol exchanges and CB64 is hybrid. Additional elements since exit router rewrite packets About namespace structure: - Hierarchical -Identifiers are part of the IP address space. - FQDN are used. Problems with the interaction between DNS and routing. The DNS may not be good enough for this mapping - New token: why is it needed? what feature is not available in existent namespaces? - Opportunistic: no need to manage the name space. How referrals are handled?, How searches are performed? SCTP: Heartbeat required to trigger locator change MIPv6: Only one locator valid in a give moment, encapsulation carrying the locator in the outer header and identifier in the inner header Modified host/site-exit interaction: Site forwarding paradigm is changed. Multiple options, like anycast address, source address based forwarding, source address rewriting. Other option is to provide a solution for the initial problem which is ingress filtering, so just release ingress filtering. Common issues: - How do you select best source locator? - How do you select the best destination locator? Detecting network failure - Heartbeats - Transport - ICMP from router - Note that failure between startup and once the session is established Security is not in the scope of this work, worthy of a separate analysis Questions: Erik Nordmark: The approaches that change the host/router relation, make the edge more explicit? G.H.: Yes, perhaps reality is not like this. E.N.: Are there any other architectural implications with making this border explicit? G.H.: If this model is mapped to reality, do you have a clean idea of what the exit is? M. Wasserman: what is the process in order to move more into details from here? Kurt Erik Lindqvist: Doing a document about proposals doing an evaluation referred to this taxonomy, and classify the proposals according to this. Besides with Elliot's draft we could have a benchmarking of the proposals. M.W.: I am worried that the architectural analysis is based on proposals, and that what is not covered by proposals is not included in the analysis. K.E.L.: Many proposals overlap, so we need to group them together Dave Crocker: Multihoming and mobility can be covered with similar mechanisms G.H.: I think the assumptions made by the solutions in both cases is that the identifier can be used as a glue between locators. D.C.: It may be complex if we try to solve all the problems in one and it may take forever. OTOH, separate solution may make things even more complex. Pekka Savola: A general comment: To progress we have to figure out deployment scenarios, and not only one solution will fit all the scenarios. K.E.L: Yes, that is why the document describing current IPv4 multihoming solutions is needed. James Kempf: Define deployment scenarios and simulations to see how this work K.E.L.: last comments on how do we proceed. The assumption was that Geoff would write a document with the architectural analysis. Additionally, we have to move forward the threats draft. Perhaps an interim meeting is needed. -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQEa0JqarNKXTPFCVEQL6JwCdGV51R7jtPApBoh9mdqnGRjGd/g0An3P4 F/cjTh0tiPEuSt/uk/Q7mHcF =vh7l -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Thu Mar 4 00:14:34 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28777 for ; Thu, 4 Mar 2004 00:14:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AylBO-00035y-5l for multi6-data@psg.com; Thu, 04 Mar 2004 05:14:06 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.30; FreeBSD) id 1AylBJ-00035b-Cj for multi6@ops.ietf.org; Thu, 04 Mar 2004 05:14:01 +0000 Received: (qmail 50161 invoked from network); 4 Mar 2004 05:13:55 -0000 Received: from cfw2-mohta.wireless.ietf59.or.kr (HELO necom830.hpcl.titech.ac.jp) (218.37.228.188) by necom830.hpcl.titech.ac.jp with SMTP; 4 Mar 2004 05:13:55 -0000 Message-ID: <4046BB9E.8080201@necom830.hpcl.titech.ac.jp> Date: Thu, 04 Mar 2004 14:16:14 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Erik Nordmark CC: multi6@ops.ietf.org Subject: Re: Source address selection insufficient? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Erik; Yes, it is so for your proposal, which is why I asked that you assume symmetric routing in Minneapolis. Masataka Ohta From owner-multi6@ops.ietf.org Thu Mar 4 00:26:42 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29564 for ; Thu, 4 Mar 2004 00:26:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AylMu-0005Fp-AW for multi6-data@psg.com; Thu, 04 Mar 2004 05:26:00 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.30; FreeBSD) id 1AylMj-0005F4-Kb for multi6@ops.ietf.org; Thu, 04 Mar 2004 05:25:49 +0000 Received: (qmail 50224 invoked from network); 4 Mar 2004 05:25:44 -0000 Received: from cfw2-mohta.wireless.ietf59.or.kr (HELO necom830.hpcl.titech.ac.jp) (218.37.228.188) by necom830.hpcl.titech.ac.jp with SMTP; 4 Mar 2004 05:25:44 -0000 Message-ID: <4046BE62.20609@necom830.hpcl.titech.ac.jp> Date: Thu, 04 Mar 2004 14:28:02 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: john.loughney@nokia.com CC: multi6@ops.ietf.org Subject: Re: on the point of mobility & multihoming References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit john.loughney@nokia.com wrote: >>From today's session, Dave & Geoff discussed multihoming vs. mobility. In > a working group I chair, we've had similar discussions and from a transport > layer, maintaining a session during a multihoming change and a mobility change > can be quite similar. Not quite. They have certain similarity that if we are going to solve mobility issue in a way different from MIPv6, which is hopeless, minor details of M6 design will be affected. But, that's all. Connection is a transport or application dependent concept, timing of which is transport or applicaiton dependent. OTOH, timing of mobility is governed by movemenet speed of mobile hosts and service area of access routers. > I second Dave's comment that trying to solve two > things at once can be never-ending. When I tried it last time, it took about half a year to design, implement and install in the field. But as I think the design was too much mobility centric, I have modified it, part of which is the current 8plus8 proposal. > Could we restrict ourselves to multihoming, > but perhaps the authors of the proposals add a section on Mobility Considerations, > so we don't run into incompatiple solutions? As long as proposals keep the IP layer connectionless, which is of course, even MIPv6 will work automatically (though with all the defects) that there is not much to worry about. Lear already wrote in his draft : 2.1.2.1 Does your solution address mobility? : : If so, how are rendezvous handled? Can your solution handle both : locators changing at the same time? If so, please explain. Should : it? If not, how will your solution interact with MOBILEIP-V6 [3] : (MIPv6) Is it enough? Masataka Ohta From owner-multi6@ops.ietf.org Thu Mar 4 00:32:15 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00041 for ; Thu, 4 Mar 2004 00:32:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AylSc-0006R9-V3 for multi6-data@psg.com; Thu, 04 Mar 2004 05:31:54 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.30; FreeBSD) id 1AylSJ-0006IT-V5 for multi6@ops.ietf.org; Thu, 04 Mar 2004 05:31:36 +0000 Received: (qmail 50247 invoked from network); 4 Mar 2004 05:31:30 -0000 Received: from cfw2-mohta.wireless.ietf59.or.kr (HELO necom830.hpcl.titech.ac.jp) (218.37.228.188) by necom830.hpcl.titech.ac.jp with SMTP; 4 Mar 2004 05:31:30 -0000 Message-ID: <4046BFBD.6010403@necom830.hpcl.titech.ac.jp> Date: Thu, 04 Mar 2004 14:33:49 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Dave Crocker CC: multi6@ops.ietf.org Subject: Re: on the point of mobility & multihoming References: <1827B216-6D56-11D8-A08E-000A95CD987A@muada.com> <34012983.20040304131810@brandenburg.com> In-Reply-To: <34012983.20040304131810@brandenburg.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dave Crocker; > You take your laptop to the park. Nearby is a very strong, high-speed > link at a coffee shop. Some distance away is a much weaker/slower > link. > > Traffic driving by disconnects constantly changes your preferred > access point. > > This is mobile multihoming. That is not a type of multihoming M6 should address. Instead, it is purely a mobility issue and is useful for smooth handover. With mobility, M6 should address multihomed base stations, multihomed home agents, and multiple home agents at different subnets (MIPv6 does allow for multiple home agents but only in a subnet, which is mostly useless), all of which was, in my experience, handled automatically. Masataka Ohta From owner-multi6@ops.ietf.org Thu Mar 4 00:39:03 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00838 for ; Thu, 4 Mar 2004 00:39:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AylZB-0007m8-LI for multi6-data@psg.com; Thu, 04 Mar 2004 05:38:41 +0000 Received: from [131.228.20.21] (helo=mgw-x1.nokia.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AylZ2-0007fC-Kh for multi6@ops.ietf.org; Thu, 04 Mar 2004 05:38:32 +0000 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i245cPZ21520; Thu, 4 Mar 2004 07:38:25 +0200 (EET) X-Scanned: Thu, 4 Mar 2004 07:38:21 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i245cL7v032325; Thu, 4 Mar 2004 07:38:21 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00NJnshK; Thu, 04 Mar 2004 07:38:20 EET Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i245cKO23886; Thu, 4 Mar 2004 07:38:20 +0200 (EET) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 4 Mar 2004 07:38:20 +0200 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: on the point of mobility & multihoming Date: Thu, 4 Mar 2004 07:38:20 +0200 Message-ID: Thread-Topic: on the point of mobility & multihoming thread-index: AcQBqjtBOnxKXfdfTcSPHJm/LBFHsgAAGmjg From: To: , Cc: X-OriginalArrivalTime: 04 Mar 2004 05:38:20.0512 (UTC) FILETIME=[E7048E00:01C401AA] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.4 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi all, > > You take your laptop to the park. Nearby is a very strong, = high-speed > > link at a coffee shop. Some distance away is a much weaker/slower > > link. > >=20 > > Traffic driving by disconnects constantly changes your preferred > > access point. > >=20 > > This is mobile multihoming. >=20 > That is not a type of multihoming M6 should address. Instead, > it is purely a mobility issue and is useful for smooth handover. >=20 > With mobility, M6 should address multihomed base stations, > multihomed home agents, and multiple home agents at different > subnets (MIPv6 does allow for multiple home agents but only > in a subnet, which is mostly useless), all of which was, in > my experience, handled automatically. This is why I pushed back a bit on the topic of mobility. Seamless mobility is out of scope for Multi6, IMO. Session stability would be more a goal, I think. John From owner-multi6@ops.ietf.org Thu Mar 4 00:55:35 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02019 for ; Thu, 4 Mar 2004 00:55:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Aylov-000BNc-SL for multi6-data@psg.com; Thu, 04 Mar 2004 05:54:57 +0000 Received: from [163.117.136.123] (helo=smtp03.uc3m.es) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Ayloc-000BFe-Oz for multi6@ops.ietf.org; Thu, 04 Mar 2004 05:54:38 +0000 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id D5503FF8F; Thu, 4 Mar 2004 06:54:37 +0100 (CET) Received: from lolo (vpn-252-215.uc3m.es [163.117.252.215]) by smtp03.uc3m.es (Postfix) with SMTP id 2A9DAFF8E; Thu, 4 Mar 2004 06:54:36 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Erik Nordmark" , Subject: RE: Source address selection insufficient? Date: Thu, 4 Mar 2004 14:52:31 +0900 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) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Erik, thanks for reading the draft > The set of locator pairs that work when sending out from site X > might be A:X-C:Y and B:X-D:Y > but the set of locator pairs that work when sending from site Y might > be the other two: A:X-D:Y and B:X-C:Y. > > Thus the intersection of the two ingress filtering constraints is > the empty > set. > > This can happen due to normal routing as far as I can tell. > The constraints for X appear if X routes packet to C out through A > and packets to D out through B. > The constraints for Y appear if Y routes packets to A out through D > and packets to B out through C. > > Am I missing something? I guess you are not, IMHO your analysis is correct. The problem concerns what it is called in the draft "source address discovery" In this option, it is proposed that when a packet that does not comply with ingress filtering arrives to the site exit router, the router informs the host about the correct source address to use with a given destination. A big assumption made in this scenario is that the host *can* change the source address. This may be more or less simple when the host is initiating a communication, since when the hosts received the icmp error informing about the proper source address, the host may be able to retransmit the packet with a different source address. However, when the host within the multihomed site is replying to a received packet, the host cannot change the source address because the reply packet would have a different address than the initial packet, so it wouldn't be recognized as a reply of the initial packet by the initiator host. Note that this situation is not restricted to the case when two multihomed sites interact, but it is also possible when a non multihomed hosts initiates a communication with a multihomed host. For instance suppose a non multihomed host with address H1 and a host H2 in a multihomed site with addresses A:H2 and B:H2. Host H1 initiates a communication using as destination address A:H2 and source address H1 Host H2 will reply using the same addresses so, source address A:H2 and destination address H1 Now if the multihomed site is using source address discovery and internal routing within the multihomed site has determined that the route to get to H1 is through IPSB, then the reply packet will not make it and a icmp packet will be sent back to H2 informing that it has to use prefix B in the source address. Clearly H2 cannot do that and the communication will fail Possible solutions for this were considered as using HoA dest option, but this is no good because HoA dest option are only processed if a BCE exists. In any case, this wouldn't really be source address discovery anymore. So, i guess that at this point, it seems to me that the more reasonable thing to do would be to honor the host source address choice, and adapt routing to it Regards, marcelo > > If the above is true it seems like we need something other than > source address selection (relaxed filtering, source-based routing, > or locator rewriting). > > Erik > > > From owner-multi6@ops.ietf.org Thu Mar 4 01:36:02 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05510 for ; Thu, 4 Mar 2004 01:36:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AymRa-000Ime-Nq for multi6-data@psg.com; Thu, 04 Mar 2004 06:34:54 +0000 Received: from [163.117.136.122] (helo=smtp02.uc3m.es) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AymRP-000Ihm-Ud for multi6@ops.ietf.org; Thu, 04 Mar 2004 06:34:44 +0000 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id A46EFE540; Thu, 4 Mar 2004 07:34:42 +0100 (CET) Received: from lolo (vpn-252-215.uc3m.es [163.117.252.215]) by smtp02.uc3m.es (Postfix) with SMTP id E8338E53F; Thu, 4 Mar 2004 07:34:40 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Erik Nordmark" , Subject: RE: Source address selection insufficient? Date: Thu, 4 Mar 2004 15:32:36 +0900 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: x-mimeole: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Forgot to reply this part... > If the above is true it seems like we need something other than > source address selection (relaxed filtering, source-based routing, > or locator rewriting). The draft also considers another option that is called site exit discovery. In this case, the routers inform the hosts about the appropriate site exit through which the host has to send the packet so that it can reach the selected destination with the selected source address. The host then tunnels the packet through the proper exit router. This would be more like source routing rather than source address based routing, and this solution honors the source address selection performed by the host (it shouldn't have the problems of the other case) regards, marcelo > > Erik > > From owner-multi6@ops.ietf.org Thu Mar 4 02:29:55 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22764 for ; Thu, 4 Mar 2004 02:29:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AynHi-0000iQ-MI for multi6-data@psg.com; Thu, 04 Mar 2004 07:28:46 +0000 Received: from [131.160.192.2] (helo=p2.piuha.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AynHX-0000fB-GM for multi6@ops.ietf.org; Thu, 04 Mar 2004 07:28:35 +0000 Received: from piuha.net (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 10B7F6A907 for ; Thu, 4 Mar 2004 09:28:33 +0200 (EET) Message-ID: <4046DA18.6040309@piuha.net> Date: Thu, 04 Mar 2004 09:26:16 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: multi6@ops.ietf.org Subject: Re: on the point of mobility & multihoming References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I would find it unfortunate that if I was using some IETF mobility protocol on a site and it stopped working because the admins turned multihoming on. So I see at least some requirements here. --Jari From owner-multi6@ops.ietf.org Thu Mar 4 02:32:15 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23229 for ; Thu, 4 Mar 2004 02:32:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AynKG-0001Bj-EZ for multi6-data@psg.com; Thu, 04 Mar 2004 07:31:24 +0000 Received: from [131.228.20.22] (helo=mgw-x2.nokia.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AynK5-0001AZ-H3 for multi6@ops.ietf.org; Thu, 04 Mar 2004 07:31:13 +0000 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i247V8h22027; Thu, 4 Mar 2004 09:31:08 +0200 (EET) X-Scanned: Thu, 4 Mar 2004 09:30:59 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i247UxRY009777; Thu, 4 Mar 2004 09:30:59 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00cTnQaW; Thu, 04 Mar 2004 09:30:58 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i247Uu711484; Thu, 4 Mar 2004 09:30:56 +0200 (EET) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 4 Mar 2004 09:30:55 +0200 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: on the point of mobility & multihoming Date: Thu, 4 Mar 2004 09:30:55 +0200 Message-ID: Thread-Topic: on the point of mobility & multihoming thread-index: AcQBqUHrCr59i1t4Tz63avkAOudVIwAEKGHQ From: To: Cc: X-OriginalArrivalTime: 04 Mar 2004 07:30:55.0627 (UTC) FILETIME=[A1614DB0:01C401BA] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.4 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Msataka-san, > They have certain similarity that if we are going to solve mobility > issue in a way different from MIPv6, which is hopeless, minor details > of M6 design will be affected. My opinion, for what it's worth, is that we're not out to solve the mobility issue in Multi6. I don't think we want to advertise that we will work on mobility, as mobility has out of scope. If we are clever, the solution for multihoming will be useful for mobility. However, I would not like multi6 to get a storm of drafts about mobility when we are chartered to solve multihoming. > But, that's all. >=20 > Connection is a transport or application dependent concept, timing > of which is transport or applicaiton dependent. Agreed. =20 > OTOH, timing of mobility is governed by movemenet speed of mobile > hosts and service area of access routers. Agreed. > > I second Dave's comment that trying to solve two > > things at once can be never-ending. >=20 > When I tried it last time, it took about half a year to design, > implement and install in the field. But as I think the > design was too much mobility centric, I have modified it, > part of which is the current 8plus8 proposal. I don't doubt that you have solved this already, but do you think having a rash of mobility drafts claming to solve multihoming would be useful? =20 > > Could we restrict ourselves to multihoming, > > but perhaps the authors of the proposals add a section on=20 > Mobility Considerations, > > so we don't run into incompatiple solutions? >=20 > As long as proposals keep the IP layer connectionless, which is > of course, even MIPv6 will work automatically (though with all > the defects) that there is not much to worry about. >=20 > Lear already wrote in his draft >=20 > : 2.1.2.1 Does your solution address mobility? > : > : If so, how are rendezvous handled? Can your solution handle both > : locators changing at the same time? If so, please explain. = Should > : it? If not, how will your solution interact with MOBILEIP-V6 [3] > : (MIPv6) >=20 > Is it enough? It might be, but Dave's comments got me thinking about several other = things, so let me think a bit more to decide if my thoughts are baked or not. John From owner-multi6@ops.ietf.org Thu Mar 4 02:35:46 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23491 for ; Thu, 4 Mar 2004 02:35:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AynNK-0001dH-4U for multi6-data@psg.com; Thu, 04 Mar 2004 07:34:34 +0000 Received: from [131.228.20.21] (helo=mgw-x1.nokia.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AynMt-0001Yo-AP for multi6@ops.ietf.org; Thu, 04 Mar 2004 07:34:07 +0000 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i247Y5Z14645; Thu, 4 Mar 2004 09:34:05 +0200 (EET) X-Scanned: Thu, 4 Mar 2004 09:33:58 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i247XwYE015940; Thu, 4 Mar 2004 09:33:58 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 006BDycj; Thu, 04 Mar 2004 09:33:57 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i247Xu714124; Thu, 4 Mar 2004 09:33:56 +0200 (EET) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 4 Mar 2004 09:33:54 +0200 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: on the point of mobility & multihoming Date: Thu, 4 Mar 2004 09:33:54 +0200 Message-ID: Thread-Topic: on the point of mobility & multihoming thread-index: AcQBurY63vaRUqxzQA+ROv/0If/67wAAD5HA From: To: , X-OriginalArrivalTime: 04 Mar 2004 07:33:54.0641 (UTC) FILETIME=[0C14AC10:01C401BB] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.4 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Jari, > I would find it unfortunate that if I was using some > IETF mobility protocol on a site and it stopped working > because the admins turned multihoming on. >=20 > So I see at least some requirements here. So a requirement that a multi6 solution must not break mobility (MIPv6?) would be sufficient? John From owner-multi6@ops.ietf.org Thu Mar 4 02:43:07 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23844 for ; Thu, 4 Mar 2004 02:43:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AynUZ-00032N-KG for multi6-data@psg.com; Thu, 04 Mar 2004 07:42:03 +0000 Received: from [131.160.192.2] (helo=p2.piuha.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AynUP-0002zM-0q for multi6@ops.ietf.org; Thu, 04 Mar 2004 07:41:53 +0000 Received: from piuha.net (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 2AEB16A906; Thu, 4 Mar 2004 09:41:50 +0200 (EET) Message-ID: <4046DD35.9010903@piuha.net> Date: Thu, 04 Mar 2004 09:39:33 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: john.loughney@nokia.com Cc: jari.arkko@piuha.net, multi6@ops.ietf.org Subject: Re: on the point of mobility & multihoming References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit john.loughney@nokia.com wrote: > So a requirement that a multi6 solution must not break > mobility (MIPv6?) would be sufficient? That could be a starting point. I am, however, willing to make it softer if necessary. Say, if HIP folks believe they can solve both problems, that should also be allowed, assuming HIP is otherwise accepted as the MULTI6 solution. Also, I kind of agree with the comments on the list that mobility and multihoming are part of the same thing. Like someone told me a couple of days ago, becoming multi-homed is half a handoff, because you move to another place but don't move away from the previous one ;-) So I think the ability to do mobility too is a desirable feature, though perhaps not a mandatory requirement. --Jari From owner-multi6@ops.ietf.org Thu Mar 4 02:46:42 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24275 for ; Thu, 4 Mar 2004 02:46:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AynYW-0003rK-7E for multi6-data@psg.com; Thu, 04 Mar 2004 07:46:08 +0000 Received: from [131.228.20.26] (helo=mgw-x3.nokia.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AynYL-0003mm-Et for multi6@ops.ietf.org; Thu, 04 Mar 2004 07:45:57 +0000 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i247jsS24582; Thu, 4 Mar 2004 09:45:55 +0200 (EET) X-Scanned: Thu, 4 Mar 2004 09:45:45 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i247jj4R009027; Thu, 4 Mar 2004 09:45:45 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00t2lu9k; Thu, 04 Mar 2004 09:45:44 EET Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i247jh723667; Thu, 4 Mar 2004 09:45:44 +0200 (EET) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 4 Mar 2004 09:45:37 +0200 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: on the point of mobility & multihoming Date: Thu, 4 Mar 2004 09:45:37 +0200 Message-ID: Thread-Topic: on the point of mobility & multihoming thread-index: AcQBvEiAimk54BltRtS1YyFjx92T7AAABhpw From: To: Cc: X-OriginalArrivalTime: 04 Mar 2004 07:45:37.0408 (UTC) FILETIME=[AEF66800:01C401BC] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.4 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Jari, > That could be a starting point. >=20 > I am, however, willing to make it softer if necessary. Say, > if HIP folks believe they can solve both problems, that should > also be allowed, assuming HIP is otherwise accepted as the MULTI6 > solution. From a purely process point of view, that might still not be a good idea. MIPv6 is a Proposed Standard, and if requirements were loosened for HIP, you would have a draft (or perhaps an Experimental RFC) which breaks an existing Proposed Standard. Such a solution would seem sub-optimal. John From owner-multi6@ops.ietf.org Thu Mar 4 02:47:45 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24341 for ; Thu, 4 Mar 2004 02:47:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AynZo-0004FV-Qp for multi6-data@psg.com; Thu, 04 Mar 2004 07:47:28 +0000 Received: from [204.127.202.55] (helo=sccrmhc11.comcast.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AynZe-0004As-2x for multi6@ops.ietf.org; Thu, 04 Mar 2004 07:47:18 +0000 Received: from dfnjgl21 (dfnjgl21.wireless.ietf59.or.kr[218.37.228.241]) by comcast.net (sccrmhc11) with SMTP id <2004030407471501100acoj2e> (Authid: sdawkins@comcast.net); Thu, 4 Mar 2004 07:47:16 +0000 Message-ID: <004501c401bc$ec724e10$f1e425da@DFNJGL21> Reply-To: "Spencer Dawkins" From: "Spencer Dawkins" To: References: <1827B216-6D56-11D8-A08E-000A95CD987A@muada.com> <34012983.20040304131810@brandenburg.com> <4046BFBD.6010403@necom830.hpcl.titech.ac.jp> Subject: Re: on the point of mobility & multihoming Date: Thu, 4 Mar 2004 16:47:10 +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.2800.1158 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I misunderstood the original post, but let me ask the question that I thought Dave brought up: > > > You take your laptop to the park. Nearby is a very strong, high-speed "You take your laptop to the park, and sit quietly on a bench, without moving one iota. Nearby ..." > > link at a coffee shop. Some distance away is a much weaker/slower > > link. > > > > Traffic driving by disconnects constantly changes your preferred > > access point. > > > > This is mobile multihoming. With my change above, would THIS be a type of multihoming that multi6 would worry about? Spencer From owner-multi6@ops.ietf.org Thu Mar 4 02:49:08 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24439 for ; Thu, 4 Mar 2004 02:49:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Aynb7-0004UC-Jq for multi6-data@psg.com; Thu, 04 Mar 2004 07:48:49 +0000 Received: from [195.212.29.155] (helo=mtagate6.de.ibm.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Aynaw-0004SM-DU for multi6@ops.ietf.org; Thu, 04 Mar 2004 07:48:38 +0000 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by mtagate6.de.ibm.com (8.12.10/8.12.10) with ESMTP id i247maJW114970; Thu, 4 Mar 2004 07:48:36 GMT Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay01.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i247mdOQ282356; Thu, 4 Mar 2004 08:48:39 +0100 Received: from zurich.ibm.com (sig-9-145-230-158.de.ibm.com [9.145.230.158]) by collon.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id IAA57748; Thu, 4 Mar 2004 08:48:32 +0100 Message-ID: <4046219F.8555CAB8@zurich.ibm.com> Date: Wed, 03 Mar 2004 19:19:11 +0100 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: john.loughney@nokia.com CC: multi6@ops.ietf.org Subject: Re: on the point of mobility & multihoming References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_12_24 autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit John, please suggest an appropriate wording change to section 2.1.2.1 of draft-lear-multi6-things-to-think-about-01, which already mentions mobility, but doesn't quite hit your point. Brian john.loughney@nokia.com wrote: > > Dave, > > > The reasons that -- for this topic -- I think it is quite important > > to look at mobility and multihoming together are: > > > > 1. My own perusal is convincing me that they have more in common > > than they have different > > > > 2. Focusing only on one leads to assumptions that can be overly > > restrictive. For example, one might think of multhoming addresses as > > being too stable. Or one might think of mobility as only a trade > > from one address to another. > > > > In his typically frustrating style, of raising really good, basic > > points, Geoff pointed out that one can be mobile AND multihomed. > > > > If we focus on one and not the other, we are not likely to deal with > > this breadth and overlap adequately. > > If we try to kill 2 birds with one stone, we'll probably miss both. > I think we should be aware of the mobility side of the topic, but > I am not so sure we should make sure we explicitly state that we will > solve both. I do think we should be aware of the mobility properties > of any possible solutions, but I have my doubts that the IETF can > solve problems that are less than extra-crispily defined. > > thanks, > John -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM From owner-multi6@ops.ietf.org Thu Mar 4 02:49:25 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24496 for ; Thu, 4 Mar 2004 02:49:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AynbO-0004XA-9C for multi6-data@psg.com; Thu, 04 Mar 2004 07:49:06 +0000 Received: from [195.212.29.150] (helo=mtagate1.de.ibm.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Aynax-0004Se-4w for multi6@ops.ietf.org; Thu, 04 Mar 2004 07:48:39 +0000 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id i247mXpS026382; Thu, 4 Mar 2004 07:48:33 GMT Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay02.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i247mYHb256780; Thu, 4 Mar 2004 08:48:34 +0100 Received: from zurich.ibm.com (sig-9-145-230-158.de.ibm.com [9.145.230.158]) by collon.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id IAA39914; Thu, 4 Mar 2004 08:48:27 +0100 Message-ID: <40461F23.CD7E231B@zurich.ibm.com> Date: Wed, 03 Mar 2004 19:08:35 +0100 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: mbagnulo@ing.uc3m.es CC: Erik Nordmark , Noel Chiappa , multi6@ops.ietf.org Subject: Re: draft-savola-multi6-asn-pi-01.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_12_24 autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit marcelo bagnulo wrote: > > > Isn't there an issue about needing to support N global locators (used > > for external communication) plus at least one local locator? > > I may be not following, but my understanding is that Brian is proposing to > use a non routable address as identifier, so that it can be assigned > independently from the topology. Well, I wasn't really *proposing* anything. But indeed the identifier-address would still need to be globally unique, but it wouldn't need to be topologically assigned. But I think Erik would like to make it impossible to forge, as well, and that is indeed a challenge. I think we are drrifting well away from Pekka's draft here. Brian > This location independent identifier would be have a global meaning, not > local, as i understand it. > The problem is that it cannot be used as a locator. IMHO you could store it > in the DNS, as long as you make sure that it is not used as a locator. > Perhaps a new RR could be defined to store this id. > > regards, marcelo > > > In the case of NOID, would it make sense to store the local > > locator together > > with the global locators in the (global) DNS? > > > > If you can't put them in the same lookup service, then you need some > > mechanism to (securely) discover locators that are not in the lookup > > service. (As an aside, if you have such a mechanism you could also use > > it to share care-of addresses with your peer when being mobile.) > > > > But I haven't found a way to do this with acceptable security in a scheme > > like NOID. I was hoping that the hash chains in WIMP could be > > used for this > > in NOID, but I think Jari convinced me that this has problems. > > > > It can be done securely when there is a new namespace as in HIP, SIM, etc. > > > > Erik > > > > > > -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM From owner-multi6@ops.ietf.org Thu Mar 4 02:54:02 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25071 for ; Thu, 4 Mar 2004 02:54:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Aynfq-0005qJ-KS for multi6-data@psg.com; Thu, 04 Mar 2004 07:53:42 +0000 Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Aynff-0005iK-VQ for multi6@ops.ietf.org; Thu, 04 Mar 2004 07:53:32 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i247rRi5002624; Thu, 4 Mar 2004 00:53:28 -0700 (MST) Received: from bobo (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i247rOQ17738; Thu, 4 Mar 2004 08:53:25 +0100 (MET) Date: Wed, 3 Mar 2004 23:53:29 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: Source address selection insufficient? To: mbagnulo@ing.uc3m.es Cc: Erik Nordmark , multi6@ops.ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk > Note that this situation is not restricted to the case when two multihomed > sites interact, but it is also possible when a non multihomed hosts > initiates a communication with a multihomed host. > For instance suppose a non multihomed host with address H1 and a host H2 in > a multihomed site with addresses A:H2 and B:H2. > Host H1 initiates a communication using as destination address A:H2 and > source address H1 > Host H2 will reply using the same addresses so, source address A:H2 and > destination address H1 > > Now if the multihomed site is using source address discovery and internal > routing within the multihomed site has determined that the route to get to > H1 is through IPSB, then the reply packet will not make it and a icmp packet > will be sent back to H2 informing that it has to use prefix B in the source > address. Clearly H2 cannot do that and the communication will fail Yes, but in that case wouldn't the initiator retry with the other destination address? Erik From owner-multi6@ops.ietf.org Thu Mar 4 02:54:59 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25267 for ; Thu, 4 Mar 2004 02:54:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ayngo-0005yZ-ME for multi6-data@psg.com; Thu, 04 Mar 2004 07:54:42 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.30; FreeBSD) id 1AyngV-0005uV-Or for multi6@ops.ietf.org; Thu, 04 Mar 2004 07:54:23 +0000 Received: (qmail 50930 invoked from network); 4 Mar 2004 07:54:20 -0000 Received: from unknown (HELO necom830.hpcl.titech.ac.jp) (210.93.162.110) by necom830.hpcl.titech.ac.jp with SMTP; 4 Mar 2004 07:54:20 -0000 Message-ID: <4046E11A.6030701@necom830.hpcl.titech.ac.jp> Date: Thu, 04 Mar 2004 16:56:10 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: john.loughney@nokia.com CC: multi6@ops.ietf.org Subject: Re: on the point of mobility & multihoming References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_RFCI autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit John; >>They have certain similarity that if we are going to solve mobility >>issue in a way different from MIPv6, which is hopeless, minor details >>of M6 design will be affected. > My opinion, for what it's worth, is that we're not out to solve the > mobility issue in Multi6. I don't think we want to advertise that > we will work on mobility, as mobility has out of scope. If we are > clever, the solution for multihoming will be useful for mobility. > However, I would not like multi6 to get a storm of drafts about > mobility when we are chartered to solve multihoming. I fully agree with you. Proposals from those who half understand the relationships will be really annoying. Thus, in my proposal, details of possible mobility solution is dropped, though minimal explanation on why a bit is reserved is given. Masataka Ohta From owner-multi6@ops.ietf.org Thu Mar 4 03:23:37 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27852 for ; Thu, 4 Mar 2004 03:23:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ayo8L-000ANb-L8 for multi6-data@psg.com; Thu, 04 Mar 2004 08:23:09 +0000 Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Ayo8B-000AMn-4x for multi6@ops.ietf.org; Thu, 04 Mar 2004 08:22:59 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i248Mti5017974; Thu, 4 Mar 2004 01:22:55 -0700 (MST) Received: from bobo (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i248MqQ18920; Thu, 4 Mar 2004 09:22:52 +0100 (MET) Date: Thu, 4 Mar 2004 00:22:56 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: Source address selection insufficient? To: mbagnulo@ing.uc3m.es Cc: Erik Nordmark , multi6@ops.ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk > So, i guess that at this point, it seems to me that the more reasonable > thing to do would be to honor the host source address choice, and adapt > routing to it That seems to be the robust approach. > The draft also considers another option that is called site exit discovery. > > In this case, the routers inform the hosts about the appropriate site exit > through which the host has to send the packet so that it can reach the > selected destination with the selected source address. > The host then tunnels the packet through the proper exit router. > > This would be more like source routing rather than source address based > routing, and this solution honors the source address selection performed by > the host (it shouldn't have the problems of the other case) I think this is just a particular implementation of source-based routing - implemented using an overlay between the hosts and the border routers. If we are going down the source-based routing architecture path, I think it is desirable to do this the right way by starting with tunnels between border routers and then increasing the domain of routers that do source-based routing following this picture in the draft: Multiple site exits | | | | -----+-----+-----+-----+----- ( ) ( Source based routing domain ) ( ) ----+----+----+----+----+---- ( ) ( Generic routing domain ) ( ) ----------------------------- The host-to-border overlay is undesirable because you have to change all the hosts, and once you've put this part of routing in the hosts it will be hard to evolve the routing and the adminstrator might loose policy control as a result. But that is mostly my gut feel. Erik From owner-multi6@ops.ietf.org Thu Mar 4 05:54:02 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08002 for ; Thu, 4 Mar 2004 05:54:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AyqSw-0005UJ-3h for multi6-data@psg.com; Thu, 04 Mar 2004 10:52:34 +0000 Received: from [138.4.2.7] (helo=mail.dit.upm.es) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AyqRw-0005JU-Nd for multi6@ops.ietf.org; Thu, 04 Mar 2004 10:51:32 +0000 Received: from jungla.dit.upm.es (IDENT:MCP1pFWgvwefYbA8/uGm0LP4H8coDQC/@jungla-sdit.dit.upm.es [138.4.5.11]) by mail.dit.upm.es (8.11.6/8.9.3) with ESMTP id i24ApV231504 for ; Thu, 4 Mar 2004 11:51:31 +0100 Received: from curie (curie.dit.upm.es [138.4.7.76]) by jungla.dit.upm.es (8.11.6/8.9.3) with ESMTP id i24ApVS19651 for ; Thu, 4 Mar 2004 11:51:31 +0100 Received: from atd by curie with local (Exim 3.36 #1 (Debian)) id 1AyqRi-0001Sm-00 for ; Thu, 04 Mar 2004 11:51:18 +0100 Date: Thu, 4 Mar 2004 11:51:18 +0100 From: Antonio Tapiador del Dujo To: multi6@ops.ietf.org Subject: Re: Source address selection insufficient? Message-ID: <20040304105118.GA5535@curie> Mail-Followup-To: multi6@ops.ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.5.1+cvs20040105i X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit El jueves, 04 de marzo de 2004, a las 14:52:31, marcelo bagnulo escribió: > > The problem concerns what it is called in the draft "source address > discovery" > In this option, it is proposed that when a packet that does not comply with > ingress filtering arrives to the site exit router, the router informs the > host about the correct source address to use with a given destination. > > A big assumption made in this scenario is that the host *can* change the > source address. > This may be more or less simple when the host is initiating a communication, > since when the hosts received the icmp error informing about the proper > source address, the host may be able to retransmit the packet with a > different source address. > > However, when the host within the multihomed site is replying to a received > packet, the host cannot change the source address because the reply packet > would have a different address than the initial packet, so it wouldn't be > recognized as a reply of the initial packet by the initiator host. What about marking packets that may be source-address-corrected, using an extension header, or maybe a single bit? The multihomed host knows which packets can be corrected, and which ones must not. Legacy hosts would not be corrected, their traffic would be source address routed or managed by other site exit solution. Upper layers solutions may use this mark for their own needs. Greetings, Antonio. -- EuropeSwPatentFree - http://EuropeSwPatentFree.hispalinux.es From owner-multi6@ops.ietf.org Thu Mar 4 07:29:55 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15550 for ; Thu, 4 Mar 2004 07:29:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ayry4-000Iww-BM for multi6-data@psg.com; Thu, 04 Mar 2004 12:28:48 +0000 Received: from [131.228.20.26] (helo=mgw-x3.nokia.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Ayrxy-000Ivt-TV for multi6@ops.ietf.org; Thu, 04 Mar 2004 12:28:43 +0000 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i24CScS09989; Thu, 4 Mar 2004 14:28:38 +0200 (EET) X-Scanned: Thu, 4 Mar 2004 14:28:32 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i24CSWin006784; Thu, 4 Mar 2004 14:28:32 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00smNX91; Thu, 04 Mar 2004 14:28:31 EET Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i24CSVO11489; Thu, 4 Mar 2004 14:28:31 +0200 (EET) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 4 Mar 2004 14:28:30 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 4 Mar 2004 14:28:31 +0200 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: on the point of mobility & multihoming Date: Thu, 4 Mar 2004 14:28:30 +0200 Message-ID: Thread-Topic: on the point of mobility & multihoming thread-index: AcQB4rVo9+vjp3vqR2234n2JFWi3dwAAVP5g From: To: Cc: , X-OriginalArrivalTime: 04 Mar 2004 12:28:31.0153 (UTC) FILETIME=[341A5A10:01C401E4] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Dave, > jlnc> So a requirement that a multi6 solution must not break > jlnc> mobility (MIPv6?) would be sufficient? >=20 > as for my own perspective, no, this would not be enough. >=20 > the infrastructure approach that is the basis for mipv6 has some > serious deployment and use challenges. >=20 > more directly, it looks quite reasonable to use a single, rather > small, set of mechanisms and solve substantial portions of both > problem spaces. >=20 > it is by no means sure that this will actually work. the problem is > that the possibility that it _will_) work is not very much part of the > discussion, yet it should be. the potential benefits of a common > mechanism are too large to ignore. I still worry about feature-creep in Multi6. Should a multi6 be a floor polish & a desert topping? =20 John From owner-multi6@ops.ietf.org Thu Mar 4 07:45:47 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16317 for ; Thu, 4 Mar 2004 07:45:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AysEA-000Liq-56 for multi6-data@psg.com; Thu, 04 Mar 2004 12:45:26 +0000 Received: from [208.184.79.7] (helo=joy.songbird.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AyrmI-000HRG-Ls for multi6@ops.ietf.org; Thu, 04 Mar 2004 12:16:38 +0000 Received: from BBFUJIP.brandenburg.com (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i24CPMd07145; Thu, 4 Mar 2004 04:25:22 -0800 Date: Thu, 4 Mar 2004 21:16:25 +0900 From: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <1799885891.20040304211625@brandenburg.com> To: john.loughney@nokia.com CC: jari.arkko@piuha.net, multi6@ops.ietf.org Subject: Re: on the point of mobility & multihoming In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-2.6 required=5.0 tests=AWL,BAYES_00,PRIORITY_NO_NAME autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit john, jlnc> So a requirement that a multi6 solution must not break jlnc> mobility (MIPv6?) would be sufficient? as for my own perspective, no, this would not be enough. the infrastructure approach that is the basis for mipv6 has some serious deployment and use challenges. more directly, it looks quite reasonable to use a single, rather small, set of mechanisms and solve substantial portions of both problem spaces. it is by no means sure that this will actually work. the problem is that the possibility that it _will_) work is not very much part of the discussion, yet it should be. the potential benefits of a common mechanism are too large to ignore. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-multi6@ops.ietf.org Thu Mar 4 07:53:28 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16936 for ; Thu, 4 Mar 2004 07:53:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AysLN-000N3R-O4 for multi6-data@psg.com; Thu, 04 Mar 2004 12:52:53 +0000 Received: from [208.184.79.7] (helo=joy.songbird.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Ays6D-000KIY-AJ for multi6@ops.ietf.org; Thu, 04 Mar 2004 12:37:13 +0000 Received: from BBFUJIP.brandenburg.com (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i24Cjxd08323; Thu, 4 Mar 2004 04:45:59 -0800 Date: Thu, 4 Mar 2004 21:37:04 +0900 From: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <586059915.20040304213704@brandenburg.com> To: john.loughney@nokia.com CC: jari.arkko@piuha.net, multi6@ops.ietf.org Subject: Re: on the point of mobility & multihoming In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-2.9 required=5.0 tests=AWL,BAYES_00,PRIORITY_NO_NAME autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] john, jlnc> Dave, jlnc> I still worry about feature-creep in Multi6. Should a multi6 be jlnc> a floor polish & a desert topping? only if you want to lick the floor. but seriously, you cannot imagine how much I share your concern for feature creep. what i've discovered in this topic is an equal fear of the potential to have too much redundant, and possibly conflicting, mechanism, because related problems were not solved with common mechanism. but, yes, the mantra of: timely, simple, useful is paramount. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-multi6@ops.ietf.org Thu Mar 4 08:32:27 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18589 for ; Thu, 4 Mar 2004 08:32:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ayswc-00024L-8p for multi6-data@psg.com; Thu, 04 Mar 2004 13:31:22 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.30; FreeBSD) id 1Ayswb-000245-8W for multi6@ops.ietf.org; Thu, 04 Mar 2004 13:31:21 +0000 Received: (qmail 52324 invoked from network); 4 Mar 2004 13:31:22 -0000 Received: from cfw2-mohta.wireless.ietf59.or.kr (HELO necom830.hpcl.titech.ac.jp) (218.37.227.104) by necom830.hpcl.titech.ac.jp with SMTP; 4 Mar 2004 13:31:22 -0000 Message-ID: <4047302E.20502@necom830.hpcl.titech.ac.jp> Date: Thu, 04 Mar 2004 22:33:34 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: john.loughney@nokia.com CC: dcrocker@brandenburg.com, jari.arkko@piuha.net, multi6@ops.ietf.org Subject: Re: on the point of mobility & multihoming References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit John; > I still worry about feature-creep in Multi6. Should a multi6 be > a floor polish & a desert topping? That happened with IPv6 by collective half-wisdoms. It often occurs when chairs waste time on discussions of abstract nonsenses. Masataka Ohta From owner-multi6@ops.ietf.org Thu Mar 4 08:37:58 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18853 for ; Thu, 4 Mar 2004 08:37:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ayt2s-0002vX-0M for multi6-data@psg.com; Thu, 04 Mar 2004 13:37:50 +0000 Received: from [195.212.29.151] (helo=mtagate2.de.ibm.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Ayt2q-0002vI-II for multi6@ops.ietf.org; Thu, 04 Mar 2004 13:37:48 +0000 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id i24DbIRT107712; Thu, 4 Mar 2004 13:37:18 GMT Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay02.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i24DbIHb266766; Thu, 4 Mar 2004 14:37:19 +0100 Received: from zurich.ibm.com (sig-9-145-242-185.de.ibm.com [9.145.242.185]) by collon.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id OAA58312; Thu, 4 Mar 2004 14:37:14 +0100 Message-ID: <4047312B.A81DD566@zurich.ibm.com> Date: Thu, 04 Mar 2004 14:37:47 +0100 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: Iljitsch van Beijnum CC: Margaret Wasserman , multi6@ops.ietf.org, Eliot Lear Subject: Re: Comments on WIMP and MTU Handling References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit So, we have found a new item for draft-lear-multi6-things-to-think-about-01 under "2.3.3 Does your solution expand the size of an IP packet?" such as: What impact does your solution have on MTU size issues? Can the IPv6 standard MTU of 1280 bytes be supported? Brian Iljitsch van Beijnum wrote: > > On 3-mrt-04, at 1:58, Margaret Wasserman wrote: > > > If an ID/Loc layer will exist conceptually below the > > fragmentation/reassembly function, it is problematic for it to add > > optional bytes to the packet (such as a header or IP option that may > > or may not be included). There are some possibilities for dealing > > with this: > > > - Run the ID/Loc separation between the Network and Transport > > layers instead. > > As opposed to network and link or transport and application??? > > Doing address agility first and then fragmentation makes implementing > the former in a middlebox much harder, if not impossible. > > > - Reduce the MTU presented to upper layers, so that there is > > always room for the optional header. > > Also problematic. What if the MTU already is 1280 or not much larger, > and the new MTU would be lower than 1280? But ignoring this for a > moment, it should be just fine to have the transport learn a small MTU > at one point in time (because a large option needs to be added) and > then at a later time the full MTU is available because there is no need > for an option at this time. > > An alternative would be to fragment the segment coming from the > transport layer without telling the transport layer about this, and > then add the option to one of the fragments. This makes it necessary > for the part of the stack doing the fragmenting to be aware of the > multihoming solution, though. > > Another way to get around this is to send the options as independent > messages. However, since firewalls won't recognize these packets they > may not make it to the destination host. Solution for that would be to > add a transport layer header without any payload data so firewalls can > see which session the packet belongs to (if any). -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM From owner-multi6@ops.ietf.org Thu Mar 4 09:25:19 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21400 for ; Thu, 4 Mar 2004 09:25:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Aytkj-000B51-4n for multi6-data@psg.com; Thu, 04 Mar 2004 14:23:09 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.30; FreeBSD) id 1Aytki-000B4l-4X for multi6@ops.ietf.org; Thu, 04 Mar 2004 14:23:08 +0000 Received: (qmail 52544 invoked from network); 4 Mar 2004 14:23:09 -0000 Received: from unknown (HELO necom830.hpcl.titech.ac.jp) (210.93.162.110) by necom830.hpcl.titech.ac.jp with SMTP; 4 Mar 2004 14:23:09 -0000 Message-ID: <40473C34.3080802@necom830.hpcl.titech.ac.jp> Date: Thu, 04 Mar 2004 23:24:52 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Brian E Carpenter CC: Iljitsch van Beijnum , Margaret Wasserman , multi6@ops.ietf.org, Eliot Lear Subject: Re: Comments on WIMP and MTU Handling References: <4047312B.A81DD566@zurich.ibm.com> In-Reply-To: <4047312B.A81DD566@zurich.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_RFCI autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Brian; > What impact does your solution have on MTU size issues? Can the IPv6 > standard MTU of 1280 bytes be supported? It is trivially easy to do so with fragmentation (see how IPv6 standard tunneling support 1280B of MTU, which actually is a fallacy) that the statement should be: What impact does your solution have on MTU size issues? Can the IPv6 standard MTU of 1280 bytes be supported without additional fragmentations at any layer? Masataka Ohta From owner-multi6@ops.ietf.org Thu Mar 4 12:33:23 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03479 for ; Thu, 4 Mar 2004 12:33:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Aywhq-000Erb-R0 for multi6-data@psg.com; Thu, 04 Mar 2004 17:32:22 +0000 Received: from [68.6.19.124] (helo=fed1mtao07.cox.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Aywho-000Er9-Q0 for multi6@ops.ietf.org; Thu, 04 Mar 2004 17:32:20 +0000 Received: from momo ([68.2.220.20]) by fed1mtao07.cox.net (InterMail vM.5.01.06.08 201-253-122-130-108-20031117) with SMTP id <20040304173218.SJWA10898.fed1mtao07.cox.net@momo>; Thu, 4 Mar 2004 12:32:18 -0500 From: "Kanchei Loa" To: Cc: Subject: RE: on the point of mobility & multihoming Date: Thu, 4 Mar 2004 10:32:12 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > Multiaddress mulithoming and mobility solutions must incorporate the > > following mechanisms: > > > > 1. multiplexing in the presence of more than one address pair > > 2. adding/removing addresses > > Well, there is a difference in the requirements in this point in mobility > and multihoming. > Both needs a handover mechanism, to stop using a locator and > start using an > alternative one, but strictly speaking, the locator set involved in a > multihoming solution can be fixed, becuase it is known a priori, for > instance consider noid. In mobility, this is not so, because you > don't know > which will be your future locators. > That might not be the case in non-mobile dynamic ad hoc connection for exit routers as specified in Dave Croker's scenario, whose locator set is not fixed and known priori. The dynamic comes from the nature of the network topology (wireless), not from mobility. If the line between exit router and ISP is changed to dotted lines (wireless) instead of one solid line (wired) in Geoff's "An Architectural View of Multi6 proposals" presentation, then the difference between mobility and multihoming is almost null. --------- Kanchei Loa loa@ieee.org From owner-multi6@ops.ietf.org Thu Mar 4 18:20:08 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20655 for ; Thu, 4 Mar 2004 18:20:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Az24f-0009IQ-JW for multi6-data@psg.com; Thu, 04 Mar 2004 23:16:17 +0000 Received: from [68.6.19.123] (helo=fed1mtao08.cox.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Az24e-0009I4-G0 for multi6@ops.ietf.org; Thu, 04 Mar 2004 23:16:16 +0000 Received: from momo ([68.2.220.20]) by fed1mtao08.cox.net (InterMail vM.5.01.06.08 201-253-122-130-108-20031117) with SMTP id <20040304231614.YWIO5081.fed1mtao08.cox.net@momo>; Thu, 4 Mar 2004 18:16:14 -0500 From: "Kanchei Loa" To: "Masataka Ohta" Cc: Subject: RE: on the point of mobility & multihoming Date: Thu, 4 Mar 2004 16:16:11 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <4046E11A.6030701@necom830.hpcl.titech.ac.jp> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > >>They have certain similarity that if we are going to solve mobility > >>issue in a way different from MIPv6, which is hopeless, minor details > >>of M6 design will be affected. > > > My opinion, for what it's worth, is that we're not out to solve the > > mobility issue in Multi6. I don't think we want to advertise that > > we will work on mobility, as mobility has out of scope. If we are > > clever, the solution for multihoming will be useful for mobility. > > However, I would not like multi6 to get a storm of drafts about > > mobility when we are chartered to solve multihoming. > > I fully agree with you. > > Proposals from those who half understand the relationships > will be really annoying. > > Thus, in my proposal, details of possible mobility solution is > dropped, though minimal explanation on why a bit is reserved is > given. > > Masataka Ohta In my opinion, you just hit an important issue of multi6 architecture, which this WG is supposed to work on first. If we take Dave Croker's scenario (suggested by Geoff Huston) and generalize it, the problem space is the same as depicted in Geoff's slide (page 3) of "An Architectural View of Multi6 proposals" except that the solid line (wired fixed connection) between the exit route and ISP is replace by dotted lines (wireless dynamic connections). In this architecture, mobility is just a special case of "dynamic ad hoc multihoming", which has timing restriction on updates and discovery. (You don't have to call it mobility if that is more IETF political correct). In Dave's scenario, from IP network's point of view, there is no difference between a laptop sitting on a bench switching among ISPs because of interference and a laptop sitting in a car that is moving back and forth among ISPs. Should multi6 architecture encompass wireless connections between the exit router and IPS? Or, Dave Croker's scenario is too far away in the future to be included in multi6 architecture, which has been focusing on traditional IP multihoming with fixed connections only? It is up to the WG to decide. But the architecture document should spell out the rational choice. The "uncomfortable" wireless issues won't goes away if we just choose to ignore them or call it something else. ------------ Kanchei Loa loa@ieee.org From owner-multi6@ops.ietf.org Fri Mar 5 02:25:21 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23386 for ; Fri, 5 Mar 2004 02:25:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Az9fx-000GIN-Fb for multi6-data@psg.com; Fri, 05 Mar 2004 07:23:17 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.30; FreeBSD) id 1Az9fb-000GG0-57 for multi6@ops.ietf.org; Fri, 05 Mar 2004 07:22:55 +0000 Received: (qmail 56036 invoked from network); 5 Mar 2004 07:23:09 -0000 Received: from comm.bb.twcu.ac.jp (HELO necom830.hpcl.titech.ac.jp) (202.11.168.64) by necom830.hpcl.titech.ac.jp with SMTP; 5 Mar 2004 07:23:09 -0000 Message-ID: <40482B3C.2000600@necom830.hpcl.titech.ac.jp> Date: Fri, 05 Mar 2004 16:24:44 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Kanchei Loa CC: multi6@ops.ietf.org Subject: Re: on the point of mobility & multihoming References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Kanchei Loa wrote: >>Thus, in my proposal, details of possible mobility solution is >>dropped, though minimal explanation on why a bit is reserved is >>given. >> >> Masataka Ohta > > > In my opinion, you just hit an important issue of multi6 architecture, which > this WG is supposed to work on first. I'm afraid you miss my points. > If we take Dave Croker's scenario > (suggested by Geoff Huston) and generalize it, the problem space is the same > as depicted in Geoff's slide (page 3) of "An Architectural View of Multi6 > proposals" Dave and Geoff completely misunderstand the relationships between M6 and MIP. Worse, they don't recognize that shim layer approaches are making the the IP layer connection oriented by let it maintain states of connections. Geoff's presentation is nothing more than rhetorical combinations of layers without analyzing architectural implications. Ignore their documents. Masataka Ohta From owner-multi6@ops.ietf.org Fri Mar 5 04:12:38 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27253 for ; Fri, 5 Mar 2004 04:12:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AzBMe-00090t-Oq for multi6-data@psg.com; Fri, 05 Mar 2004 09:11:28 +0000 Received: from [195.212.29.156] (helo=mtagate7.de.ibm.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AzBMT-0008z2-CL for multi6@ops.ietf.org; Fri, 05 Mar 2004 09:11:17 +0000 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by mtagate7.de.ibm.com (8.12.10/8.12.10) with ESMTP id i259AeRm086300; Fri, 5 Mar 2004 09:10:40 GMT Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay01.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i259AhqO256192; Fri, 5 Mar 2004 10:10:43 +0100 Received: from zurich.ibm.com (sig-9-145-244-231.de.ibm.com [9.145.244.231]) by collon.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA27816; Fri, 5 Mar 2004 10:10:37 +0100 Message-ID: <4048442E.84F088C0@zurich.ibm.com> Date: Fri, 05 Mar 2004 10:11:10 +0100 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: Masataka Ohta CC: multi6@ops.ietf.org Subject: Re: on the point of mobility & multihoming References: <40482B3C.2000600@necom830.hpcl.titech.ac.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Masataka, Masataka Ohta wrote: > > Kanchei Loa wrote: > > >>Thus, in my proposal, details of possible mobility solution is > >>dropped, though minimal explanation on why a bit is reserved is > >>given. > >> > >> Masataka Ohta > > > > > > In my opinion, you just hit an important issue of multi6 architecture, which > > this WG is supposed to work on first. > > I'm afraid you miss my points. > > > If we take Dave Croker's scenario > > (suggested by Geoff Huston) and generalize it, the problem space is the same > > as depicted in Geoff's slide (page 3) of "An Architectural View of Multi6 > > proposals" > > Dave and Geoff completely misunderstand the relationships > between M6 and MIP. > > Worse, they don't recognize that shim layer approaches are > making the the IP layer connection oriented by let it maintain > states of connections. Please do not over-simplify and please do not personalize this discussion. We all understand, I assume, that site multihoming implies state. The exact nature of the state, and how it is maintained and deleted, depends on the layer (or wedge) that maintains it. The architectural analysis is not supposed to *define* the solution, i.e. choose a particular model for the multihoming state. It is supposed to analyze the options available and the arguments for and against them. > Geoff's presentation is nothing more than rhetorical combinations > of layers without analyzing architectural implications. Please do not insult our colleague. This was a first presentation and we know that a lot more work remains. > Ignore their documents. Please do not make such rude statements on this mailing list. Regards Brian Carpenter co-chair From owner-multi6@ops.ietf.org Fri Mar 5 04:16:58 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27409 for ; Fri, 5 Mar 2004 04:16:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AzBRj-0009hk-RG for multi6-data@psg.com; Fri, 05 Mar 2004 09:16:43 +0000 Received: from [195.212.29.150] (helo=mtagate1.de.ibm.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AzBRY-0009gb-Gt for multi6@ops.ietf.org; Fri, 05 Mar 2004 09:16:32 +0000 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id i259GUpS124886 for ; Fri, 5 Mar 2004 09:16:31 GMT Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay01.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i259GYqO269184 for ; Fri, 5 Mar 2004 10:16:34 +0100 Received: from zurich.ibm.com (sig-9-145-244-231.de.ibm.com [9.145.244.231]) by collon.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA21564 for ; Fri, 5 Mar 2004 10:16:27 +0100 Message-ID: <4048458D.8B454C19@zurich.ibm.com> Date: Fri, 05 Mar 2004 10:17:01 +0100 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: multi6@ops.ietf.org Subject: Feature creep avoidance [Re: on the point of mobility & multihoming] References: <586059915.20040304213704@brandenburg.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit It's to avoid featurism that RFC 3582 describes "goals" not "requirements" and that Eliot's draft describes "things to think about." When we have a complete architectural analysis, I hope we will be able to extract from that what are the necessary and sufficient components of a solution, and stop there. Brian Dave Crocker wrote: > > [ post by non-subscriber. with the massive amount of spam, it is easy to > miss > and therefore delete posts by non-subscribers. if you wish to regularly > post from an address that is not subscribed to this mailing list, send a > message to -owner@ops.ietf.org and ask to have the alternate > address added to the list of addresses from which submissions are > automatically accepted. ] > > john, > > jlnc> Dave, > > jlnc> I still worry about feature-creep in Multi6. Should a multi6 be > jlnc> a floor polish & a desert topping? > > only if you want to lick the floor. > > but seriously, you cannot imagine how much I share your concern for > feature creep. > > what i've discovered in this topic is an equal fear of the potential > to have too much redundant, and possibly conflicting, mechanism, > because related problems were not solved with common mechanism. > > but, yes, the mantra of: timely, simple, useful > is paramount. > > d/ > -- > Dave Crocker > Brandenburg InternetWorking > Sunnyvale, CA USA From owner-multi6@ops.ietf.org Fri Mar 5 04:26:08 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27732 for ; Fri, 5 Mar 2004 04:26:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AzBaG-000BAt-Hp for multi6-data@psg.com; Fri, 05 Mar 2004 09:25:32 +0000 Received: from [195.212.29.154] (helo=mtagate5.de.ibm.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AzBa5-000B9D-9s for multi6@ops.ietf.org; Fri, 05 Mar 2004 09:25:21 +0000 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by mtagate5.de.ibm.com (8.12.10/8.12.10) with ESMTP id i259PJe2069626 for ; Fri, 5 Mar 2004 09:25:20 GMT Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay01.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i259PNqO230786 for ; Fri, 5 Mar 2004 10:25:23 +0100 Received: from zurich.ibm.com (sig-9-145-244-231.de.ibm.com [9.145.244.231]) by collon.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA21708 for ; Fri, 5 Mar 2004 10:25:17 +0100 Message-ID: <4048479E.AC99300D@zurich.ibm.com> Date: Fri, 05 Mar 2004 10:25:50 +0100 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: multi6@ops.ietf.org Subject: Re: on the point of mobility & multihoming References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit below... Kanchei Loa wrote: > > > >>They have certain similarity that if we are going to solve mobility > > >>issue in a way different from MIPv6, which is hopeless, minor details > > >>of M6 design will be affected. > > > > > My opinion, for what it's worth, is that we're not out to solve the > > > mobility issue in Multi6. I don't think we want to advertise that > > > we will work on mobility, as mobility has out of scope. If we are > > > clever, the solution for multihoming will be useful for mobility. > > > However, I would not like multi6 to get a storm of drafts about > > > mobility when we are chartered to solve multihoming. > > > > I fully agree with you. > > > > Proposals from those who half understand the relationships > > will be really annoying. > > > > Thus, in my proposal, details of possible mobility solution is > > dropped, though minimal explanation on why a bit is reserved is > > given. > > > > Masataka Ohta > > In my opinion, you just hit an important issue of multi6 architecture, which > this WG is supposed to work on first. If we take Dave Croker's scenario > (suggested by Geoff Huston) and generalize it, the problem space is the same > as depicted in Geoff's slide (page 3) of "An Architectural View of Multi6 > proposals" except that the solid line (wired fixed connection) between the > exit route and ISP is replace by dotted lines (wireless dynamic > connections). > > In this architecture, mobility is just a special case of "dynamic ad hoc > multihoming", which has timing restriction on updates and discovery. (You > don't have to call it mobility if that is more IETF political correct). In > Dave's scenario, from IP network's point of view, there is no difference > between a laptop sitting on a bench switching among ISPs because of > interference and a laptop sitting in a car that is moving back and forth > among ISPs. > > Should multi6 architecture encompass wireless connections between the exit > router and IPS? Or, Dave Croker's scenario is too far away in the future to > be included in multi6 architecture, which has been focusing on traditional > IP multihoming with fixed connections only? It is up to the WG to decide. > But the architecture document should spell out the rational choice. The > "uncomfortable" wireless issues won't goes away if we just choose to ignore > them or call it something else. Actually, it isn't up to the WG to decide. We are chartered to deal with _site multihoming_. That is definitely a different problem space from host multihoming in the form of ISP roaming. (Also, I don't see what wireless has to do with it. If I sit in front of two Ethernet plugs leading to two ISPs, and move my connector from one to the other every two minutes, the problem is the same - but it is *not* site multihoming.) Brian Brian From owner-multi6@ops.ietf.org Fri Mar 5 04:34:36 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28295 for ; Fri, 5 Mar 2004 04:34:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AzBih-000CgU-F5 for multi6-data@psg.com; Fri, 05 Mar 2004 09:34:15 +0000 Received: from [195.212.29.151] (helo=mtagate2.de.ibm.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AzBiW-000Cep-EC for multi6@ops.ietf.org; Fri, 05 Mar 2004 09:34:04 +0000 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id i259U4RT101484; Fri, 5 Mar 2004 09:30:04 GMT Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay02.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i259U5bM261904; Fri, 5 Mar 2004 10:30:05 +0100 Received: from zurich.ibm.com (sig-9-145-244-231.de.ibm.com [9.145.244.231]) by collon.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA27674; Fri, 5 Mar 2004 10:30:01 +0100 Message-ID: <404848BA.9D6C71AE@zurich.ibm.com> Date: Fri, 05 Mar 2004 10:30:34 +0100 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: Antonio Tapiador del Dujo CC: multi6@ops.ietf.org Subject: Re: Source address selection insufficient? References: <20040304105118.GA5535@curie> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Antonio Tapiador del Dujo wrote: > = > El jueves, 04 de marzo de 2004, a las 14:52:31, marcelo bagnulo escribi= =F3: > > > > The problem concerns what it is called in the draft "source address > > discovery" > > In this option, it is proposed that when a packet that does not compl= y with > > ingress filtering arrives to the site exit router, the router informs= the > > host about the correct source address to use with a given destination= =2E > > > > A big assumption made in this scenario is that the host *can* change = the > > source address. > > This may be more or less simple when the host is initiating a communi= cation, > > since when the hosts received the icmp error informing about the prop= er > > source address, the host may be able to retransmit the packet with a > > different source address. > > > > However, when the host within the multihomed site is replying to a re= ceived > > packet, the host cannot change the source address because the reply p= acket > > would have a different address than the initial packet, so it wouldn'= t be > > recognized as a reply of the initial packet by the initiator host. > = > What about marking packets that may be source-address-corrected, > using an extension header, or maybe a single bit? > = > The multihomed host knows which packets can be corrected, and which > ones must not. > Legacy hosts would not be corrected, their traffic would be source > address routed or managed by other site exit solution. I definitely feel that marking packets would make this type of solution more robust in some ways, but it has distinct problems - we don't have a bit for this, and we really want to avoid extension headers if we can (MTU size issues, etc.) > = > Upper layers solutions may use this mark for their own needs. I suspect ULPs will want to avoid knowing anything about MH events, unless you include the transport layer as a ULP. Brian From owner-multi6@ops.ietf.org Fri Mar 5 04:45:26 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28877 for ; Fri, 5 Mar 2004 04:45:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AzBt5-000EqG-Lh for multi6-data@psg.com; Fri, 05 Mar 2004 09:44:59 +0000 Received: from [203.50.0.6] (helo=kahuna.telstra.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AzBs8-000EeI-3U for multi6@ops.ietf.org; Fri, 05 Mar 2004 09:44:00 +0000 Received: from gih505.telstra.net (kahuna.telstra.net [203.50.0.6]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id i259hauX027370; Fri, 5 Mar 2004 20:43:52 +1100 (EST) (envelope-from gih@telstra.net) Message-Id: <6.0.1.1.2.20040305203801.01cd0ec0@localhost> X-Sender: gih@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Fri, 05 Mar 2004 20:43:23 +1100 To: Brian E Carpenter , multi6@ops.ietf.org From: Geoff Huston Subject: Re: on the point of mobility & multihoming In-Reply-To: <4048479E.AC99300D@zurich.ibm.com> References: <4048479E.AC99300D@zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk > > In my opinion, you just hit an important issue of multi6 architecture, > which > > this WG is supposed to work on first. If we take Dave Croker's scenario > > (suggested by Geoff Huston) and generalize it, the problem space is the > same > > as depicted in Geoff's slide (page 3) of "An Architectural View of Multi6 > > proposals" except that the solid line (wired fixed connection) between the > > exit route and ISP is replace by dotted lines (wireless dynamic > > connections). I did stress in my presentation to the wg that slide 3 was misleading in a number of ways. There may be multiple parties to the communication, and they may be simultaneous or spread over time. The "site exit" router may not know its role with respect to a particular host in some environments. Also, Erik Nordmark pointed out that there may be more than one site exit router in the path. My point was that while the diagram assisted with describing the space, it was a diagram that included some assumptions that are not going to hold in all cases. regards, Geoff From owner-multi6@ops.ietf.org Sat Mar 6 06:50:48 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13841 for ; Sat, 6 Mar 2004 06:50:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AzaHi-0006ub-3f for multi6-data@psg.com; Sat, 06 Mar 2004 11:48:02 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.30; FreeBSD) id 1AzaHW-0006m5-Pb for multi6@ops.ietf.org; Sat, 06 Mar 2004 11:47:50 +0000 Received: (qmail 61703 invoked from network); 6 Mar 2004 11:48:26 -0000 Received: from yahoobb219178198019.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.178.198.19) by necom830.hpcl.titech.ac.jp with SMTP; 6 Mar 2004 11:48:26 -0000 Message-ID: <4049BAEF.8000009@necom830.hpcl.titech.ac.jp> Date: Sat, 06 Mar 2004 20:50:07 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Brian E Carpenter CC: multi6@ops.ietf.org Subject: Re: on the point of mobility & multihoming References: <40482B3C.2000600@necom830.hpcl.titech.ac.jp> <4048442E.84F088C0@zurich.ibm.com> In-Reply-To: <4048442E.84F088C0@zurich.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Brian E Carpenter; >>Dave and Geoff completely misunderstand the relationships >>between M6 and MIP. >> >>Worse, they don't recognize that shim layer approaches are >>making the the IP layer connection oriented by let it maintain >>states of connections. > Please do not over-simplify and please do not personalize this > discussion. You over-simplify and personalize the discussion. Don't to that. The over-simplification, for example, is to just say "state" even though the text you quoted says "states of connecitons". It is interprested as an intentional rude behaviour, regadless of whether you said "please" several times. > We all understand, I assume, that site > multihoming implies state. You are lying of the worst lie to state the half truth. The proper statement on state is that "multihoming for connection implies states of connections". > The architectural analysis is not supposed to *define* the solution, Thank you for acknowledging you are doing nothing other than abstract nonsense on impossible options. >>Geoff's presentation is nothing more than rhetorical combinations >>of layers without analyzing architectural implications. > Please do not insult our colleague. It is a proper critic on a presentation of someone who you yourself choose. If the quality of document or presentation from the person you yourself choose, it is perfectly OK to say the document or the presentation is poor with reasons such as "hetorical combinations of layers without analyzing architectural implications". >>Ignore their documents. > Please do not make such rude statements on this mailing list. You are rude. You give any technical point, save for the half truth above. Masataka Ohta From owner-multi6@ops.ietf.org Sat Mar 6 07:11:29 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14437 for ; Sat, 6 Mar 2004 07:11:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Azads-000C3C-AT for multi6-data@psg.com; Sat, 06 Mar 2004 12:10:56 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.30; FreeBSD) id 1Azadh-000C02-Fw for multi6@ops.ietf.org; Sat, 06 Mar 2004 12:10:45 +0000 Received: (qmail 61799 invoked from network); 6 Mar 2004 12:11:22 -0000 Received: from yahoobb219178198019.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.178.198.19) by necom830.hpcl.titech.ac.jp with SMTP; 6 Mar 2004 12:11:22 -0000 Message-ID: <4049C04E.1040008@necom830.hpcl.titech.ac.jp> Date: Sat, 06 Mar 2004 21:13:02 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Geoff Huston CC: Brian E Carpenter , multi6@ops.ietf.org Subject: Re: on the point of mobility & multihoming References: <4048479E.AC99300D@zurich.ibm.com> <6.0.1.1.2.20040305203801.01cd0ec0@localhost> In-Reply-To: <6.0.1.1.2.20040305203801.01cd0ec0@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Geoff Huston wrote: > I did stress in my presentation to the wg that slide 3 was misleading in a > number of ways. One of a mistake, among many, of your presentation was to say too much about mobility even though there is little architectural relationship between mobility and multihoming. It is one of a reason why your presentation should be ignored. An even worse mistake is that you consider some layer can magically solve the problem, which is the *ARCHITECATURAL* reasoing for *NAT*. For proper solutions, all the layers above IP must be involved, which was the first step of the architectural analysis. By insisting on sigle layers and pretending not to make any decision, you drop the core architectural point to consider multiple layers in a single solution. Thus, your presentation is no step of moving forward. Masataka Ohta From owner-multi6@ops.ietf.org Sat Mar 6 07:38:17 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15306 for ; Sat, 6 Mar 2004 07:38:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Azb3q-000Gtm-SF for multi6-data@psg.com; Sat, 06 Mar 2004 12:37:46 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Azb3f-000GsM-LA for multi6@ops.ietf.org; Sat, 06 Mar 2004 12:37:35 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i26CbqQI002149; Sat, 6 Mar 2004 13:37:53 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0ACA1EE0-6F6B-11D8-8C79-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: multi6@ops.ietf.org From: Iljitsch van Beijnum Subject: Re: Source address selection insufficient? Date: Sat, 6 Mar 2004 13:37:34 +0100 To: Erik Nordmark X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 3-mrt-04, at 6:29, Erik Nordmark wrote: > /-- ( A ) ---( ) --- ( C ) --\ > X (site X) ( IPv6 ) (Site Y) Y > \-- ( B ) ---( ) --- ( D ) --/ > This has 4 locator pairs: > A:X-C:Y > A:X-D:Y > B:X-C:Y > B:X-D:Y Ugh, is it just me or is the A:X notation (rather than X:A) very counter-intuitive? > The set of locator pairs that work when sending out from site X > might be A:X-C:Y and B:X-D:Y > but the set of locator pairs that work when sending from site Y might > be the other two: A:X-D:Y and B:X-C:Y. What you are saying is that X wants to reach Y over either the path A->C (1) or the path B->D (2), while in the other direction the path is D->A (3) or C->B (4). The address permutations in the packets are then as follows (!I means ingress filtered): address pair X->Y direction Y->X direction A/C (1) (3) !I A/D (2) !I (3) B/C (1) !I (4) B/D (2) (4) !I > Thus the intersection of the two ingress filtering constraints is the > empty set. :-( This means our address agility mechanisms must support packet flow where the src/dst addresses in packets in one direction don't correspond to the src/dst addresses in opposite direction. In the above example X may send out packets with A/C while Y responds with packets containing D/B. Unfortunately this still breaks all non-address agile protocols, most notably current TCP and UDP but also many proposed solutions in their compatible or negotiation phase. > This can happen due to normal routing as far as I can tell. > Am I missing something? The only way this can happen during "normal" routing is when the two destination addresses for a correspondent are routed differently. When this isn't the case (for instance, when a default route is in effect) the problem should only occur when there are outages but current TCP and UDP are dead in the water in that case anyway. We have to look at the possibilities of setting up new sessions (with a multihoming solution in effect) under these circumstances, though. I guess this means that trying different source addresses CAN be sufficient but it's far from ideal because it can't live together with existing traffic engineering techniques. But maybe the problem isn't as bad as it would seem at first glance: for small sites, source address based routing is fairly trivial and it provides decent overal traffic engineering (although individual streams may suffer) while only larger sites are going to run BGP in order to do traditional traffic engineering anyway, and presumably, those sites are in the position to get ingress filtering relaxed. (We need to document this very well at some point because this is still imcompatible with ingress filtering further downstream.) From owner-multi6@ops.ietf.org Sat Mar 6 07:45:43 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15575 for ; Sat, 6 Mar 2004 07:45:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AzbBC-000IR1-JV for multi6-data@psg.com; Sat, 06 Mar 2004 12:45:22 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AzbB1-000IPb-SQ for multi6@ops.ietf.org; Sat, 06 Mar 2004 12:45:12 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i26CjRQI002263; Sat, 6 Mar 2004 13:45:27 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <581566651.20040303151244@brandenburg.com> References: <581566651.20040303151244@brandenburg.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <197F1036-6F6C-11D8-8C79-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: multi6@ops.ietf.org, Geoff Huston From: Iljitsch van Beijnum Subject: Re: Wedge between transport and ULP Date: Sat, 6 Mar 2004 13:45:08 +0100 To: Dave Crocker X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 3-mrt-04, at 7:12, Dave Crocker wrote: > Geoff mention an architectural choice that is not currently > represented by any proposals. It places a multiaddressing wedge layer > between the transport layer and the applications layer. We've discussed this a while ago (where you on the list yet back then?). I'm not sure if everyone agreed in the end, but my position was and is that this can't work in a sane way. > The wedge fits rather nicely into that realm the OSI folks like to > call 'session layer'. Things put at that layer tend to need to > replicate control (eg, reliability) mechanisms already done in > transport. This will be particularly true if the layer is expected to > work across multiple transport associations. The problem is that you can't know how much data made it to the other end at any particular moment in time so retiring one TCP session and continuing over another means you have to resync. For some protocols (most HTTP, FTP) this can be done with relative ease, but solving the general case means effectively tunneling TCP over TCP, which makes no sense. From owner-multi6@ops.ietf.org Sat Mar 6 12:38:15 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27438 for ; Sat, 6 Mar 2004 12:38:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AzfiM-00006L-Nm for multi6-data@psg.com; Sat, 06 Mar 2004 17:35:54 +0000 Received: from [208.184.15.238] (helo=EXECDSL.COM) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Azfhv-000Pwo-Et for multi6@ops.ietf.org; Sat, 06 Mar 2004 17:35:27 +0000 Received: from [66.95.38.74] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 6710251 for multi6@ops.ietf.org; Sat, 06 Mar 2004 12:35:26 -0500 Message-Id: <5.1.0.14.0.20040306123026.019ae830@localhost> X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 06 Mar 2004 12:35:25 -0500 To: multi6@ops.ietf.org From: "Joel M. Halpern" Subject: Re: Source address selection insufficient? In-Reply-To: <0ACA1EE0-6F6B-11D8-8C79-000A95CD987A@muada.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk I think that this is getting more complex than necessary. It is true that routing is frequently asymmetric. However, that is a very different statement from saying that connectivity is asymettric. While the routing path among ISPs for a given address pair (src, dst) may be different in the forward and reverse direction, it would take a very strange situation for a pair to work one way, and not when reversed. It would take an even stranger situation for there to be no pair that worked in both directions. As such, I think we ought to be able to assume that there exists (at any given time) an address pair that is useable in both directions. (The packets using that pair may not take the same path forward and backward, but will use the same ingress / egress points on each end. Situations where the connectivitiy / path changes are so fast that you can not find such a pair probably need very different techniques (just as MANET is looking for different techniques than MobileIP.) Yours, Joel M. Halpern At 01:37 PM 3/6/2004 +0100, Iljitsch van Beijnum wrote: >On 3-mrt-04, at 6:29, Erik Nordmark wrote: > >> /-- ( A ) ---( ) --- ( C ) --\ >> X (site X) ( IPv6 ) (Site Y) Y >> \-- ( B ) ---( ) --- ( D ) --/ > >>This has 4 locator pairs: >> A:X-C:Y >> A:X-D:Y >> B:X-C:Y >> B:X-D:Y > >Ugh, is it just me or is the A:X notation (rather than X:A) very >counter-intuitive? > >>The set of locator pairs that work when sending out from site X >>might be A:X-C:Y and B:X-D:Y >>but the set of locator pairs that work when sending from site Y might >>be the other two: A:X-D:Y and B:X-C:Y. > >What you are saying is that X wants to reach Y over either the path A->C >(1) or the path B->D (2), while in the other direction the path is D->A >(3) or C->B (4). The address permutations in the packets are then as >follows (!I means ingress filtered): > >address pair X->Y direction Y->X direction >A/C (1) (3) !I >A/D (2) !I (3) >B/C (1) !I (4) >B/D (2) (4) !I > >>Thus the intersection of the two ingress filtering constraints is the >>empty set. > >:-( > >This means our address agility mechanisms must support packet flow where >the src/dst addresses in packets in one direction don't correspond to the >src/dst addresses in opposite direction. In the above example X may send >out packets with A/C while Y responds with packets containing D/B. > >Unfortunately this still breaks all non-address agile protocols, most >notably current TCP and UDP but also many proposed solutions in their >compatible or negotiation phase. > >>This can happen due to normal routing as far as I can tell. > >>Am I missing something? > >The only way this can happen during "normal" routing is when the two >destination addresses for a correspondent are routed differently. When >this isn't the case (for instance, when a default route is in effect) the >problem should only occur when there are outages but current TCP and UDP >are dead in the water in that case anyway. We have to look at the >possibilities of setting up new sessions (with a multihoming solution in >effect) under these circumstances, though. > >I guess this means that trying different source addresses CAN be >sufficient but it's far from ideal because it can't live together with >existing traffic engineering techniques. > >But maybe the problem isn't as bad as it would seem at first glance: for >small sites, source address based routing is fairly trivial and it >provides decent overal traffic engineering (although individual streams >may suffer) while only larger sites are going to run BGP in order to do >traditional traffic engineering anyway, and presumably, those sites are in >the position to get ingress filtering relaxed. (We need to document this >very well at some point because this is still imcompatible with ingress >filtering further downstream.) > From owner-multi6@ops.ietf.org Sat Mar 6 14:43:00 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01447 for ; Sat, 6 Mar 2004 14:43:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Azhel-0000o5-76 for multi6-data@psg.com; Sat, 06 Mar 2004 19:40:19 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Azhea-0000mY-IS for multi6@ops.ietf.org; Sat, 06 Mar 2004 19:40:08 +0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 06 Mar 2004 11:52:25 +0000 Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i26Je5F8008370; Sat, 6 Mar 2004 11:40:05 -0800 (PST) Received: from cisco.com (rtp-vpn3-550.cisco.com [10.82.218.41]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA07147; Sat, 6 Mar 2004 11:40:03 -0800 (PST) Message-ID: <404A2916.9020404@cisco.com> Date: Sat, 06 Mar 2004 11:40:06 -0800 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dave Crocker CC: john.loughney@nokia.com, jari.arkko@piuha.net, multi6@ops.ietf.org Subject: Re: on the point of mobility & multihoming References: <1799885891.20040304211625@brandenburg.com> In-Reply-To: <1799885891.20040304211625@brandenburg.com> X-Enigmail-Version: 0.83.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I like the idea of having a "mobility considerations" section in peoples' drafts. While I agree with John that if we focus on trying to kill two birds with one stone, sometimes the other bird just happens to get killed by being in the right place at the right time. To stretch this analogy past the bounds of taste for a moment, if we sufficiently wound the second bird and it only requires a small amount of thinking to knock him off entirely, we're better off. That having been said, Geoff's (and Dave's) clear message is that we could create a nightmare of overhead and complexity if we are not careful. Consider a case where we are using some sort of shim layer solution that sits atop MIPv6. The cases we have to deal with look like this: -- what happens when a provider goes down? Will the correspondent node attempt to send packets to the home agent? -- what if the home agent is behind the same provider? will the home agent be using a multihoming mechanism, and how will it impact the correspondent node? -- suppose the mobile node reseats itself back to its home network in the midst of all of this? Messy messy. In the meantime, is what we would really have from an architectural standpoint one form of transport isolation running atop another (I hesitate to use the word "tunnels" because it's not quite correct, but we're in the same ball park). BTW... Excellent presentation, Geoff! My apologies to bird lovers everywhere... Eliot From owner-multi6@ops.ietf.org Sat Mar 6 18:52:09 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11187 for ; Sat, 6 Mar 2004 18:52:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AzlXw-0003F6-ST for multi6-data@psg.com; Sat, 06 Mar 2004 23:49:32 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.30; FreeBSD) id 1AzlXl-0003DL-Vw for multi6@ops.ietf.org; Sat, 06 Mar 2004 23:49:22 +0000 Received: (qmail 64138 invoked from network); 6 Mar 2004 23:50:07 -0000 Received: from yahoobb219178198019.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.178.198.19) by necom830.hpcl.titech.ac.jp with SMTP; 6 Mar 2004 23:50:07 -0000 Message-ID: <404A640D.1010503@necom830.hpcl.titech.ac.jp> Date: Sun, 07 Mar 2004 08:51:41 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: "Joel M. Halpern" CC: multi6@ops.ietf.org Subject: Re: Source address selection insufficient? References: <5.1.0.14.0.20040306123026.019ae830@localhost> In-Reply-To: <5.1.0.14.0.20040306123026.019ae830@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Joel M. Halpern; > I think that this is getting more complex than necessary. Because of the introduction of connection at the IP layer, yes. The issue is simple if you accept the IP layer is connectionless and unidirectional. > It is true that routing is frequently asymmetric. > However, that is a very different statement from saying that > connectivity is asymettric. While the routing path among ISPs for a > given address pair (src, dst) may be different in the forward and > reverse direction, it would take a very strange situation for a pair to > work one way, and not when reversed. It would take an even stranger > situation for there to be no pair that worked in both directions. > > As such, I think we ought to be able to assume that there exists (at any > given time) an address pair that is useable in both directions. That is a useful property because it makes ICMP returned most of the time, though we shouldn't rely on them too much (that is, PMTUD is not a good idea). However, as the destination locator is chosen by the source local policy, bidirectional transport layer can not assume the locator pairs are same for the both directions. Masataka Ohta From owner-multi6@ops.ietf.org Sun Mar 7 00:03:40 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19459 for ; Sun, 7 Mar 2004 00:03:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AzqOc-000Gka-31 for multi6-data@psg.com; Sun, 07 Mar 2004 05:00:14 +0000 Received: from [66.92.66.68] (helo=cyteen.hactrn.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AzqOR-000Gib-8W for multi6@ops.ietf.org; Sun, 07 Mar 2004 05:00:03 +0000 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id AA9DE5C7 for ; Sun, 7 Mar 2004 00:00:02 -0500 (EST) To: multi6@ops.ietf.org Subject: Weekly posting summary for multi6@ops.ietf.org From: Rob Austein Date: Sun, 07 Mar 2004 00:00:02 -0500 Message-Id: <20040307050002.AA9DE5C7@cyteen.hactrn.net> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Messages | Bytes | Who --------+------+--------+----------+------------------------ 5.77% | 6 | 33.82% | 173474 | gih@telstra.net 10.58% | 11 | 12.07% | 61920 | kurtis@kurtis.pp.se 14.42% | 15 | 8.17% | 41900 | mohta@necom830.hpcl.titech.ac.jp 10.58% | 11 | 8.19% | 42030 | brc@zurich.ibm.com 8.65% | 9 | 5.49% | 28146 | erik.nordmark@sun.com 7.69% | 8 | 5.42% | 27795 | john.loughney@nokia.com 6.73% | 7 | 4.17% | 21367 | iljitsch@muada.com 5.77% | 6 | 3.83% | 19630 | mbagnulo@ing.uc3m.es 3.85% | 4 | 1.50% | 7708 | majordomo@psg.com 2.88% | 3 | 2.13% | 10908 | loa@ieee.org 2.88% | 3 | 1.76% | 9016 | pekkas@netcore.fi 2.88% | 3 | 1.60% | 8211 | dhc@dcrocker.net 1.92% | 2 | 2.01% | 10294 | huitema@windows.microsoft.com 1.92% | 2 | 1.12% | 5737 | spencer@mcsr-labs.org 1.92% | 2 | 1.08% | 5517 | francis.dupont@enst-bretagne.fr 1.92% | 2 | 1.04% | 5340 | dcrocker@brandenburg.com 1.92% | 2 | 0.95% | 4896 | sommerfeld@orchard.arlington.ma.us 1.92% | 2 | 0.86% | 4429 | jari.arkko@piuha.net 0.96% | 1 | 1.16% | 5942 | joel@stevecrocker.com 0.96% | 1 | 1.03% | 5259 | pekka.nikander@nomadiclab.com 0.96% | 1 | 0.73% | 3731 | atapiador@dit.upm.es 0.96% | 1 | 0.72% | 3676 | lear@cisco.com 0.96% | 1 | 0.61% | 3121 | jnc@mercury.lcs.mit.edu 0.96% | 1 | 0.56% | 2847 | margaret@thingmagic.com --------+------+--------+----------+------------------------ 100.00% | 104 |100.00% | 512894 | Total Grunchweather Associates provides this automatic summary on an at-whim basis at the request of the MULTI6 WG chairs. Your mileage may vary. We decline responsibilities, all shapes, all sizes, all colors. If this script produces broken output, you get to keep both pieces. From owner-multi6@ops.ietf.org Sun Mar 7 03:49:41 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09328 for ; Sun, 7 Mar 2004 03:49:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AztwF-00051t-Da for multi6-data@psg.com; Sun, 07 Mar 2004 08:47:11 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Aztw4-0004zj-BQ for multi6@ops.ietf.org; Sun, 07 Mar 2004 08:47:00 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i278lHQI017780; Sun, 7 Mar 2004 09:47:17 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <5.1.0.14.0.20040306123026.019ae830@localhost> References: <5.1.0.14.0.20040306123026.019ae830@localhost> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: multi6@ops.ietf.org From: Iljitsch van Beijnum Subject: Re: Source address selection insufficient? Date: Sun, 7 Mar 2004 09:46:57 +0100 To: "Joel M. Halpern" X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 6-mrt-04, at 18:35, Joel M. Halpern wrote: > I think that this is getting more complex than necessary. This isn't complexity invented by us; it's just reality that we have to deal with. > It is true that routing is frequently asymmetric. > However, that is a very different statement from saying that > connectivity is asymettric. Asymmetric routing + ingress filtering = asymmetric connectivity. > While the routing path among ISPs for a given address pair (src, dst) > may be different in the forward and reverse direction, it would take a > very strange situation for a pair to work one way, and not when > reversed. See Erik's original example or my interpretation of it in my message that you superfluously quoted in its entirety. From owner-multi6@ops.ietf.org Sun Mar 7 04:39:43 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11426 for ; Sun, 7 Mar 2004 04:39:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Azujh-000DYV-8v for multi6-data@psg.com; Sun, 07 Mar 2004 09:38:17 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.30; FreeBSD) id 1AzujW-000DUu-FO for multi6@ops.ietf.org; Sun, 07 Mar 2004 09:38:06 +0000 Received: (qmail 65757 invoked from network); 7 Mar 2004 09:38:59 -0000 Received: from yahoobb219178198119.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.178.198.119) by necom830.hpcl.titech.ac.jp with SMTP; 7 Mar 2004 09:38:59 -0000 Message-ID: <404AEE0A.7080100@necom830.hpcl.titech.ac.jp> Date: Sun, 07 Mar 2004 18:40:26 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Iljitsch van Beijnum CC: "Joel M. Halpern" , multi6@ops.ietf.org Subject: Re: Source address selection insufficient? References: <5.1.0.14.0.20040306123026.019ae830@localhost> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch; >> I think that this is getting more complex than necessary. > This isn't complexity invented by us; it's just reality that we have to > deal with. > >> It is true that routing is frequently asymmetric. >> However, that is a very different statement from saying that >> connectivity is asymettric. > Asymmetric routing + ingress filtering = asymmetric connectivity. An interesting implication is that site internal routers must use proper source address for ICMP reply to a host in a peer site, which makes connection oriented maintenance of source address impossible. Of course, for those believing in NAT or connection oriented IP layer, it is not impossible but just to make all the routers maintain transport layer states without having any knowledge on transport layer connectivity. Masataka Ohta From owner-multi6@ops.ietf.org Sun Mar 7 08:11:15 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17341 for ; Sun, 7 Mar 2004 08:11:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Azy0s-000NUU-O9 for multi6-data@psg.com; Sun, 07 Mar 2004 13:08:14 +0000 Received: from [195.212.29.154] (helo=mtagate5.de.ibm.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Azy0d-000NQj-HL for multi6@ops.ietf.org; Sun, 07 Mar 2004 13:07:59 +0000 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by mtagate5.de.ibm.com (8.12.10/8.12.10) with ESMTP id i27D7ue2016766; Sun, 7 Mar 2004 13:07:56 GMT Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay02.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i27D7vLi277504; Sun, 7 Mar 2004 14:07:57 +0100 Received: from zurich.ibm.com (sig-9-145-171-72.de.ibm.com [9.145.171.72]) by collon.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id OAA37388; Sun, 7 Mar 2004 14:07:52 +0100 Message-ID: <404B1EC8.62268A70@zurich.ibm.com> Date: Sun, 07 Mar 2004 14:08:24 +0100 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: Kanchei Loa CC: multi6@ops.ietf.org Subject: Re: on the point of mobility & multihoming References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Kenchei, I really think you miss my points. Firstly, this is not the MANET WG, and we are clearly chartered by the IESG to work on site multihoming in its classical sense, where if we come down to basics, the main goal is to prevent a BGP explosion. Secondly, there is nothing academic about observing that it is irrelevant whether physical links go up and down due to trucks blocking a wireless signal or due to random wires being disconnected. We are looking for a solution that doesn't care why the physical signal fails. Brian Kanchei Loa wrote: > > > > In my opinion, you just hit an important issue of multi6 architecture, > which > > > this WG is supposed to work on first. If we take Dave Croker's scenario > > > (suggested by Geoff Huston) and generalize it, the problem space is the > same > > > as depicted in Geoff's slide (page 3) of "An Architectural View of > Multi6 > > > proposals" except that the solid line (wired fixed connection) between > the > > > exit route and ISP is replace by dotted lines (wireless dynamic > > > connections). > > > > > > In this architecture, mobility is just a special case of "dynamic ad hoc > > > multihoming", which has timing restriction on updates and discovery. > (You > > > don't have to call it mobility if that is more IETF political correct). > In > > > Dave's scenario, from IP network's point of view, there is no difference > > > between a laptop sitting on a bench switching among ISPs because of > > > interference and a laptop sitting in a car that is moving back and forth > > > among ISPs. > > > > > > Should multi6 architecture encompass wireless connections between the > exit > > > router and IPS? Or, Dave Croker's scenario is too far away in the future > to > > > be included in multi6 architecture, which has been focusing on > traditional > > > IP multihoming with fixed connections only? It is up to the WG to > decide. > > > But the architecture document should spell out the rational choice. The > > > "uncomfortable" wireless issues won't goes away if we just choose to > ignore > > > them or call it something else. > > > Brian E Carpenter wrote: > > > Actually, it isn't up to the WG to decide. We are chartered to deal with > > _site multihoming_. That is definitely a different problem space from host > > multihoming in the form of ISP roaming. > > > > Now I know where the problem is. In Dave's scenario, the Personal Area > Network (PAN) surrounding him in the park is the "site", which consists of > laptop, PDA, game console, headphone, MP3 player, digital camera, and dual > mode handset (UMTS and 802.11b). The exit routers are laptop with 802.11g, > and handset with UMTS and 802.11b. Later, Dave's friend Geoff, sitting next > him on the same bench, join him to work on multi6 drafts. So, Dave's PAN and > Geoff's PAN are forming a new "site" with 4 exit routers (Dave's > laptop(802.11g), handset (UMTS, 802.11b), and Geoff's laptop (802.11a) and > handset (WCDMA and 802.11g). This new "site" should be able to take full > advantage of 4 redundant wireless ISP connections, even the interference > might knock out one or two ISP from time to time. > > If you consider above expanded scenario of a "site multioming" is too > "non-traditional", then let's try a traditional one. An branch office in > downtown has 4 exit routers to 5 ISP. Router a connects to ISP A through > wired cable modem (cost $55 per month) as primary Internet link. Router b > connects to ISP B through 802.16 wireless link (cost $60 per month) on the > roof top dish as backup Internet link. Router c connects to ISP C through > 802.11a corporate backbone (cost $100 per month) in adjacent building as > corporate resources access and backup Internet link. Router d connects to > local community networks (cost $50 per month), which are served by two > 802.11b providers ISP Da and ISP Db. This branch office is setup to support > their business in local community. So, router d is as important as other > exit routers. When the weather is bad or other RF factors, traffic driving > by disconnects constantly changes branch office's preferred access point. > > My point is that wireless exit connection to ISP is not an invisible wired > connection. It injects "ad hoc" factor into both traditional and > non-traditional site multihoming. That is definitely NOT a different problem > space from _site multihoming_ we are chartered to deal with unless you > exclude wireless in the charter. The host multihoming with "ISP roaming" is > just a special case of site multihoming where exit router and host are on > the same machine. > > > (Also, I don't see what wireless has to do with it. If I sit in front of > two > > Ethernet plugs leading to two ISPs, and move my connector from > > one to the other every two minutes, the problem is the same - but it is > *not* site > > multihoming.) > > > > Brian > > The "wireless" make "ad hoc site multihoming" a practical engineering > problem for any Internet community who follows IETF's lead. Your example of > plug-and-unplug Ethernet belongs to academic research not IETF. In above > scenario if all connection to ISPs are wired links, it won't make any sense > to create a multihoming protocol by this WG to deal with the situation that > a administrator plug-and-unplug Ethernet connector of exit routers at will > every two minutes. However, "wireless" causes the same plug-and-unplug > scenario a practical engineering problem we have to deal with. My opinion, > for what it's worth, is that the arguments of ad hoc multihoming should be > thrown out if the consensus is that wireless is not in WG's equation. > > In 1992 Dave Clark said "We reject kings, presidents, and voting. We believe > in rough consensus and running code". In my opinion, majority of the IPv6 > running codes are going to be deployed on wireless networks. > > ----------------- > Kanchei Loa > loa@ieee.org -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM From owner-multi6@ops.ietf.org Sun Mar 7 11:04:57 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25275 for ; Sun, 7 Mar 2004 11:04:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B00jV-0003Aj-2G for multi6-data@psg.com; Sun, 07 Mar 2004 16:02:29 +0000 Received: from [68.6.19.125] (helo=fed1mtao06.cox.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AzRSN-000N8e-L8 for multi6@ops.ietf.org; Sat, 06 Mar 2004 02:22:27 +0000 Received: from momo ([68.2.220.20]) by fed1mtao06.cox.net (InterMail vM.5.01.06.08 201-253-122-130-108-20031117) with SMTP id <20040306022224.LDMY25273.fed1mtao06.cox.net@momo>; Fri, 5 Mar 2004 21:22:24 -0500 From: "Kanchei Loa" To: "Brian E Carpenter" Cc: Subject: RE: on the point of mobility & multihoming Date: Fri, 5 Mar 2004 19:22:21 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <4048479E.AC99300D@zurich.ibm.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] > > In my opinion, you just hit an important issue of multi6 architecture, which > > this WG is supposed to work on first. If we take Dave Croker's scenario > > (suggested by Geoff Huston) and generalize it, the problem space is the same > > as depicted in Geoff's slide (page 3) of "An Architectural View of Multi6 > > proposals" except that the solid line (wired fixed connection) between the > > exit route and ISP is replace by dotted lines (wireless dynamic > > connections). > > > > In this architecture, mobility is just a special case of "dynamic ad hoc > > multihoming", which has timing restriction on updates and discovery. (You > > don't have to call it mobility if that is more IETF political correct). In > > Dave's scenario, from IP network's point of view, there is no difference > > between a laptop sitting on a bench switching among ISPs because of > > interference and a laptop sitting in a car that is moving back and forth > > among ISPs. > > > > Should multi6 architecture encompass wireless connections between the exit > > router and IPS? Or, Dave Croker's scenario is too far away in the future to > > be included in multi6 architecture, which has been focusing on traditional > > IP multihoming with fixed connections only? It is up to the WG to decide. > > But the architecture document should spell out the rational choice. The > > "uncomfortable" wireless issues won't goes away if we just choose to ignore > > them or call it something else. > Brian E Carpenter wrote: > Actually, it isn't up to the WG to decide. We are chartered to deal with > _site multihoming_. That is definitely a different problem space from host > multihoming in the form of ISP roaming. > Now I know where the problem is. In Dave's scenario, the Personal Area Network (PAN) surrounding him in the park is the "site", which consists of laptop, PDA, game console, headphone, MP3 player, digital camera, and dual mode handset (UMTS and 802.11b). The exit routers are laptop with 802.11g, and handset with UMTS and 802.11b. Later, Dave's friend Geoff, sitting next him on the same bench, join him to work on multi6 drafts. So, Dave's PAN and Geoff's PAN are forming a new "site" with 4 exit routers (Dave's laptop(802.11g), handset (UMTS, 802.11b), and Geoff's laptop (802.11a) and handset (WCDMA and 802.11g). This new "site" should be able to take full advantage of 4 redundant wireless ISP connections, even the interference might knock out one or two ISP from time to time. If you consider above expanded scenario of a "site multioming" is too "non-traditional", then let's try a traditional one. An branch office in downtown has 4 exit routers to 5 ISP. Router a connects to ISP A through wired cable modem (cost $55 per month) as primary Internet link. Router b connects to ISP B through 802.16 wireless link (cost $60 per month) on the roof top dish as backup Internet link. Router c connects to ISP C through 802.11a corporate backbone (cost $100 per month) in adjacent building as corporate resources access and backup Internet link. Router d connects to local community networks (cost $50 per month), which are served by two 802.11b providers ISP Da and ISP Db. This branch office is setup to support their business in local community. So, router d is as important as other exit routers. When the weather is bad or other RF factors, traffic driving by disconnects constantly changes branch office's preferred access point. My point is that wireless exit connection to ISP is not an invisible wired connection. It injects "ad hoc" factor into both traditional and non-traditional site multihoming. That is definitely NOT a different problem space from _site multihoming_ we are chartered to deal with unless you exclude wireless in the charter. The host multihoming with "ISP roaming" is just a special case of site multihoming where exit router and host are on the same machine. > (Also, I don't see what wireless has to do with it. If I sit in front of two > Ethernet plugs leading to two ISPs, and move my connector from > one to the other every two minutes, the problem is the same - but it is *not* site > multihoming.) > > Brian The "wireless" make "ad hoc site multihoming" a practical engineering problem for any Internet community who follows IETF's lead. Your example of plug-and-unplug Ethernet belongs to academic research not IETF. In above scenario if all connection to ISPs are wired links, it won't make any sense to create a multihoming protocol by this WG to deal with the situation that a administrator plug-and-unplug Ethernet connector of exit routers at will every two minutes. However, "wireless" causes the same plug-and-unplug scenario a practical engineering problem we have to deal with. My opinion, for what it's worth, is that the arguments of ad hoc multihoming should be thrown out if the consensus is that wireless is not in WG's equation. In 1992 Dave Clark said "We reject kings, presidents, and voting. We believe in rough consensus and running code". In my opinion, majority of the IPv6 running codes are going to be deployed on wireless networks. ----------------- Kanchei Loa loa@ieee.org From owner-multi6@ops.ietf.org Sun Mar 7 11:19:07 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25541 for ; Sun, 7 Mar 2004 11:19:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B00yM-00062M-CG for multi6-data@psg.com; Sun, 07 Mar 2004 16:17:50 +0000 Received: from [192.71.80.74] (helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B00yB-00060z-91 for multi6@ops.ietf.org; Sun, 07 Mar 2004 16:17:39 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id 42494310AA7 for ; Sun, 7 Mar 2004 17:18:05 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v612) In-Reply-To: <20040307050002.AA9DE5C7@cyteen.hactrn.net> References: <20040307050002.AA9DE5C7@cyteen.hactrn.net> Content-Type: text/plain; charset=US-ASCII; format=fixed Message-Id: Content-Transfer-Encoding: 7bit From: Kurt Erik Lindqvist Subject: Re: Weekly posting summary for multi6@ops.ietf.org Date: Sun, 7 Mar 2004 17:17:57 +0100 To: Multi6 List X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 All, we (chairs) asked Rob to provide this service just as for some of the other WGs. This is more for reference. Note that this first week is based on archives that we fed Robs script so it might be off a bit. - - kurtis - On 2004-03-07, at 06.00, Rob Austein wrote: > Messages | Bytes | Who > --------+------+--------+----------+------------------------ > 5.77% | 6 | 33.82% | 173474 | gih@telstra.net > 10.58% | 11 | 12.07% | 61920 | kurtis@kurtis.pp.se > 14.42% | 15 | 8.17% | 41900 | mohta@necom830.hpcl.titech.ac.jp > 10.58% | 11 | 8.19% | 42030 | brc@zurich.ibm.com > 8.65% | 9 | 5.49% | 28146 | erik.nordmark@sun.com > 7.69% | 8 | 5.42% | 27795 | john.loughney@nokia.com > 6.73% | 7 | 4.17% | 21367 | iljitsch@muada.com > 5.77% | 6 | 3.83% | 19630 | mbagnulo@ing.uc3m.es > 3.85% | 4 | 1.50% | 7708 | majordomo@psg.com > 2.88% | 3 | 2.13% | 10908 | loa@ieee.org > 2.88% | 3 | 1.76% | 9016 | pekkas@netcore.fi > 2.88% | 3 | 1.60% | 8211 | dhc@dcrocker.net > 1.92% | 2 | 2.01% | 10294 | huitema@windows.microsoft.com > 1.92% | 2 | 1.12% | 5737 | spencer@mcsr-labs.org > 1.92% | 2 | 1.08% | 5517 | francis.dupont@enst-bretagne.fr > 1.92% | 2 | 1.04% | 5340 | dcrocker@brandenburg.com > 1.92% | 2 | 0.95% | 4896 | sommerfeld@orchard.arlington.ma.us > 1.92% | 2 | 0.86% | 4429 | jari.arkko@piuha.net > 0.96% | 1 | 1.16% | 5942 | joel@stevecrocker.com > 0.96% | 1 | 1.03% | 5259 | pekka.nikander@nomadiclab.com > 0.96% | 1 | 0.73% | 3731 | atapiador@dit.upm.es > 0.96% | 1 | 0.72% | 3676 | lear@cisco.com > 0.96% | 1 | 0.61% | 3121 | jnc@mercury.lcs.mit.edu > 0.96% | 1 | 0.56% | 2847 | margaret@thingmagic.com > --------+------+--------+----------+------------------------ > 100.00% | 104 |100.00% | 512894 | Total > > Grunchweather Associates provides this automatic summary on an at-whim > basis at the request of the MULTI6 WG chairs. Your mileage may vary. > We decline responsibilities, all shapes, all sizes, all colors. > If this script produces broken output, you get to keep both pieces. > -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQEtLO6arNKXTPFCVEQJZ/wCgnIXT8NgclFUCD26lSxnk9X8L3gEAn2Bf qLk8SWAvojzxdMvV48Oeh/iO =JMAj -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Sun Mar 7 18:38:54 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13120 for ; Sun, 7 Mar 2004 18:38:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B07oJ-000HBx-Rw for multi6-data@psg.com; Sun, 07 Mar 2004 23:35:55 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.30; FreeBSD) id 1B07o0-000H9P-K8 for multi6@ops.ietf.org; Sun, 07 Mar 2004 23:35:36 +0000 Received: (qmail 68833 invoked from network); 7 Mar 2004 23:36:40 -0000 Received: from yahoobb219178198119.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.178.198.119) by necom830.hpcl.titech.ac.jp with SMTP; 7 Mar 2004 23:36:40 -0000 Message-ID: <404BB255.9090100@necom830.hpcl.titech.ac.jp> Date: Mon, 08 Mar 2004 08:37:57 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Kanchei Loa CC: Brian E Carpenter , multi6@ops.ietf.org Subject: Re: on the point of mobility & multihoming References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Kanchei Loa; > Router d connects to > local community networks (cost $50 per month), which are served by two > 802.11b providers ISP Da and ISP Db. This branch office is setup to support > their business in local community. So, router d is as important as other > exit routers. When the weather is bad or other RF factors, traffic driving > by disconnects constantly changes branch office's preferred access point. You are applying 802.11b technology wrongly, then. If the branch office is setup to support their business in local community, 802.11b link of router d is as important as and should be as stable as other links of other exit routers. If a link to an ISP constantly disconects, two links to the ISP constantly disconnect that the ISP is useless. Or, you can still use the ISP with the quality for less serious purposes, which has nothing to do with M6. > The "wireless" make "ad hoc site multihoming" a practical engineering Neither "wireless" nor "ad hoc" means "unreliable" nor "unstable". Masataka Ohta From owner-multi6@ops.ietf.org Sun Mar 7 19:50:10 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15288 for ; Sun, 7 Mar 2004 19:50:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B08vq-0005zp-NG for multi6-data@psg.com; Mon, 08 Mar 2004 00:47:46 +0000 Received: from [68.6.19.241] (helo=fed1mtao04.cox.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B08vX-0005x2-Oh for multi6@ops.ietf.org; Mon, 08 Mar 2004 00:47:27 +0000 Received: from momo ([68.2.220.20]) by fed1mtao04.cox.net (InterMail vM.5.01.06.08 201-253-122-130-108-20031117) with SMTP id <20040308004728.ZBQ29098.fed1mtao04.cox.net@momo>; Sun, 7 Mar 2004 19:47:28 -0500 From: "Kanchei Loa" To: "Brian E Carpenter" Cc: Subject: RE: on the point of mobility & multihoming Date: Sun, 7 Mar 2004 17:47:24 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <404B1EC8.62268A70@zurich.ibm.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Brian E Carpenter wrote: > Kenchei, > > I really think you miss my points. > > Firstly, this is not the MANET WG, and we are clearly chartered by > the IESG to work on site multihoming in its classical sense, where > if we come down to basics, the main goal is to prevent a BGP explosion. > Actually, we are in agreement here regarding "the main goal is to prevent a BGP explosion" for this WG. But I should clarify that Dave Croker's scenario is not a MANET problem as you assumed. The combined Dave's and Geoff's Personal Area Network is at link layer (like L2 bridging). From IP routing point of view it is a single IP subnet with 4 exit routers to 4 ISPs. There is no IP MANET running anywhere. However, if there is no BGP running between exit router and ISP, then it has nothing to do with BGP explosion. Is multi6 only deal with the architecture where BGP is running between exit router and ISP ? > Secondly, there is nothing academic about observing that it is irrelevant > whether physical links go up and down due to trucks blocking a > wireless signal > or due to random wires being disconnected. We are looking for a > solution that doesn't care why the physical signal fails. > > Brian Agree. We are looking for a solution that doesn't care why the physical signal fails and the frequency of failing. In my branch office scenario BGP is running between exit routers and ISPs. Does this scenario fit multi6 WG charter ? If the answer is "no", I will rest my case. But please clarify your definition of "site multihoming in its classical sense" and why my branch office scenario doesn't fit your definition. If the answer is "yes", then we are back to the original debate of this thread. Multiaddress mulithoming and mobility solutions must incorporate the same mechanisms: 1. multiplexing in the presence of more than one address pair 2. adding/removing addresses 3. failover 4. rendezvous There is no difference between multihoming and mobility. In my branch office scenario "traffic driving by disconnects constantly changes branch office's preferred access point". The physical signal between exit router and ISP could fail due to (1) plug-and-unplug connectors (wired connection) (2) weather or other RF factors (wireless connection) (3) changing distance (mobility). The solution for multihoming designed for (1) and (2) should solve (3) as well. From IP multihoming point of view, why the signal fails is irrelevant to the solution. "We are looking for a solution that doesn't care why the physical signal fails". My point, for what it worth, is that we should kill two birds in one stone because there is only one bird if you get closer and exam it carefully. Both coming architecture and operation documents should make it clear that mobility is not an add-on feature for multihoming, such that we could categorize and evaluation solutions/recommendations accordingly. Note: How do we word it is another story. MIP has been given IP mobility a bad name, which is usually related to complex signaling and awkward tunneling schemes. May be we just call it dynamic multihoming instead of mobility. -------------- Kanchei Loa loa@ieee.org > > Kanchei Loa wrote: > > > > > > In my opinion, you just hit an important issue of multi6 > architecture, > > which > > > > this WG is supposed to work on first. If we take Dave > Croker's scenario > > > > (suggested by Geoff Huston) and generalize it, the problem > space is the > > same > > > > as depicted in Geoff's slide (page 3) of "An Architectural View of > > Multi6 > > > > proposals" except that the solid line (wired fixed > connection) between > > the > > > > exit route and ISP is replace by dotted lines (wireless dynamic > > > > connections). > > > > > > > > In this architecture, mobility is just a special case of > "dynamic ad hoc > > > > multihoming", which has timing restriction on updates and discovery. > > (You > > > > don't have to call it mobility if that is more IETF > political correct). > > In > > > > Dave's scenario, from IP network's point of view, there is > no difference > > > > between a laptop sitting on a bench switching among ISPs because of > > > > interference and a laptop sitting in a car that is moving > back and forth > > > > among ISPs. > > > > > > > > Should multi6 architecture encompass wireless connections > between the > > exit > > > > router and IPS? Or, Dave Croker's scenario is too far away > in the future > > to > > > > be included in multi6 architecture, which has been focusing on > > traditional > > > > IP multihoming with fixed connections only? It is up to the WG to > > decide. > > > > But the architecture document should spell out the rational > choice. The > > > > "uncomfortable" wireless issues won't goes away if we just choose to > > ignore > > > > them or call it something else. > > > > > Brian E Carpenter wrote: > > > > > Actually, it isn't up to the WG to decide. We are chartered > to deal with > > > _site multihoming_. That is definitely a different problem > space from host > > > multihoming in the form of ISP roaming. > > > > > > > Now I know where the problem is. In Dave's scenario, the Personal Area > > Network (PAN) surrounding him in the park is the "site", which > consists of > > laptop, PDA, game console, headphone, MP3 player, digital > camera, and dual > > mode handset (UMTS and 802.11b). The exit routers are laptop > with 802.11g, > > and handset with UMTS and 802.11b. Later, Dave's friend Geoff, > sitting next > > him on the same bench, join him to work on multi6 drafts. So, > Dave's PAN and > > Geoff's PAN are forming a new "site" with 4 exit routers (Dave's > > laptop(802.11g), handset (UMTS, 802.11b), and Geoff's laptop > (802.11a) and > > handset (WCDMA and 802.11g). This new "site" should be able to > take full > > advantage of 4 redundant wireless ISP connections, even the interference > > might knock out one or two ISP from time to time. > > > > If you consider above expanded scenario of a "site multioming" is too > > "non-traditional", then let's try a traditional one. An branch office in > > downtown has 4 exit routers to 5 ISP. Router a connects to ISP A through > > wired cable modem (cost $55 per month) as primary Internet > link. Router b > > connects to ISP B through 802.16 wireless link (cost $60 per > month) on the > > roof top dish as backup Internet link. Router c connects to > ISP C through > > 802.11a corporate backbone (cost $100 per month) in adjacent building as > > corporate resources access and backup Internet link. Router d > connects to > > local community networks (cost $50 per month), which are served by two > > 802.11b providers ISP Da and ISP Db. This branch office is > setup to support > > their business in local community. So, router d is as important as other > > exit routers. When the weather is bad or other RF factors, > traffic driving > > by disconnects constantly changes branch office's preferred > access point. > > > > My point is that wireless exit connection to ISP is not an > invisible wired > > connection. It injects "ad hoc" factor into both traditional and > > non-traditional site multihoming. That is definitely NOT a > different problem > > space from _site multihoming_ we are chartered to deal with unless you > > exclude wireless in the charter. The host multihoming with "ISP > roaming" is > > just a special case of site multihoming where exit router and > host are on > > the same machine. > > > > > (Also, I don't see what wireless has to do with it. If I sit > in front of > > two > > > Ethernet plugs leading to two ISPs, and move my connector from > > > one to the other every two minutes, the problem is the same - > but it is > > *not* site > > > multihoming.) > > > > > > Brian > > > > The "wireless" make "ad hoc site multihoming" a practical engineering > > problem for any Internet community who follows IETF's lead. > Your example of > > plug-and-unplug Ethernet belongs to academic research not IETF. > In above > > scenario if all connection to ISPs are wired links, it won't > make any sense > > to create a multihoming protocol by this WG to deal with the > situation that > > a administrator plug-and-unplug Ethernet connector of exit > routers at will > > every two minutes. However, "wireless" causes the same plug-and-unplug > > scenario a practical engineering problem we have to deal with. > My opinion, > > for what it's worth, is that the arguments of ad hoc > multihoming should be > > thrown out if the consensus is that wireless is not in WG's equation. > > > > In 1992 Dave Clark said "We reject kings, presidents, and > voting. We believe > > in rough consensus and running code". In my opinion, majority > of the IPv6 > > running codes are going to be deployed on wireless networks. > > > > ----------------- > > Kanchei Loa > > loa@ieee.org > > -- > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > Brian E Carpenter > Distinguished Engineer, Internet Standards & Technology, IBM > > From owner-multi6@ops.ietf.org Mon Mar 8 14:16:34 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21734 for ; Mon, 8 Mar 2004 14:16:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B0QCK-0003Mw-Uw for multi6-data@psg.com; Mon, 08 Mar 2004 19:13:56 +0000 Received: from [192.18.42.14] (helo=nwkea-mail-2.sun.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B0QCA-0003JL-CG for multi6@ops.ietf.org; Mon, 08 Mar 2004 19:13:46 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i28JDTdO010849; Mon, 8 Mar 2004 11:13:30 -0800 (PST) Received: from bobo (bobo.SFBay.Sun.COM [129.146.89.81]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i28JDRQ11272; Mon, 8 Mar 2004 20:13:27 +0100 (MET) Date: Mon, 8 Mar 2004 11:13:34 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Source address selection insufficient? To: Iljitsch van Beijnum Cc: Erik Nordmark , multi6@ops.ietf.org In-Reply-To: "Your message with ID" <0ACA1EE0-6F6B-11D8-8C79-000A95CD987A@muada.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk > This means our address agility mechanisms must support packet flow > where the src/dst addresses in packets in one direction don't > correspond to the src/dst addresses in opposite direction. In the above > example X may send out packets with A/C while Y responds with packets > containing D/B. If you need that level of address agility underneath the transport protocols you need to modify the hosts at both ends. Once you modify the hosts at both ends why not also provide connection rehoming? (There seems to be a large class of connection rehoming mechanisms that can live with source locator rewriting instead of ingress filtering, but that's the subject of a different email.) > But maybe the problem isn't as bad as it would seem at first glance: > for small sites, source address based routing is fairly trivial and it > provides decent overal traffic engineering (although individual streams > may suffer) while only larger sites are going to run BGP in order to do > traditional traffic engineering anyway, and presumably, those sites are > in the position to get ingress filtering relaxed. (We need to document > this very well at some point because this is still imcompatible with > ingress filtering further downstream.) I agree that source based routing and relaxed filtering both work. What is tricky is the middle between the small and the large; too small a site to be able to convince the ISPs to relax ingress filtering and too large a site for source based routing to be trivial. Erik From owner-multi6@ops.ietf.org Mon Mar 8 17:29:33 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07390 for ; Mon, 8 Mar 2004 17:29:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B0TDN-000KDE-77 for multi6-data@psg.com; Mon, 08 Mar 2004 22:27:13 +0000 Received: from [208.184.79.7] (helo=joy.songbird.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B0TDC-000KBn-Py for multi6@ops.ietf.org; Mon, 08 Mar 2004 22:27:02 +0000 Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i28MZud06571; Mon, 8 Mar 2004 14:35:56 -0800 Date: Mon, 8 Mar 2004 14:26:57 -0800 From: dhcnotice Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <173148923.20040308142657@brandenburg.com> To: Brian E Carpenter CC: Kanchei Loa , multi6@ops.ietf.org Subject: two perspectives on "site" multihoming In-Reply-To: <404B1EC8.62268A70@zurich.ibm.com> References: <404B1EC8.62268A70@zurich.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.7 required=5.0 tests=AWL,BAYES_00,PRIORITY_NO_NAME autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Brian, BEC> Firstly, this is not the MANET WG, and we are clearly chartered by BEC> the IESG to work on site multihoming in its classical sense, where BEC> if we come down to basics, the main goal is to prevent a BGP explosion. There are two different strategic ways to approach site multi-homing. One is at the site-level, of course. Hence the focus is on network-level mechanisms. An example would be a network-agile method of addressing while holding the host portion constant, and then filling in the correct network portion at the exit router. Presumably this would leave the host untouched. The other approach is at the host-level, where the exit router is essentially unaware of the mechanism -- return filtering issues notwithstanding. The model has the host do all the work and can, in fact, leave the exit router unchanged. So, the host is address-agile. It is worth noting that this approach has the option of being implemented at the site level, largely transparent to the host, for easy adoption by sites. Or it can be adopted at the host level, for easy adoption by those hosts, without having to recruit site administration to the effort. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-multi6@ops.ietf.org Mon Mar 8 17:35:57 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07792 for ; Mon, 8 Mar 2004 17:35:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B0TKx-000Lh6-W5 for multi6-data@psg.com; Mon, 08 Mar 2004 22:35:03 +0000 Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B0TKP-000LbE-7N for multi6@ops.ietf.org; Mon, 08 Mar 2004 22:34:29 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i28MYEbR025892; Mon, 8 Mar 2004 15:34:15 -0700 (MST) Received: from bobo (bobo.SFBay.Sun.COM [129.146.89.81]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i28MYCQ02730; Mon, 8 Mar 2004 23:34:12 +0100 (MET) Date: Mon, 8 Mar 2004 14:34:18 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Source address selection insufficient? To: "Joel M. Halpern" Cc: multi6@ops.ietf.org In-Reply-To: "Your message with ID" <5.1.0.14.0.20040306123026.019ae830@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk > I think that this is getting more complex than necessary. > It is true that routing is frequently asymmetric. > However, that is a very different statement from saying that connectivity > is asymettric. While the routing path among ISPs for a given address pair > (src, dst) may be different in the forward and reverse direction, it would > take a very strange situation for a pair to work one way, and not when > reversed. It would take an even stranger situation for there to be no pair > that worked in both directions. Things might be a bit subtle - perhaps we don't understand well enough the interaction between routing, source address selection, and ingress filtering yet. A few observations: 1. If you ignore the effect of the source addresses and ingress filtering, all paths between A and B work in both directions in my example. Thus there is no need for unidirectional failures of links to get into this state. 2. Each link between a site and their ISPs can have packets pass in both directions in the example; there exist a address pair which makes packets traverse a particular site/ISP link. 3. One perspective is that we get in trouble due to the assumption by the transport protocols that the same address pair is used in both directions; the assumption seems counter to the loose notion of "address selection" - only one end of the communication can select address. (Another perspective is that ingress filtering doesn't fit.) > As such, I think we ought to be able to assume that there exists (at any > given time) an address pair that is useable in both directions. (The > packets using that pair may not take the same path forward and backward, > but will use the same ingress / egress points on each end. I don't understand. From the fact that communication is possible in both directions, both e2e and over each of the site/ISP links, it doesn't follow that an adress pair exists that can be used in both directions. Can you clarify? Erik From owner-multi6@ops.ietf.org Mon Mar 8 18:14:17 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10637 for ; Mon, 8 Mar 2004 18:14:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B0Tvu-0006JJ-KV for multi6-data@psg.com; Mon, 08 Mar 2004 23:13:14 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B0Tvj-0006Dt-Iw for multi6@ops.ietf.org; Mon, 08 Mar 2004 23:13:03 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i28NDKQI047885; Tue, 9 Mar 2004 00:13:20 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <25A9E05E-7156-11D8-9606-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: multi6@ops.ietf.org From: Iljitsch van Beijnum Subject: Re: Source address selection insufficient? Date: Tue, 9 Mar 2004 00:13:02 +0100 To: Erik Nordmark X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 8-mrt-04, at 20:13, Erik Nordmark wrote: >> This means our address agility mechanisms must support packet flow >> where the src/dst addresses in packets in one direction don't >> correspond to the src/dst addresses in opposite direction. > If you need that level of address agility underneath the transport > protocols > you need to modify the hosts at both ends. Any level of address agility greater than 0 requires this. > Once you modify the hosts at both ends why not also provide connection > rehoming? Sure. But how does this relate to the problem at hand currently? > (There seems to be a large class of connection rehoming mechanisms > that can live with source locator rewriting instead of ingress > filtering, > but that's the subject of a different email.) Unfortunately we still have to deal with the packets that can't be rewritten and I'm not sure if expecting all routers to be upgraded to support this is reasonable. > I agree that source based routing and relaxed filtering both work. > What is tricky is the middle between the small and the large; too small > a site to be able to convince the ISPs to relax ingress filtering > and too large a site for source based routing to be trivial. For mid-sized sites the "use a default only" policy wouldn't be ideal, but it should at least make sure there is always a working path. For small sites the default-only policy has the disadvantage that only one external link will be used for outgoing traffic, but in a site that has several routers and subnets, different routers/subnets could use different external connections so rudimentary load balancing would still happen. The main problem of this approach is the fact that unfortunate source address choices lead to blocked packets/sessions because of ingress filtering. However, mechanisms to overcome this problem can largely be implemented unilaterally, especially for outgoing sessions. From owner-multi6@ops.ietf.org Mon Mar 8 22:21:37 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18544 for ; Mon, 8 Mar 2004 22:21:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B0XmL-000KgO-MK for multi6-data@psg.com; Tue, 09 Mar 2004 03:19:37 +0000 Received: from [68.6.19.125] (helo=fed1mtao06.cox.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B0XmA-000Kev-QK for multi6@ops.ietf.org; Tue, 09 Mar 2004 03:19:26 +0000 Received: from momo ([68.2.220.20]) by fed1mtao06.cox.net (InterMail vM.5.01.06.08 201-253-122-130-108-20031117) with SMTP id <20040309000323.ORHE25273.fed1mtao06.cox.net@momo> for ; Mon, 8 Mar 2004 19:03:23 -0500 From: "Kanchei Loa" To: Subject: RE: on the point of mobility & multihoming Date: Mon, 8 Mar 2004 17:03:22 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <404BB255.9090100@necom830.hpcl.titech.ac.jp> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit There are many factors (technical and non-technical) affecting the decision to select a specific link layer for ISP connections. The performance of all wireless technologies varies with time and space, which is the nature of the beast. Brian Carpenter said "We are looking for a solution that doesn't care why the physical signal fails". I agree with him ----------------- Kanchei Loa loa@ieee.org > -----Original Message----- > From: owner-multi6@ops.ietf.org > [mailto:owner-multi6@ops.ietf.org]On Behalf Of Masataka Ohta > Sent: Sunday, March 07, 2004 4:38 PM > To: Kanchei Loa > Cc: Brian E Carpenter; multi6@ops.ietf.org > Subject: Re: on the point of mobility & multihoming > > > Kanchei Loa; > > > Router d connects to > > local community networks (cost $50 per month), which are served by two > > 802.11b providers ISP Da and ISP Db. This branch office is > setup to support > > their business in local community. So, router d is as important as other > > exit routers. When the weather is bad or other RF factors, > traffic driving > > by disconnects constantly changes branch office's preferred > access point. > > You are applying 802.11b technology wrongly, then. > > If the branch office is setup to support their business in local > community, 802.11b link of router d is as important as and should > be as stable as other links of other exit routers. > > If a link to an ISP constantly disconects, two links to the ISP > constantly disconnect that the ISP is useless. > > Or, you can still use the ISP with the quality for less serious > purposes, which has nothing to do with M6. > > > The "wireless" make "ad hoc site multihoming" a practical engineering > > Neither "wireless" nor "ad hoc" means "unreliable" nor "unstable". > > Masataka Ohta > > > > From owner-multi6@ops.ietf.org Mon Mar 8 23:32:42 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20631 for ; Mon, 8 Mar 2004 23:32:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B0YtP-000PMi-Ow for multi6-data@psg.com; Tue, 09 Mar 2004 04:30:59 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.30; FreeBSD) id 1B0YtE-000PHQ-Nd for multi6@ops.ietf.org; Tue, 09 Mar 2004 04:30:48 +0000 Received: (qmail 75716 invoked from network); 9 Mar 2004 04:32:14 -0000 Received: from vaio.hpcl.titech.ac.jp (HELO necom830.hpcl.titech.ac.jp) (131.112.32.134) by necom830.hpcl.titech.ac.jp with SMTP; 9 Mar 2004 04:32:14 -0000 Message-ID: <404D4907.6070906@necom830.hpcl.titech.ac.jp> Date: Tue, 09 Mar 2004 13:33:11 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Kanchei Loa CC: multi6@ops.ietf.org Subject: Re: on the point of mobility & multihoming References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Kanchei Loa; > There are many factors (technical and non-technical) affecting the decision > to select a specific link layer for ISP connections. The performance of all > wireless technologies varies with time and space, which is the nature of the > beast. There is nothing wireless specific. Try to use 100 base T with 500m UTP-3 cables and 10 dumb hubs cascaded. Masataka Ohta From owner-multi6@ops.ietf.org Tue Mar 9 01:23:12 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25944 for ; Tue, 9 Mar 2004 01:23:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B0abG-000NOr-KU for multi6-data@psg.com; Tue, 09 Mar 2004 06:20:22 +0000 Received: from [68.6.19.126] (helo=fed1mtao05.cox.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B0aax-000NEe-Eu for multi6@ops.ietf.org; Tue, 09 Mar 2004 06:20:03 +0000 Received: from momo ([68.2.220.20]) by fed1mtao05.cox.net (InterMail vM.5.01.06.08 201-253-122-130-108-20031117) with SMTP id <20040309062000.TIOE8957.fed1mtao05.cox.net@momo>; Tue, 9 Mar 2004 01:20:00 -0500 From: "Kanchei Loa" To: "Masataka Ohta" Cc: Subject: RE: on the point of mobility & multihoming Date: Mon, 8 Mar 2004 23:20:01 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <404D4907.6070906@necom830.hpcl.titech.ac.jp> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > >Kanchei Loa wrote: > > > There are many factors (technical and non-technical) affecting the decision > > to select a specific link layer for ISP connections. The performance of all > > wireless technologies varies with time and space, which is the nature of the > > beast. > > Masataka Ohta wrote: > There is nothing wireless specific. > > Try to use 100 base T with 500m UTP-3 cables and 10 dumb hubs > cascaded. > Well, a connection between exit router and ISP using "100 base T with 500m UTP-3 cables and 10 dumb hubs" is out of the specification of IEEE standard. The user won't expect M6 solution would work on an out-of-spec connection nor should this WG. But the same user would expect M6 solution maintains reasonable performance (or degrade gracefully) with his "within-spec" wireless link to ISP independent of the weather condition. However, there is a possibility that a M6 solution working on the wireless connection might patch the "100 base T with 500m UTP-3 cables and 10 dumb hubs" problem (although the link layer might have shut down the interface already before the IP layer have the chance to take care of it). -------------- Kanchei Loa loa@ieee.org From owner-multi6@ops.ietf.org Tue Mar 9 01:46:44 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27216 for ; Tue, 9 Mar 2004 01:46:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B0azB-0009AU-4n for multi6-data@psg.com; Tue, 09 Mar 2004 06:45:05 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B0ays-00091M-1v for multi6@ops.ietf.org; Tue, 09 Mar 2004 06:44:46 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i296ijl04727 for ; Tue, 9 Mar 2004 08:44:45 +0200 Date: Tue, 9 Mar 2004 08:44:45 +0200 (EET) From: Pekka Savola To: multi6@ops.ietf.org Subject: delayed multihoming to lear-multi6-things-to-think-about? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Hi, Maybe we should add something like this around 2.3.4 ("Will your solution add additional latency?"), just to spell out a consideration pointed out earlier by me, Dave C., and others: ====== 2.3.5 Can multihoming setup be delayed from session setup? If the proposal induces overhead (added bytes in packets, or additional packets), is it possible to delay that overhead (or "multihoming set-up") to happen after the session has been established? That is, is it possible to specify that multihoming benefits would only be achieved for sessions which last over XX seconds, to optimize away the cost of set-up for short-lived sessions? ====== makes sense? IMHO, this is especially interesting for protocols which require more signalling than the original session startup, i.e., are not able to piggyback it on the existing packets. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Tue Mar 9 01:50:02 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27363 for ; Tue, 9 Mar 2004 01:50:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B0b3A-000B6G-AC for multi6-data@psg.com; Tue, 09 Mar 2004 06:49:12 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B0b2z-000B0o-C0 for multi6@ops.ietf.org; Tue, 09 Mar 2004 06:49:01 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i296n0d04810 for ; Tue, 9 Mar 2004 08:49:00 +0200 Date: Tue, 9 Mar 2004 08:49:00 +0200 (EET) From: Pekka Savola To: multi6@ops.ietf.org Subject: multihoming goals and lear-multi6-things-to-think-about? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Hi, As I mentioned in the meeting, I think there is a problem in understanding the multihoming goals RFC, as evidenced by a couple of solutions describing e.g., how they solve traffic engineering problem. (That is, we're interested of *site* traffic engineering, not *node* TE.) Should we include a section in draft-lear-multi6-things-to-think-about which tries to briefly describe (again :) the actual goals of the multihoming goals RFC -- or should we just stick to asking a few pointed questions in draft-lear-... ? Opinions? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Tue Mar 9 03:01:33 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13210 for ; Tue, 9 Mar 2004 03:01:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B0c7V-000HRX-SL for multi6-data@psg.com; Tue, 09 Mar 2004 07:57:45 +0000 Received: from [192.71.80.74] (helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B0c7K-000HKf-Pv for multi6@ops.ietf.org; Tue, 09 Mar 2004 07:57:35 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id A3B6F314A9F; Tue, 9 Mar 2004 08:58:02 +0100 (CET) In-Reply-To: <173148923.20040308142657@brandenburg.com> References: <404B1EC8.62268A70@zurich.ibm.com> <173148923.20040308142657@brandenburg.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=fixed Message-Id: <7AC44F19-719F-11D8-B4D0-000A95928574@kurtis.pp.se> Content-Transfer-Encoding: 7bit Cc: multi6@ops.ietf.org, Brian E Carpenter , Kanchei Loa From: Kurt Erik Lindqvist Subject: Re: two perspectives on "site" multihoming Date: Tue, 9 Mar 2004 08:57:58 +0100 To: dhcnotice X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dave, > One is at the site-level, of course. Hence the focus is on > network-level > mechanisms. An example would be a network-agile method of addressing > while holding the host portion constant, and then filling in the > correct > network portion at the exit router. Presumably this would leave the > host untouched. > > The other approach is at the host-level, where the exit router is > essentially unaware of the mechanism -- return filtering issues > notwithstanding. The model has the host do all the work and can, in > fact, leave the exit router unchanged. So, the host is address-agile. > > It is worth noting that this approach has the option of being > implemented at the site level, largely transparent to the host, for > easy > adoption by sites. Or it can be adopted at the host level, for easy > adoption by those hosts, without having to recruit site administration > to the effort. I think your second scenario (without a modified exit router) is a mobile node. More or less. And I wouldn't describe that as site multihoming. There is a scaling component from a administrative point of view involved. IMHO the first scenario and a scenario where there is interaction between the hosts and the site-exit routers, are site multihoming. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQE15CaarNKXTPFCVEQIygQCfex+D0yN97z2JrsW7PMc3TRHXuTwAni73 olVsPn6cd9E3lplELko0+cya =LEtE -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Tue Mar 9 03:22:41 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13984 for ; Tue, 9 Mar 2004 03:22:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B0cSm-0001pE-OZ for multi6-data@psg.com; Tue, 09 Mar 2004 08:19:44 +0000 Received: from [192.71.80.74] (helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B0cRx-0001S1-TC for multi6@ops.ietf.org; Tue, 09 Mar 2004 08:18:54 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id 05BA4314BCE; Tue, 9 Mar 2004 09:19:21 +0100 (CET) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=fixed Message-Id: <752477C0-71A2-11D8-B4D0-000A95928574@kurtis.pp.se> Content-Transfer-Encoding: 7bit Cc: multi6@ops.ietf.org From: Kurt Erik Lindqvist Subject: Re: multihoming goals and lear-multi6-things-to-think-about? Date: Tue, 9 Mar 2004 09:19:17 +0100 To: Pekka Savola X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-03-09, at 07.49, Pekka Savola wrote: > Hi, > > As I mentioned in the meeting, I think there is a problem in > understanding the multihoming goals RFC, as evidenced by a couple of > solutions describing e.g., how they solve traffic engineering problem. > (That is, we're interested of *site* traffic engineering, not *node* > TE.) > > Should we include a section in > draft-lear-multi6-things-to-think-about which tries to briefly > describe (again :) the actual goals of the multihoming goals RFC -- or > should we just stick to asking a few pointed questions in > draft-lear-... ? > > Opinions? I think the pointed questions makes more sense. There is no point in using draft-lear to explain 3582. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQE1+CKarNKXTPFCVEQJjpwCdG+URmbkl4KHNmrGL/GSGpYb22moAoORo /ct0ZcmDNj7XQVAvOyZoNsKW =roZ9 -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Tue Mar 9 03:44:45 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15237 for ; Tue, 9 Mar 2004 03:44:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B0cpz-000Cve-Kd for multi6-data@psg.com; Tue, 09 Mar 2004 08:43:43 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.30; FreeBSD) id 1B0cpo-000Cul-Pn for multi6@ops.ietf.org; Tue, 09 Mar 2004 08:43:32 +0000 Received: (qmail 76823 invoked from network); 9 Mar 2004 08:45:01 -0000 Received: from yahoobb219178198119.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.178.198.119) by necom830.hpcl.titech.ac.jp with SMTP; 9 Mar 2004 08:45:01 -0000 Message-ID: <404D8444.9060700@necom830.hpcl.titech.ac.jp> Date: Tue, 09 Mar 2004 17:45:56 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Kanchei Loa CC: multi6@ops.ietf.org Subject: Re: on the point of mobility & multihoming References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Kanchei; > Well, a connection between exit router and ISP using "100 base T with 500m > UTP-3 cables and 10 dumb hubs" is out of the specification of IEEE standard. > The user won't expect M6 solution would work on an out-of-spec connection > nor should this WG. But the same user would expect M6 solution maintains > reasonable performance (or degrade gracefully) with his "within-spec" > wireless link to ISP independent of the weather condition. What, do you mean, "within-spec" of, say, 11b. With some definition of "within-spec", what performance is expected by the standard? To answer the questions, quote the standard, please. Masataka Ohta From owner-multi6@ops.ietf.org Tue Mar 9 04:28:54 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17278 for ; Tue, 9 Mar 2004 04:28:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B0dVT-000NjW-Qo for multi6-data@psg.com; Tue, 09 Mar 2004 09:26:35 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B0dVJ-000Ni9-8T for multi6@ops.ietf.org; Tue, 09 Mar 2004 09:26:25 +0000 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 09 Mar 2004 01:39:55 +0000 Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i299QMY6027055; Tue, 9 Mar 2004 01:26:22 -0800 (PST) Received: from cisco.com (sjc-vpn4-306.cisco.com [10.21.81.50]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id BAA11316; Tue, 9 Mar 2004 01:26:21 -0800 (PST) Message-ID: <404D8DC1.70907@cisco.com> Date: Tue, 09 Mar 2004 01:26:25 -0800 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: multi6@ops.ietf.org Subject: Re: multihoming goals and lear-multi6-things-to-think-about? References: In-Reply-To: X-Enigmail-Version: 0.83.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Pekka, I would not feel comfortable restating what is already written rather well. It probably would cause more confusion than help. Those who are actually doing the solutions should be aware of RFC 3582, and should have read it cover to cover and understood its context. There's no substitute. Eliot Pekka Savola wrote: > Hi, > > As I mentioned in the meeting, I think there is a problem in > understanding the multihoming goals RFC, as evidenced by a couple of > solutions describing e.g., how they solve traffic engineering problem. > (That is, we're interested of *site* traffic engineering, not *node* > TE.) > > Should we include a section in > draft-lear-multi6-things-to-think-about which tries to briefly > describe (again :) the actual goals of the multihoming goals RFC -- or > should we just stick to asking a few pointed questions in > draft-lear-... ? > > Opinions? > From owner-multi6@ops.ietf.org Tue Mar 9 09:18:13 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28217 for ; Tue, 9 Mar 2004 09:18:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B0i11-0000zj-4v for multi6-data@psg.com; Tue, 09 Mar 2004 14:15:27 +0000 Received: from [195.212.29.154] (helo=mtagate5.de.ibm.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B0i0h-0000or-99 for multi6@ops.ietf.org; Tue, 09 Mar 2004 14:15:07 +0000 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by mtagate5.de.ibm.com (8.12.10/8.12.10) with ESMTP id i29EF3e2148988; Tue, 9 Mar 2004 14:15:03 GMT Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay01.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i29EF66c217720; Tue, 9 Mar 2004 15:15:07 +0100 Received: from zurich.ibm.com (gsine09.us.sine.ibm.com [9.14.6.39]) by collon.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with SMTP id PAA25546; Tue, 9 Mar 2004 15:14:56 +0100 Message-ID: <404D8393.F0C27A2@zurich.ibm.com> Date: Tue, 09 Mar 2004 09:42:59 +0100 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: Kanchei Loa CC: multi6@ops.ietf.org Subject: Re: on the point of mobility & multihoming References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=BAYES_00,DATE_IN_PAST_03_06 autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Kanchei Loa wrote: (Note: some of Kanchei's posts have been delayed by a mailing list issue... apologies if this seems out of sequence.) > > > Brian E Carpenter wrote: > > > Kenchei, > > > > I really think you miss my points. > > > > Firstly, this is not the MANET WG, and we are clearly chartered by > > the IESG to work on site multihoming in its classical sense, where > > if we come down to basics, the main goal is to prevent a BGP explosion. > > > > Actually, we are in agreement here regarding "the main goal is to prevent a > BGP explosion" for this WG. > But I should clarify that Dave Croker's scenario is not a MANET problem as > you assumed. The combined Dave's and Geoff's Personal Area Network is at > link layer (like L2 bridging). From IP routing point of view it is a single > IP subnet with 4 exit routers to 4 ISPs. There is no IP MANET running > anywhere. However, if there is no BGP running between exit router and ISP, > then it has nothing to do with BGP explosion. Correct; it's effectively a small network (what we've often referred to as a dentist's office network) which happens to be connected as a subscriber to several ISPs. But we do expect [RFC 3177] it to have a /48 or /64 prefix from each of those ISPs, and it is indeed to keep those out of the DFZ that we need a multi6 solution. (Yes, this is elementary, but it does no harm to recall the elementary problem from time to time.) > Is multi6 only deal with the architecture where BGP is running between exit > router and ISP ? No... if we did that, we would not solve the problem. My point is really that walk-in-the-park example doesn't (in my view) change the problem space (at least not the problem space that I believe we are working on). > > Secondly, there is nothing academic about observing that it is irrelevant > > whether physical links go up and down due to trucks blocking a > > wireless signal > > or due to random wires being disconnected. We are looking for a > > solution that doesn't care why the physical signal fails. > > > > Brian > > Agree. We are looking for a solution that doesn't care why the physical > signal fails and the frequency of failing. > > In my branch office scenario BGP is running between exit routers and ISPs. > Does this scenario fit multi6 WG charter ? Yes... but as indicated above, a scenario without BGP fits also. > If the answer is "no", I will rest my case. But please clarify your > definition of "site multihoming in its classical sense" and why my branch > office scenario doesn't fit your definition. > > If the answer is "yes", then we are back to the original debate of this > thread. > Multiaddress mulithoming and mobility solutions must incorporate the same > mechanisms: > 1. multiplexing in the presence of more than one address pair > 2. adding/removing addresses > 3. failover > 4. rendezvous > There is no difference between multihoming and mobility. I'm afraid I don't think that follows, but I would rather argue the point when Geoff has written up a first version of the architectural analysis. However, to scratch the surface of the argument, there is one physical difference - in the site multihoming case I don't see that there is a rendezvous issue. The set of connections that may be used is defined and configured in advance, whereas in mobility it is unknown in advance and requires discovery, rendezvous and AAA mechanisms. > In my branch office scenario "traffic driving by disconnects constantly > changes branch office's preferred access point". The physical signal between > exit router and ISP could fail due to (1) plug-and-unplug connectors (wired > connection) (2) weather or other RF factors (wireless connection) (3) > changing distance (mobility). The solution for multihoming designed for (1) > and (2) should solve (3) as well. From IP multihoming point of view, why > the signal fails is irrelevant to the solution. "We are looking for a > solution that doesn't care why the physical signal fails". > > My point, for what it worth, is that we should kill two birds in one stone > because there is only one bird if you get closer and exam it carefully. Both > coming architecture and operation documents should make it clear that > mobility is not an add-on feature for multihoming, such that we could > categorize and evaluation solutions/recommendations accordingly. > > Note: How do we word it is another story. MIP has been given IP mobility a > bad name, which is usually related to complex signaling and awkward > tunneling schemes. May be we just call it dynamic multihoming instead of > mobility. It may be that by *adding* a discovery, rendezvous and AAA package to the multi6 solution, we will get a new mobility mechanism. We should certainly keep that in mind in the architecture discussion Brian > > > > Kanchei Loa wrote: > > > > > > > > In my opinion, you just hit an important issue of multi6 > > architecture, > > > which > > > > > this WG is supposed to work on first. If we take Dave > > Croker's scenario > > > > > (suggested by Geoff Huston) and generalize it, the problem > > space is the > > > same > > > > > as depicted in Geoff's slide (page 3) of "An Architectural View of > > > Multi6 > > > > > proposals" except that the solid line (wired fixed > > connection) between > > > the > > > > > exit route and ISP is replace by dotted lines (wireless dynamic > > > > > connections). > > > > > > > > > > In this architecture, mobility is just a special case of > > "dynamic ad hoc > > > > > multihoming", which has timing restriction on updates and discovery. > > > (You > > > > > don't have to call it mobility if that is more IETF > > political correct). > > > In > > > > > Dave's scenario, from IP network's point of view, there is > > no difference > > > > > between a laptop sitting on a bench switching among ISPs because of > > > > > interference and a laptop sitting in a car that is moving > > back and forth > > > > > among ISPs. > > > > > > > > > > Should multi6 architecture encompass wireless connections > > between the > > > exit > > > > > router and IPS? Or, Dave Croker's scenario is too far away > > in the future > > > to > > > > > be included in multi6 architecture, which has been focusing on > > > traditional > > > > > IP multihoming with fixed connections only? It is up to the WG to > > > decide. > > > > > But the architecture document should spell out the rational > > choice. The > > > > > "uncomfortable" wireless issues won't goes away if we just choose to > > > ignore > > > > > them or call it something else. > > > > > > > Brian E Carpenter wrote: > > > > > > > Actually, it isn't up to the WG to decide. We are chartered > > to deal with > > > > _site multihoming_. That is definitely a different problem > > space from host > > > > multihoming in the form of ISP roaming. > > > > > > > > > > Now I know where the problem is. In Dave's scenario, the Personal Area > > > Network (PAN) surrounding him in the park is the "site", which > > consists of > > > laptop, PDA, game console, headphone, MP3 player, digital > > camera, and dual > > > mode handset (UMTS and 802.11b). The exit routers are laptop > > with 802.11g, > > > and handset with UMTS and 802.11b. Later, Dave's friend Geoff, > > sitting next > > > him on the same bench, join him to work on multi6 drafts. So, > > Dave's PAN and > > > Geoff's PAN are forming a new "site" with 4 exit routers (Dave's > > > laptop(802.11g), handset (UMTS, 802.11b), and Geoff's laptop > > (802.11a) and > > > handset (WCDMA and 802.11g). This new "site" should be able to > > take full > > > advantage of 4 redundant wireless ISP connections, even the interference > > > might knock out one or two ISP from time to time. > > > > > > If you consider above expanded scenario of a "site multioming" is too > > > "non-traditional", then let's try a traditional one. An branch office in > > > downtown has 4 exit routers to 5 ISP. Router a connects to ISP A through > > > wired cable modem (cost $55 per month) as primary Internet > > link. Router b > > > connects to ISP B through 802.16 wireless link (cost $60 per > > month) on the > > > roof top dish as backup Internet link. Router c connects to > > ISP C through > > > 802.11a corporate backbone (cost $100 per month) in adjacent building as > > > corporate resources access and backup Internet link. Router d > > connects to > > > local community networks (cost $50 per month), which are served by two > > > 802.11b providers ISP Da and ISP Db. This branch office is > > setup to support > > > their business in local community. So, router d is as important as other > > > exit routers. When the weather is bad or other RF factors, > > traffic driving > > > by disconnects constantly changes branch office's preferred > > access point. > > > > > > My point is that wireless exit connection to ISP is not an > > invisible wired > > > connection. It injects "ad hoc" factor into both traditional and > > > non-traditional site multihoming. That is definitely NOT a > > different problem > > > space from _site multihoming_ we are chartered to deal with unless you > > > exclude wireless in the charter. The host multihoming with "ISP > > roaming" is > > > just a special case of site multihoming where exit router and > > host are on > > > the same machine. > > > > > > > (Also, I don't see what wireless has to do with it. If I sit > > in front of > > > two > > > > Ethernet plugs leading to two ISPs, and move my connector from > > > > one to the other every two minutes, the problem is the same - > > but it is > > > *not* site > > > > multihoming.) > > > > > > > > Brian > > > > > > The "wireless" make "ad hoc site multihoming" a practical engineering > > > problem for any Internet community who follows IETF's lead. > > Your example of > > > plug-and-unplug Ethernet belongs to academic research not IETF. > > In above > > > scenario if all connection to ISPs are wired links, it won't > > make any sense > > > to create a multihoming protocol by this WG to deal with the > > situation that > > > a administrator plug-and-unplug Ethernet connector of exit > > routers at will > > > every two minutes. However, "wireless" causes the same plug-and-unplug > > > scenario a practical engineering problem we have to deal with. > > My opinion, > > > for what it's worth, is that the arguments of ad hoc > > multihoming should be > > > thrown out if the consensus is that wireless is not in WG's equation. > > > > > > In 1992 Dave Clark said "We reject kings, presidents, and > > voting. We believe > > > in rough consensus and running code". In my opinion, majority > > of the IPv6 > > > running codes are going to be deployed on wireless networks. > > > > > > ----------------- > > > Kanchei Loa > > > loa@ieee.org > > > > -- > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > Brian E Carpenter > > Distinguished Engineer, Internet Standards & Technology, IBM > > > > -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM From owner-multi6@ops.ietf.org Tue Mar 9 09:30:55 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28716 for ; Tue, 9 Mar 2004 09:30:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B0iEz-0006jp-EK for multi6-data@psg.com; Tue, 09 Mar 2004 14:29:53 +0000 Received: from [195.212.29.152] (helo=mtagate3.de.ibm.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B0iEo-0006fj-54 for multi6@ops.ietf.org; Tue, 09 Mar 2004 14:29:42 +0000 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id i29ETQHI103004; Tue, 9 Mar 2004 14:29:26 GMT Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay02.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i29ETRWC249368; Tue, 9 Mar 2004 15:29:27 +0100 Received: from zurich.ibm.com (gsine09.us.sine.ibm.com [9.14.6.39]) by collon.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with SMTP id PAA56184; Tue, 9 Mar 2004 15:29:19 +0100 Message-ID: <404DD4DA.9A84AAE1@zurich.ibm.com> Date: Tue, 09 Mar 2004 15:29:46 +0100 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: Eliot Lear CC: Pekka Savola , multi6@ops.ietf.org Subject: Re: multihoming goals and lear-multi6-things-to-think-about? References: <404D8DC1.70907@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Eliot, Agreed. Looking at some of the drafts, I had a strong impression that some authors had read the section headings in 3582, but not the details, which were thoroughly debated. As Kurtis said, let's concentrate on sharpening up the questions in your draft. Brian Eliot Lear wrote: > > Hi Pekka, > > I would not feel comfortable restating what is already written rather > well. It probably would cause more confusion than help. Those who are > actually doing the solutions should be aware of RFC 3582, and should > have read it cover to cover and understood its context. There's no > substitute. > > Eliot > > Pekka Savola wrote: > > > Hi, > > > > As I mentioned in the meeting, I think there is a problem in > > understanding the multihoming goals RFC, as evidenced by a couple of > > solutions describing e.g., how they solve traffic engineering problem. > > (That is, we're interested of *site* traffic engineering, not *node* > > TE.) > > > > Should we include a section in > > draft-lear-multi6-things-to-think-about which tries to briefly > > describe (again :) the actual goals of the multihoming goals RFC -- or > > should we just stick to asking a few pointed questions in > > draft-lear-... ? > > > > Opinions? > > -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM From owner-multi6@ops.ietf.org Tue Mar 9 09:44:59 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29246 for ; Tue, 9 Mar 2004 09:44:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B0iSW-000CZO-Pn for multi6-data@psg.com; Tue, 09 Mar 2004 14:43:52 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B0iSL-000CW3-CG for multi6@ops.ietf.org; Tue, 09 Mar 2004 14:43:41 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i29EhT912890; Tue, 9 Mar 2004 16:43:29 +0200 Date: Tue, 9 Mar 2004 16:43:29 +0200 (EET) From: Pekka Savola To: Brian E Carpenter cc: Eliot Lear , Subject: Re: multihoming goals and lear-multi6-things-to-think-about? In-Reply-To: <404DD4DA.9A84AAE1@zurich.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 9 Mar 2004, Brian E Carpenter wrote: > Agreed. Looking at some of the drafts, I had a strong impression > that some authors had read the section headings in 3582, but > not the details, which were thoroughly debated. As Kurtis said, > let's concentrate on sharpening up the questions in your draft. Totally agree here. I guess the good question comes from whether we expect the user to fully understand nuances of the issues raised in 3582 or not. Two example questions: y.y.y Does the mechanism solve traffic engineering issues? A significant multihoming benefit today is the ability obtain traffic-engineering (whether for load sharing, performance, or policy) benefits. Does your solution solve these problems -- if so, how? Is this control possible in an "aggregated" fashion, for the whole (or parts) of the site, or must it be done individually for each host? x.x.x Manageability of the mechanism at site level? How is the site multihoming mechanism managed [RFC3582, 3.2.5]? In particular, does one have to manage each host individually, or is it possible to manage the mechanism in an "aggregated" fashion, for the whole site at a time? ... are these important enough to be added? I think these two are the ones that have been misunderstood the most often -- and adding these in the "things to think aboug" -document migth help in catching the folks who didn't think of these issues at enough depth. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Tue Mar 9 11:42:41 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07399 for ; Tue, 9 Mar 2004 11:42:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B0kGT-000C1u-EO for multi6-data@psg.com; Tue, 09 Mar 2004 16:39:33 +0000 Received: from [208.184.79.7] (helo=joy.songbird.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B0kGI-000BxH-C1 for multi6@ops.ietf.org; Tue, 09 Mar 2004 16:39:22 +0000 Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i29GmHd11343; Tue, 9 Mar 2004 08:48:17 -0800 Date: Tue, 9 Mar 2004 08:39:13 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <1098961872.20040309083913@brandenburg.com> To: Brian E Carpenter CC: Kanchei Loa , multi6@ops.ietf.org Subject: Re: on the point of mobility & multihoming In-Reply-To: <404D8393.F0C27A2@zurich.ibm.com> References: <404D8393.F0C27A2@zurich.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.7 required=5.0 tests=AWL,BAYES_00,PRIORITY_NO_NAME autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Brian, BEC> My point is really that walk-in-the-park example doesn't (in my view) BEC> change the problem space (at least not the problem space that I believe BEC> we are working on). ... >> Agree. We are looking for a solution that doesn't care why the physical >> signal fails and the frequency of failing. ... >> Multiaddress mulithoming and mobility solutions must incorporate the same >> mechanisms: ... BEC> is one physical difference - in the site multihoming case I don't see BEC> that there is a rendezvous issue. The set of connections that may be used BEC> is defined and configured in advance, whereas in mobility it is unknown BEC> in advance and requires discovery, rendezvous and AAA mechanisms. Multhihoming configuration changes over time, as does the availability of configured connections to the Internet. These changes in reachability are presumed to happen more slowly that with a mobile scenario, but the the other technical characteristics are pretty much the same. (We could quibble about full-scale outages, with no valid address, but otherwise it is multiple addresses, changing over time.) "In advance" does not apply to an existing connection when a multihome access is changed during the connection. The multihoming scenario that is probably driving folk's sense of difference between multihoming and mobility is: a) little or no change to the configuration, b) no need to apply the changes to existing connections. This is a useful set of constraints, but it is important to recognize the way they change the problem space. BEC> It may be that by *adding* a discovery, rendezvous and AAA package to BEC> the multi6 solution, we will get a new mobility mechanism. We should BEC> certainly keep that in mind in the architecture discussion yup. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-multi6@ops.ietf.org Tue Mar 9 12:35:54 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10333 for ; Tue, 9 Mar 2004 12:35:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B0l7i-0008BW-NK for multi6-data@psg.com; Tue, 09 Mar 2004 17:34:34 +0000 Received: from [68.6.19.241] (helo=fed1mtao04.cox.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B0l7X-00086k-RO for multi6@ops.ietf.org; Tue, 09 Mar 2004 17:34:23 +0000 Received: from momo ([68.2.220.20]) by fed1mtao04.cox.net (InterMail vM.5.01.06.08 201-253-122-130-108-20031117) with SMTP id <20040309173424.UUIU29098.fed1mtao04.cox.net@momo>; Tue, 9 Mar 2004 12:34:24 -0500 From: "Kanchei Loa" To: "Masataka Ohta" Cc: Subject: RE: on the point of mobility & multihoming Date: Tue, 9 Mar 2004 10:34:21 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <404D8444.9060700@necom830.hpcl.titech.ac.jp> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> Kanchei Loa wrote: > > Well, a connection between exit router and ISP using "100 base T with 500m > > UTP-3 cables and 10 dumb hubs" is out of the specification of IEEE standard. > > The user won't expect M6 solution would work on an out-of-spec connection > > nor should this WG. But the same user would expect M6 solution maintains > > reasonable performance (or degrade gracefully) with his "within-spec" > > wireless link to ISP independent of the weather condition. > > Masataka Ohta wrote: > What, do you mean, "within-spec" of, say, 11b. > > With some definition of "within-spec", what performance > is expected by the standard? > > To answer the questions, quote the standard, please. > Quote from IEEE 802.11 1999 edition ---------- 5.1.1 How wireless LAN systems are different Wireless networks have fundamental characteristics that make them significantly different from traditional wired LANs. Some countries impose specific requirements for radio equipment in addition to those specified in this standard. 5.1.1.1 Destination address does not equal destination location In wired LANs, an address is equivalent to a physical location. This is implicitly assumed in the design of wired LANs. In IEEE 802.11, the addressable unit is a station (STA). The STA is a message destination, but not (in general) a fixed location. 5.1.1.2 The media impact the design The physical layers used in IEEE 802.11 are fundamentally different from wired media. Thus IEEE 802.11 PHYs a) Use a medium that has neither absolute nor readily observable boundaries outside of which stations with conformant PHY transceivers are known to be unable to receive network frames. b) Are unprotected from outside signals. c) Communicate over a medium significantly less reliable than wired PHYs. d) Have dynamic topologies. e) Lack full connectivity, and therefore the assumption normally made that every STA can hear every other STA is invalid (i.e., STAs may be "hidden" from each other). f) Have time-varying and asymmetric propagation properties. Because of limitations on wireless PHY ranges, wireless LANs intended to cover reasonable geographic distances may be built from basic coverage building blocks. ---------------- end quote -------- The limitations on 802.11b PHY range vary with antenna configuration and local environment factors, which is the information provided by the ISP to subscribed users. I believe we are off-topic here. If you want to discuss what the 802.11b coverage is under various configurations, we should take it off-line. ------------ Kanchei Loa loa@ieee.org From owner-multi6@ops.ietf.org Tue Mar 9 14:46:10 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17584 for ; Tue, 9 Mar 2004 14:46:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B0n8w-0002xC-7q for multi6-data@psg.com; Tue, 09 Mar 2004 19:43:58 +0000 Received: from [68.6.19.123] (helo=fed1mtao08.cox.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B0n8l-0002vI-9X for multi6@ops.ietf.org; Tue, 09 Mar 2004 19:43:47 +0000 Received: from momo ([68.2.220.20]) by fed1mtao08.cox.net (InterMail vM.5.01.06.08 201-253-122-130-108-20031117) with SMTP id <20040309194345.BDPP5081.fed1mtao08.cox.net@momo>; Tue, 9 Mar 2004 14:43:45 -0500 From: "Kanchei Loa" To: "Brian E Carpenter" Cc: Subject: RE: on the point of mobility & multihoming Date: Tue, 9 Mar 2004 12:43:44 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <404D8393.F0C27A2@zurich.ibm.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Brian, I still disagree on some of your points regarding the problem space (as Dave's reply depicted). But I would hold my arguments until Geoff has written up a first version of the architecture draft (assuming he is going to address this issue). Kanchei --------- Kanchei Loa loa@ieee.org > -----Original Message----- > From: Brian E Carpenter [mailto:brc@zurich.ibm.com] > Sent: Tuesday, March 09, 2004 1:43 AM > To: Kanchei Loa > Cc: multi6@ops.ietf.org > Subject: Re: on the point of mobility & multihoming > > > Kanchei Loa wrote: > > (Note: some of Kanchei's posts have been delayed by a mailing list > issue... apologies if this seems out of sequence.) > > > > > > Brian E Carpenter wrote: > > > > > Kenchei, > > > > > > I really think you miss my points. > > > > > > Firstly, this is not the MANET WG, and we are clearly chartered by > > > the IESG to work on site multihoming in its classical sense, where > > > if we come down to basics, the main goal is to prevent a BGP > explosion. > > > > > > > Actually, we are in agreement here regarding "the main goal is > to prevent a > > BGP explosion" for this WG. > > But I should clarify that Dave Croker's scenario is not a MANET > problem as > > you assumed. The combined Dave's and Geoff's Personal Area Network is at > > link layer (like L2 bridging). From IP routing point of view it > is a single > > IP subnet with 4 exit routers to 4 ISPs. There is no IP MANET running > > anywhere. However, if there is no BGP running between exit > router and ISP, > > then it has nothing to do with BGP explosion. > > Correct; it's effectively a small network (what we've often referred to as > a dentist's office network) which happens to be connected as a subscriber > to several ISPs. But we do expect [RFC 3177] it to have a /48 or > /64 prefix > from each of those ISPs, and it is indeed to keep those out of > the DFZ that we > need a multi6 solution. (Yes, this is elementary, but it does no harm to > recall the elementary problem from time to time.) > > > Is multi6 only deal with the architecture where BGP is running > between exit > > router and ISP ? > > No... if we did that, we would not solve the problem. > > My point is really that walk-in-the-park example doesn't (in my view) > change the problem space (at least not the problem space that I believe > we are working on). > > > > Secondly, there is nothing academic about observing that it > is irrelevant > > > whether physical links go up and down due to trucks blocking a > > > wireless signal > > > or due to random wires being disconnected. We are looking for a > > > solution that doesn't care why the physical signal fails. > > > > > > Brian > > > > Agree. We are looking for a solution that doesn't care why the physical > > signal fails and the frequency of failing. > > > > In my branch office scenario BGP is running between exit > routers and ISPs. > > Does this scenario fit multi6 WG charter ? > > Yes... but as indicated above, a scenario without BGP fits also. > > > If the answer is "no", I will rest my case. But please clarify your > > definition of "site multihoming in its classical sense" and why > my branch > > office scenario doesn't fit your definition. > > > > If the answer is "yes", then we are back to the original debate of this > > thread. > > Multiaddress mulithoming and mobility solutions must > incorporate the same > > mechanisms: > > 1. multiplexing in the presence of more than one address pair > > 2. adding/removing addresses > > 3. failover > > 4. rendezvous > > There is no difference between multihoming and mobility. > > I'm afraid I don't think that follows, but I would rather argue the > point when Geoff has written up a first version of the architectural > analysis. However, to scratch the surface of the argument, there > is one physical difference - in the site multihoming case I don't see > that there is a rendezvous issue. The set of connections that may be used > is defined and configured in advance, whereas in mobility it is unknown > in advance and requires discovery, rendezvous and AAA mechanisms. > > > In my branch office scenario "traffic driving by disconnects constantly > > changes branch office's preferred access point". The physical > signal between > > exit router and ISP could fail due to (1) plug-and-unplug > connectors (wired > > connection) (2) weather or other RF factors (wireless connection) (3) > > changing distance (mobility). The solution for multihoming > designed for (1) > > and (2) should solve (3) as well. From IP multihoming point of > view, why > > the signal fails is irrelevant to the solution. "We are looking for a > > solution that doesn't care why the physical signal fails". > > > > My point, for what it worth, is that we should kill two birds > in one stone > > because there is only one bird if you get closer and exam it > carefully. Both > > coming architecture and operation documents should make it clear that > > mobility is not an add-on feature for multihoming, such that we could > > categorize and evaluation solutions/recommendations accordingly. > > > > Note: How do we word it is another story. MIP has been given IP > mobility a > > bad name, which is usually related to complex signaling and awkward > > tunneling schemes. May be we just call it dynamic multihoming instead of > > mobility. > > It may be that by *adding* a discovery, rendezvous and AAA package to > the multi6 solution, we will get a new mobility mechanism. We should > certainly keep that in mind in the architecture discussion > > Brian > > > > > > > > Kanchei Loa wrote: > > > > > > > > > > In my opinion, you just hit an important issue of multi6 > > > architecture, > > > > which > > > > > > this WG is supposed to work on first. If we take Dave > > > Croker's scenario > > > > > > (suggested by Geoff Huston) and generalize it, the problem > > > space is the > > > > same > > > > > > as depicted in Geoff's slide (page 3) of "An > Architectural View of > > > > Multi6 > > > > > > proposals" except that the solid line (wired fixed > > > connection) between > > > > the > > > > > > exit route and ISP is replace by dotted lines (wireless dynamic > > > > > > connections). > > > > > > > > > > > > In this architecture, mobility is just a special case of > > > "dynamic ad hoc > > > > > > multihoming", which has timing restriction on updates > and discovery. > > > > (You > > > > > > don't have to call it mobility if that is more IETF > > > political correct). > > > > In > > > > > > Dave's scenario, from IP network's point of view, there is > > > no difference > > > > > > between a laptop sitting on a bench switching among > ISPs because of > > > > > > interference and a laptop sitting in a car that is moving > > > back and forth > > > > > > among ISPs. > > > > > > > > > > > > Should multi6 architecture encompass wireless connections > > > between the > > > > exit > > > > > > router and IPS? Or, Dave Croker's scenario is too far away > > > in the future > > > > to > > > > > > be included in multi6 architecture, which has been focusing on > > > > traditional > > > > > > IP multihoming with fixed connections only? It is up to > the WG to > > > > decide. > > > > > > But the architecture document should spell out the rational > > > choice. The > > > > > > "uncomfortable" wireless issues won't goes away if we > just choose to > > > > ignore > > > > > > them or call it something else. > > > > > > > > > Brian E Carpenter wrote: > > > > > > > > > Actually, it isn't up to the WG to decide. We are chartered > > > to deal with > > > > > _site multihoming_. That is definitely a different problem > > > space from host > > > > > multihoming in the form of ISP roaming. > > > > > > > > > > > > > Now I know where the problem is. In Dave's scenario, the > Personal Area > > > > Network (PAN) surrounding him in the park is the "site", which > > > consists of > > > > laptop, PDA, game console, headphone, MP3 player, digital > > > camera, and dual > > > > mode handset (UMTS and 802.11b). The exit routers are laptop > > > with 802.11g, > > > > and handset with UMTS and 802.11b. Later, Dave's friend Geoff, > > > sitting next > > > > him on the same bench, join him to work on multi6 drafts. So, > > > Dave's PAN and > > > > Geoff's PAN are forming a new "site" with 4 exit routers (Dave's > > > > laptop(802.11g), handset (UMTS, 802.11b), and Geoff's laptop > > > (802.11a) and > > > > handset (WCDMA and 802.11g). This new "site" should be able to > > > take full > > > > advantage of 4 redundant wireless ISP connections, even the > interference > > > > might knock out one or two ISP from time to time. > > > > > > > > If you consider above expanded scenario of a "site > multioming" is too > > > > "non-traditional", then let's try a traditional one. An > branch office in > > > > downtown has 4 exit routers to 5 ISP. Router a connects to > ISP A through > > > > wired cable modem (cost $55 per month) as primary Internet > > > link. Router b > > > > connects to ISP B through 802.16 wireless link (cost $60 per > > > month) on the > > > > roof top dish as backup Internet link. Router c connects to > > > ISP C through > > > > 802.11a corporate backbone (cost $100 per month) in > adjacent building as > > > > corporate resources access and backup Internet link. Router d > > > connects to > > > > local community networks (cost $50 per month), which are > served by two > > > > 802.11b providers ISP Da and ISP Db. This branch office is > > > setup to support > > > > their business in local community. So, router d is as > important as other > > > > exit routers. When the weather is bad or other RF factors, > > > traffic driving > > > > by disconnects constantly changes branch office's preferred > > > access point. > > > > > > > > My point is that wireless exit connection to ISP is not an > > > invisible wired > > > > connection. It injects "ad hoc" factor into both traditional and > > > > non-traditional site multihoming. That is definitely NOT a > > > different problem > > > > space from _site multihoming_ we are chartered to deal with > unless you > > > > exclude wireless in the charter. The host multihoming with "ISP > > > roaming" is > > > > just a special case of site multihoming where exit router and > > > host are on > > > > the same machine. > > > > > > > > > (Also, I don't see what wireless has to do with it. If I sit > > > in front of > > > > two > > > > > Ethernet plugs leading to two ISPs, and move my connector from > > > > > one to the other every two minutes, the problem is the same - > > > but it is > > > > *not* site > > > > > multihoming.) > > > > > > > > > > Brian > > > > > > > > The "wireless" make "ad hoc site multihoming" a practical > engineering > > > > problem for any Internet community who follows IETF's lead. > > > Your example of > > > > plug-and-unplug Ethernet belongs to academic research not IETF. > > > In above > > > > scenario if all connection to ISPs are wired links, it won't > > > make any sense > > > > to create a multihoming protocol by this WG to deal with the > > > situation that > > > > a administrator plug-and-unplug Ethernet connector of exit > > > routers at will > > > > every two minutes. However, "wireless" causes the same > plug-and-unplug > > > > scenario a practical engineering problem we have to deal with. > > > My opinion, > > > > for what it's worth, is that the arguments of ad hoc > > > multihoming should be > > > > thrown out if the consensus is that wireless is not in WG's > equation. > > > > > > > > In 1992 Dave Clark said "We reject kings, presidents, and > > > voting. We believe > > > > in rough consensus and running code". In my opinion, majority > > > of the IPv6 > > > > running codes are going to be deployed on wireless networks. > > > > > > > > ----------------- > > > > Kanchei Loa > > > > loa@ieee.org > > > > > > -- > > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > > Brian E Carpenter > > > Distinguished Engineer, Internet Standards & Technology, IBM > > > > > > > > -- > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > Brian E Carpenter > Distinguished Engineer, Internet Standards & Technology, IBM > > > From owner-multi6@ops.ietf.org Tue Mar 9 16:37:17 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29731 for ; Tue, 9 Mar 2004 16:37:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B0osf-0007BM-NH for multi6-data@psg.com; Tue, 09 Mar 2004 21:35:17 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B0osU-00072u-6F for multi6@ops.ietf.org; Tue, 09 Mar 2004 21:35:06 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i29LZ3GF065624; Tue, 9 Mar 2004 22:35:11 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <404D8393.F0C27A2@zurich.ibm.com> References: <404D8393.F0C27A2@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Multi6 List From: Iljitsch van Beijnum Subject: Re: on the point of mobility & multihoming Date: Tue, 9 Mar 2004 20:56:25 +0100 To: Brian E Carpenter X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 9-mrt-04, at 9:42, Brian E Carpenter wrote: >> Multiaddress mulithoming and mobility solutions must incorporate the >> same >> mechanisms: >> 1. multiplexing in the presence of more than one address pair >> 2. adding/removing addresses >> 3. failover >> 4. rendezvous >> There is no difference between multihoming and mobility. > I'm afraid I don't think that follows, but I would rather argue the > point when Geoff has written up a first version of the architectural > analysis. However, to scratch the surface of the argument, there > is one physical difference - in the site multihoming case I don't see > that there is a rendezvous issue. I'm not so sure. In mobility, we need to know the current address of the correspondent. In multihoming, we need to know which of the correspondent's addresses is currently working, and of the working addresses, which is preferred. This is not fundamentally different, or at least it doesn't have to. Obviously there are many details that will differ in practice, but multiaddressing is multiaddressing regardless of how it's first approached. However, I'm not sure if adding all the mobility requirements to our list at this time is helpful, the same way I'm not convinced rehashing policy and load balancing *now* is helpful. If we can come up with a synthesis of what's on the table now that is sound both in architecture and security, there should be ample opportunity to add the other stuff later. Granted, there is a slight chance we paint ourselves in a corner with regards to those issues now, but I'm willing to take that risk for the sake of focussing the discussion so we can achieve some results. (And could you guys PLEASE stop repeating each other's postings in full? I'm beginning to feel sorry for the poor mailing list archive.) From owner-multi6@ops.ietf.org Tue Mar 9 16:38:25 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29879 for ; Tue, 9 Mar 2004 16:38:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B0oui-0007oy-DO for multi6-data@psg.com; Tue, 09 Mar 2004 21:37:24 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.30; FreeBSD) id 1B0ouX-0007gv-JY for multi6@ops.ietf.org; Tue, 09 Mar 2004 21:37:13 +0000 Received: (qmail 79877 invoked from network); 9 Mar 2004 21:38:52 -0000 Received: from yahoobb219178198119.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.178.198.119) by necom830.hpcl.titech.ac.jp with SMTP; 9 Mar 2004 21:38:52 -0000 Message-ID: <404E3999.4000202@necom830.hpcl.titech.ac.jp> Date: Wed, 10 Mar 2004 06:39:37 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Kanchei Loa CC: multi6@ops.ietf.org Subject: Re: on the point of mobility & multihoming References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Kanchei Loa; > Because of limitations on wireless PHY ranges, wireless LANs intended to > cover reasonable geographic distances may be built from basic coverage > building blocks. So, use it reasonably, just as use 100 base T reasonably. Or you will suffer, regardless of whatever technology you might use. > I believe we are off-topic here. You are off-topic from the beginning. Masataka Ohta From owner-multi6@ops.ietf.org Wed Mar 10 01:16:03 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21625 for ; Wed, 10 Mar 2004 01:16:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B0wyB-00051z-Qq for multi6-data@psg.com; Wed, 10 Mar 2004 06:13:31 +0000 Received: from [68.6.19.123] (helo=fed1mtao08.cox.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B0wxl-0004xu-3B for multi6@ops.ietf.org; Wed, 10 Mar 2004 06:13:05 +0000 Received: from momo ([68.2.220.20]) by fed1mtao08.cox.net (InterMail vM.5.01.06.08 201-253-122-130-108-20031117) with SMTP id <20040310061301.HRJU18087.fed1mtao08.cox.net@momo>; Wed, 10 Mar 2004 01:13:01 -0500 From: "Kanchei Loa" To: "Kurt Erik Lindqvist" Cc: , "Brian E Carpenter" , "dhcnotice" Subject: RE: two perspectives on "site" multihoming Date: Tue, 9 Mar 2004 23:12:59 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <7AC44F19-719F-11D8-B4D0-000A95928574@kurtis.pp.se> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > Dave Crocker wrote: > > One is at the site-level, of course. Hence the focus is on > > network-level > > mechanisms. An example would be a network-agile method of addressing > > while holding the host portion constant, and then filling in the > > correct > > network portion at the exit router. Presumably this would leave the > > host untouched. > > > > The other approach is at the host-level, where the exit router is > > essentially unaware of the mechanism -- return filtering issues > > notwithstanding. The model has the host do all the work and can, in > > fact, leave the exit router unchanged. So, the host is address-agile. > > > > It is worth noting that this approach has the option of being > > implemented at the site level, largely transparent to the host, for > > easy > > adoption by sites. Or it can be adopted at the host level, for easy > > adoption by those hosts, without having to recruit site administration > > to the effort. > > Kurt Erik Lindqvist wrote: > I think your second scenario (without a modified exit router) is a > mobile node. More or less. And I wouldn't describe that as site > multihoming. There is a scaling component from a administrative point > of view involved. IMHO the first scenario and a scenario where there is > interaction between the hosts and the site-exit routers, are site > multihoming. > Dave's second scenario of host agile solution is a legitimate multihoming and "mobile node" at the same time. Brian Carpenter said " if we come down to basics, the main goal (of this WG) is to prevent a BGP explosion". He also said "it's (a branch office) effectively a small network (what we've often referred to as a dentist's office network) which happens to be connected as a subscriber to several ISPs. But we do expect [RFC 3177] it to have a /48 or /64 prefix from each of those ISPs, and it is indeed to keep those out of the DFZ that we need a multi6 solution". Imagine this WG defines a host agile multi6 solution, which allows a "dentist's office network" to connect to multiple ISP with regular IP connections (no BGP) plus AAA and/or DHCP exchanges. The "scaling component from a administrative point of view involved" is upgrading software on hosts, which is small price to pay for a small site with no networking knowledge (they need to keep OS up-to-date for patches and security bugs anyway). These large numbers of small sites are kept out of the DFZ that helps BGP explosion problem. If you compare basic mechanisms to achieve host agile multihoming and mobility, the difference is null. My point is that if mobility is treated as a component outside multihoming, the "mobile node" attitude is going to bias toward network agile solution, which is more deployable at large site, where network expertise is abundant. Small to medium site would prefer host agile solution because network administration tasks are kept at minimum or don't exist at all. -------------------- Kanchei Loa loa@ieee.org From owner-multi6@ops.ietf.org Wed Mar 10 02:51:36 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24662 for ; Wed, 10 Mar 2004 02:51:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B0yT1-000PVB-HY for multi6-data@psg.com; Wed, 10 Mar 2004 07:49:27 +0000 Received: from [192.71.80.74] (helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B0ySq-000PNc-2T for multi6@ops.ietf.org; Wed, 10 Mar 2004 07:49:16 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id 62C71318596; Wed, 10 Mar 2004 08:49:44 +0100 (CET) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=fixed Message-Id: <78F28E28-7267-11D8-98F5-000A95928574@kurtis.pp.se> Content-Transfer-Encoding: 7bit Cc: , Brian E Carpenter , Eliot Lear From: Kurt Erik Lindqvist Subject: Re: multihoming goals and lear-multi6-things-to-think-about? Date: Wed, 10 Mar 2004 08:49:34 +0100 To: Pekka Savola X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> Agreed. Looking at some of the drafts, I had a strong impression >> that some authors had read the section headings in 3582, but >> not the details, which were thoroughly debated. As Kurtis said, >> let's concentrate on sharpening up the questions in your draft. > > Totally agree here. I guess the good question comes from whether we > expect the user to fully understand nuances of the issues raised in > 3582 or not. > > Two example questions: > > y.y.y Does the mechanism solve traffic engineering issues? > > A significant multihoming benefit today is the ability obtain > traffic-engineering (whether for load sharing, performance, or policy) > benefits. Does your solution solve these problems -- if so, how? Is > this control possible in an "aggregated" fashion, for the whole (or > parts) of the site, or must it be done individually for each host? I actually think that you are asking several questions in one here. Shouldn't this be y.y Aggregation of capabilities A number of mechanisms can be applied 'per host', 'per site' or both. This part lists the mechanisms where this might have an impact on other systems or procedures. y.y.1 Traffic Engineering Traffic engineering can be applied for load-sharing, performance or policy. Can this be handled in an aggregate fashion? If so, how? If not, can it be different per each host? How is it implemented? > x.x.x Manageability of the mechanism at site level? > > How is the site multihoming mechanism managed [RFC3582, 3.2.5]? In > particular, does one have to manage each host individually, or is it > possible to manage the mechanism in an "aggregated" fashion, for the > whole site at a time? > > ... are these important enough to be added? I think these two are the > ones that have been misunderstood the most often -- and adding these > in the "things to think aboug" -document migth help in catching the > folks who didn't think of these issues at enough depth. I think we should add something on the aggregation capabilities for various parts of the solution. These two are a good start, and I am sure there are more. So I think a y.y.2 Manageability would also be good... - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQE7IkqarNKXTPFCVEQI6oACg4n7ilpAnH6u9QIPlGtz0J2OP5vAAnj6h BqMftiEpeqRH1s6Ydttqclks =h2ut -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Wed Mar 10 02:52:11 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24682 for ; Wed, 10 Mar 2004 02:52:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B0yUq-000PwP-Th for multi6-data@psg.com; Wed, 10 Mar 2004 07:51:20 +0000 Received: from [192.71.80.74] (helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B0yUg-000Ppv-8g for multi6@ops.ietf.org; Wed, 10 Mar 2004 07:51:10 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id 8337C3185A7; Wed, 10 Mar 2004 08:51:39 +0100 (CET) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=fixed Message-Id: Content-Transfer-Encoding: 7bit Cc: "Masataka Ohta" , From: Kurt Erik Lindqvist Subject: Re: on the point of mobility & multihoming Date: Wed, 10 Mar 2004 08:51:35 +0100 To: "Kanchei Loa" X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.3 required=5.0 tests=AWL,BAYES_00,UPPERCASE_25_50 autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-03-09, at 18.34, Kanchei Loa wrote: > > I believe we are off-topic here. If you want to discuss what the > 802.11b > coverage is under various configurations, we should take it off-line. yes :-) - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQE7JCqarNKXTPFCVEQL6lACfW8KLKyAtAu6ypnBDBfUnnt7r73QAn0ig jqGEx+QsdaXYOt1H9hl2tRbb =g6ak -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Wed Mar 10 02:56:04 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24781 for ; Wed, 10 Mar 2004 02:56:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B0yYb-0000s3-GZ for multi6-data@psg.com; Wed, 10 Mar 2004 07:55:13 +0000 Received: from [192.71.80.74] (helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B0yYQ-0000pY-Ol for multi6@ops.ietf.org; Wed, 10 Mar 2004 07:55:03 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id 258C13185BF; Wed, 10 Mar 2004 08:55:31 +0100 (CET) In-Reply-To: References: <404D8393.F0C27A2@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=fixed Message-Id: <4B016419-7268-11D8-98F5-000A95928574@kurtis.pp.se> Content-Transfer-Encoding: 7bit Cc: Multi6 List , Brian E Carpenter From: Kurt Erik Lindqvist Subject: Re: on the point of mobility & multihoming Date: Wed, 10 Mar 2004 08:55:26 +0100 To: Iljitsch van Beijnum X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-03-09, at 20.56, Iljitsch van Beijnum wrote: > Obviously there are many details that will differ in practice, but > multiaddressing is multiaddressing regardless of how it's first > approached. However, I'm not sure if adding all the mobility > requirements to our list at this time is helpful, the same way I'm not > convinced rehashing policy and load balancing *now* is helpful. If we > can come up with a synthesis of what's on the table now that is sound > both in architecture and security, there should be ample opportunity > to add the other stuff later. Granted, there is a slight chance we > paint ourselves in a corner with regards to those issues now, but I'm > willing to take that risk for the sake of focussing the discussion so > we can achieve some results. > While I am sure that we at one point will start to see convergence in the requirements for multi6 and mobility, I actually would like to leave mobility our for now. The scope of multi6 is wide enough as it is. Let's look at this problem first. Once we have a better understanding of the impact and of architectural analysis we need to get input from a number of sources. Applications and mobility tends to be highest on my list. I am just afraid that if we start mixing mobility in from the beginning, we will be in way over our heads... - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQE7J8aarNKXTPFCVEQIcfgCgr+BDaSakVoTs7rgg2eEja7uLQSEAnjgl NTsS7aqQVMt0FJ4NVe9TLAEa =ShMP -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Wed Mar 10 03:00:32 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24970 for ; Wed, 10 Mar 2004 03:00:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B0ycZ-00021a-LZ for multi6-data@psg.com; Wed, 10 Mar 2004 07:59:19 +0000 Received: from [192.71.80.74] (helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B0ycP-0001yF-2f for multi6@ops.ietf.org; Wed, 10 Mar 2004 07:59:09 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id 7453D3185E7; Wed, 10 Mar 2004 08:59:38 +0100 (CET) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=fixed Message-Id: Content-Transfer-Encoding: 7bit Cc: "Brian E Carpenter" , , "dhcnotice" From: Kurt Erik Lindqvist Subject: Re: two perspectives on "site" multihoming Date: Wed, 10 Mar 2004 08:59:34 +0100 To: "Kanchei Loa" X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-03-10, at 07.12, Kanchei Loa wrote: > If you compare basic mechanisms to achieve host agile multihoming and > mobility, the difference is null. My point is that if mobility is > treated > as a component outside multihoming, the "mobile node" attitude is > going to > bias toward network agile solution, which is more deployable at large > site, > where network expertise is abundant. Small to medium site would prefer > host > agile solution because network administration tasks are kept at > minimum or > don't exist at all. I am not arguing that we should leave the "mobile aspect" out. I am arguing that we need to take one step at a time. For all I know, we haven't even decided if we are looking for one solution, multiple solutions, a flag-day-solution or a phased approach. Once we are starting to agree on the various architectural aspects and analysis, the threats models and get input from other groups - we can answer those questions, as well as what the relationship between mobility and multihoming is. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQE7K6aarNKXTPFCVEQKsKgCgth+HYlAq53D2BZWQWdlx/T+gLQsAoNFZ CrfzOlSaBLe4lgutxYLdzIDi =Y9x2 -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Wed Mar 10 03:01:58 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25058 for ; Wed, 10 Mar 2004 03:01:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B0yeD-0002VI-Pg for multi6-data@psg.com; Wed, 10 Mar 2004 08:01:01 +0000 Received: from [192.71.80.74] (helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B0ye3-0002Sh-4s for multi6@ops.ietf.org; Wed, 10 Mar 2004 08:00:51 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id 174F63185FC for ; Wed, 10 Mar 2004 09:01:21 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v612) Content-Transfer-Encoding: 7bit Message-Id: <1C982B3E-7269-11D8-98F5-000A95928574@kurtis.pp.se> Content-Type: text/plain; charset=US-ASCII; format=fixed To: Multi6 List From: Kurt Erik Lindqvist Subject: Minutes dead-line Date: Wed, 10 Mar 2004 09:01:18 +0100 X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.4 required=5.0 tests=AWL,BAYES_00,UPPERCASE_25_50 autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Please provide comments on the minutes by next Friday, the 19th. I will then submit the minutes. Best regards, - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQE7LUKarNKXTPFCVEQKPVwCfUghyFGpdx5ijt9zXNMAoeZwlVHAAnjr1 /njDQFbCTnX+nN9MkEBx8RYz =w027 -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Wed Mar 10 03:09:27 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25272 for ; Wed, 10 Mar 2004 03:09:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B0ylR-0004GZ-KT for multi6-data@psg.com; Wed, 10 Mar 2004 08:08:29 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B0ylG-0004DL-O9 for multi6@ops.ietf.org; Wed, 10 Mar 2004 08:08:18 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i2A87GGF074004; Wed, 10 Mar 2004 09:07:16 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <4B016419-7268-11D8-98F5-000A95928574@kurtis.pp.se> References: <404D8393.F0C27A2@zurich.ibm.com> <4B016419-7268-11D8-98F5-000A95928574@kurtis.pp.se> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Multi6 List From: Iljitsch van Beijnum Subject: Re: on the point of mobility & multihoming Date: Wed, 10 Mar 2004 09:06:57 +0100 To: Kurt Erik Lindqvist X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 10-mrt-04, at 8:55, Kurt Erik Lindqvist wrote: > I actually would like to > leave mobility our for now. The scope of multi6 is wide enough as it > is. Let's look at this problem first. > I am just afraid that if we start mixing mobility in from the > beginning, we will be in way over our heads... That was what I was trying to say in the part that you quoted. :-) But that doesn't mean we should continue to ignore mobility forever as there is significant overlap. From owner-multi6@ops.ietf.org Wed Mar 10 05:59:12 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02210 for ; Wed, 10 Mar 2004 05:59:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B11OZ-000A5E-V2 for multi6-data@psg.com; Wed, 10 Mar 2004 10:57:03 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.30; FreeBSD) id 1B11OM-000A35-Qn for multi6@ops.ietf.org; Wed, 10 Mar 2004 10:56:51 +0000 Received: (qmail 82443 invoked from network); 10 Mar 2004 10:58:39 -0000 Received: from yahoobb219178198119.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.178.198.119) by necom830.hpcl.titech.ac.jp with SMTP; 10 Mar 2004 10:58:39 -0000 Message-ID: <404EF503.4020703@necom830.hpcl.titech.ac.jp> Date: Wed, 10 Mar 2004 19:59:15 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Kurt Erik Lindqvist CC: Iljitsch van Beijnum , Multi6 List , Brian E Carpenter Subject: Re: on the point of mobility & multihoming References: <404D8393.F0C27A2@zurich.ibm.com> <4B016419-7268-11D8-98F5-000A95928574@kurtis.pp.se> In-Reply-To: <4B016419-7268-11D8-98F5-000A95928574@kurtis.pp.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Kurt; > I am just afraid that if we start mixing mobility in from the > beginning, we will be in way over our heads... Which is what Geoff did with his rhetorical presentation without understanding the implication of mobility for multihoming, which is partly why Geoff's presentation is useless and to be ignored. Masataka Ohta From owner-multi6@ops.ietf.org Wed Mar 10 09:02:44 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09249 for ; Wed, 10 Mar 2004 09:02:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B14Ff-000P2V-6r for multi6-data@psg.com; Wed, 10 Mar 2004 14:00:03 +0000 Received: from [195.212.29.155] (helo=mtagate6.de.ibm.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B14FQ-000Oxh-3Q for multi6@ops.ietf.org; Wed, 10 Mar 2004 13:59:48 +0000 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by mtagate6.de.ibm.com (8.12.10/8.12.10) with ESMTP id i2ADxfhW047426; Wed, 10 Mar 2004 13:59:41 GMT Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay02.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i2ADxg6W252008; Wed, 10 Mar 2004 14:59:42 +0100 Received: from zurich.ibm.com (gsine06.us.sine.ibm.com [9.14.6.46]) by collon.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with SMTP id OAA60552; Wed, 10 Mar 2004 14:59:37 +0100 Message-ID: <404F1F62.6440A399@zurich.ibm.com> Date: Wed, 10 Mar 2004 15:00:02 +0100 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: Multi6 List CC: Kurt Erik Lindqvist Subject: Re: on the point of mobility & multihoming References: <404D8393.F0C27A2@zurich.ibm.com> <4B016419-7268-11D8-98F5-000A95928574@kurtis.pp.se> <404EF503.4020703@necom830.hpcl.titech.ac.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I would like to make it clear that the co-chairs absolutely disagree with Mr Ohta's comment on Geoff's presentation. We believe it is very useful, although it is only the start of a major effort. Brian Masataka Ohta wrote: > > Kurt; > > > I am just afraid that if we start mixing mobility in from the > > beginning, we will be in way over our heads... > > Which is what Geoff did with his rhetorical presentation > without understanding the implication of mobility for > multihoming, which is partly why Geoff's presentation > is useless and to be ignored. > > Masataka Ohta From owner-multi6@ops.ietf.org Wed Mar 10 11:45:38 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19153 for ; Wed, 10 Mar 2004 11:45:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B16ne-000Mvy-GU for multi6-data@psg.com; Wed, 10 Mar 2004 16:43:18 +0000 Received: from [192.71.80.74] (helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B16nT-000Msi-Rf for multi6@ops.ietf.org; Wed, 10 Mar 2004 16:43:08 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id BDAC5319DB5; Wed, 10 Mar 2004 17:43:37 +0100 (CET) In-Reply-To: <404F1F62.6440A399@zurich.ibm.com> References: <404D8393.F0C27A2@zurich.ibm.com> <4B016419-7268-11D8-98F5-000A95928574@kurtis.pp.se> <404EF503.4020703@necom830.hpcl.titech.ac.jp> <404F1F62.6440A399@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=fixed Message-Id: <11C30257-72B2-11D8-98F5-000A95928574@kurtis.pp.se> Content-Transfer-Encoding: 7bit Cc: Multi6 List From: Kurt Erik Lindqvist Subject: Re: on the point of mobility & multihoming Date: Wed, 10 Mar 2004 17:43:33 +0100 To: Brian E Carpenter X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I want to second Brian. And I think that Ohta-san is putting words in my mouth that I most certainly do not agree with. - - kurtis - On 2004-03-10, at 15.00, Brian E Carpenter wrote: > I would like to make it clear that the co-chairs absolutely > disagree with Mr Ohta's comment on Geoff's presentation. > We believe it is very useful, although it is only the start of a > major effort. > > Brian > > Masataka Ohta wrote: >> >> Kurt; >> >>> I am just afraid that if we start mixing mobility in from the >>> beginning, we will be in way over our heads... >> >> Which is what Geoff did with his rhetorical presentation >> without understanding the implication of mobility for >> multihoming, which is partly why Geoff's presentation >> is useless and to be ignored. >> >> Masataka Ohta -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQE9FuKarNKXTPFCVEQK11wCfRdJ0fA5I+H/3rHG2C5y/xh4ypt0AoPlh 525xFvnJdGjFXmiuiOPa7vn0 =bV8v -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Wed Mar 10 18:15:16 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13121 for ; Wed, 10 Mar 2004 18:15:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B1CsY-0007t9-Md for multi6-data@psg.com; Wed, 10 Mar 2004 23:12:46 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.30; FreeBSD) id 1B1CsN-0007po-Sj for multi6@ops.ietf.org; Wed, 10 Mar 2004 23:12:36 +0000 Received: (qmail 85280 invoked from network); 10 Mar 2004 23:14:34 -0000 Received: from yahoobb219178198119.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.178.198.119) by necom830.hpcl.titech.ac.jp with SMTP; 10 Mar 2004 23:14:34 -0000 Message-ID: <404FA175.9060708@necom830.hpcl.titech.ac.jp> Date: Thu, 11 Mar 2004 08:15:01 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Kurt Erik Lindqvist CC: Brian E Carpenter , Multi6 List Subject: Re: on the point of mobility & multihoming References: <404D8393.F0C27A2@zurich.ibm.com> <4B016419-7268-11D8-98F5-000A95928574@kurtis.pp.se> <404EF503.4020703@necom830.hpcl.titech.ac.jp> <404F1F62.6440A399@zurich.ibm.com> <11C30257-72B2-11D8-98F5-000A95928574@kurtis.pp.se> In-Reply-To: <11C30257-72B2-11D8-98F5-000A95928574@kurtis.pp.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Brian and Kurt; > I want to second Brian. And I think that Ohta-san is putting words in > my mouth that I most certainly do not agree with. >>I would like to make it clear that the co-chairs absolutely >>disagree with Mr Ohta's comment on Geoff's presentation. >>We believe it is very useful, although it is only the start of a >>major effort. As both of you are responsible for choosing Geoff as the presenter and wasted our time, it is not surprising that you don't admit your faults and react even against words in Kurt's own mouth. However, with no technical content, your reactions are no constructive. Just admit the technical fact that Geoff's presentation was technically poor and misdirected, for which both of you are guilty. Masataka Ohta From owner-multi6@ops.ietf.org Thu Mar 11 07:35:06 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29321 for ; Thu, 11 Mar 2004 07:35:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B1PME-000Hmf-Jl for multi6-data@psg.com; Thu, 11 Mar 2004 12:32:14 +0000 Received: from [212.68.5.99] (helo=n97.nomadiclab.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B1PM3-000HjQ-NJ for multi6@ops.ietf.org; Thu, 11 Mar 2004 12:32:03 +0000 Received: from [IPv6:::1] (polle.local.nikander.com [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 5E53D8; Thu, 11 Mar 2004 14:44:42 +0200 (EET) Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <192334F1-7358-11D8-A780-000393CE1E8C@nomadiclab.com> Content-Transfer-Encoding: 7bit Cc: Multi6 List From: Pekka Nikander Subject: To multi6 chairs: Date for interim meeting? Date: Thu, 11 Mar 2004 14:32:02 +0200 To: Kurt Erik Lindqvist , Brian E Carpenter X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Brian and Kurt, During the multi6 meeting in Seoul, there was some talk that there may be a multi6 interim meeting before San Diego. Since I need to co-ordinate my travelling a few months ahead due to a large number of potential conflicts, I would appreciate if you could set a tentative date and place for this interim meeting, if taking place, as soon as possible. --Pekka Nikander From owner-multi6@ops.ietf.org Thu Mar 11 07:55:23 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29985 for ; Thu, 11 Mar 2004 07:55:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B1PhU-000037-6A for multi6-data@psg.com; Thu, 11 Mar 2004 12:54:12 +0000 Received: from [195.212.14.170] (helo=mail-gw2.hursley.ibm.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B1PhJ-000Pz9-6u for multi6@ops.ietf.org; Thu, 11 Mar 2004 12:54:01 +0000 Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw2.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.12) id 1B1PhH-0002ba-00; Thu, 11 Mar 2004 12:53:59 +0000 Received: from [9.20.136.27] (helo=sp15en17.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.12) id 1B1PhH-0002bV-00; Thu, 11 Mar 2004 12:53:59 +0000 Received: from zurich.ibm.com (gsine08.us.sine.ibm.com [9.14.6.48]) by sp15en17.hursley.ibm.com (AIX5.1/8.11.6p2/8.11.0) with SMTP id i2BCrvF122448; Thu, 11 Mar 2004 12:53:57 GMT Message-ID: <40506182.AFAA1FAF@zurich.ibm.com> Date: Thu, 11 Mar 2004 13:54:26 +0100 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: Pekka Nikander CC: Kurt Erik Lindqvist , Multi6 List Subject: Re: To multi6 chairs: Date for interim meeting? References: <192334F1-7358-11D8-A780-000393CE1E8C@nomadiclab.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Pekka, We are trying to find a couple of dates/places to suggest to the WG. But it's hard, and we know that there will be no date that suits everybody. We'll make a proposal ASAP. Brian Pekka Nikander wrote: > > Brian and Kurt, > > During the multi6 meeting in Seoul, there was some talk > that there may be a multi6 interim meeting before San > Diego. Since I need to co-ordinate my travelling a > few months ahead due to a large number of potential > conflicts, I would appreciate if you could set a tentative > date and place for this interim meeting, if taking place, > as soon as possible. > > --Pekka Nikander From owner-multi6@ops.ietf.org Thu Mar 11 11:30:50 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09822 for ; Thu, 11 Mar 2004 11:30:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B1T3A-0001kq-3m for multi6-data@psg.com; Thu, 11 Mar 2004 16:28:48 +0000 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B1T2b-0001Y1-Ld for multi6@ops.ietf.org; Thu, 11 Mar 2004 16:28:13 +0000 Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i2BGS9aD016896; Thu, 11 Mar 2004 08:28:10 -0800 (PST) Received: from cisco.com (sjc-vpn1-596.cisco.com [10.21.98.84]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id IAA12759; Thu, 11 Mar 2004 08:28:09 -0800 (PST) Message-ID: <40509399.7080904@cisco.com> Date: Thu, 11 Mar 2004 08:28:09 -0800 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian E Carpenter CC: Pekka Nikander , Kurt Erik Lindqvist , Multi6 List Subject: Re: To multi6 chairs: Date for interim meeting? References: <192334F1-7358-11D8-A780-000393CE1E8C@nomadiclab.com> <40506182.AFAA1FAF@zurich.ibm.com> In-Reply-To: <40506182.AFAA1FAF@zurich.ibm.com> X-Enigmail-Version: 0.83.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit While Brian and Kurt try and sort out the "wheres and whens", perhaps we should have a discussion of "whats". What do we need to accomplish before the meeting, and what do we need to accomplish at the meeting? We got a pretty good summary of many approaches in Seoul. Maybe the next step should be authors doing a matrix-like comparison of their proposals to the others. It would help greatly if there was some running code, so that people have an idea of implementation complexity. In the next few weeks I'll put out a new version of things to think about. We need someone (Geoff?) to codify Geoff's excellent presentation. Other thoughts? Eliot From owner-multi6@ops.ietf.org Thu Mar 11 12:59:22 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13831 for ; Thu, 11 Mar 2004 12:59:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B1UQl-000B6h-Op for multi6-data@psg.com; Thu, 11 Mar 2004 17:57:15 +0000 Received: from [195.212.14.170] (helo=mail-gw2.hursley.ibm.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B1UQa-000B3s-Ro for multi6@ops.ietf.org; Thu, 11 Mar 2004 17:57:05 +0000 Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw2.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.12) id 1B1UQa-0008NW-00 for multi6@ops.ietf.org; Thu, 11 Mar 2004 17:57:04 +0000 Received: from [9.20.136.27] (helo=sp15en17.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.12) id 1B1UQZ-0008NR-00 for multi6@ops.ietf.org; Thu, 11 Mar 2004 17:57:03 +0000 Received: from zurich.ibm.com (gsine10.us.sine.ibm.com [9.14.6.40]) by sp15en17.hursley.ibm.com (AIX5.1/8.11.6p2/8.11.0) with SMTP id i2BHv2F134678 for ; Thu, 11 Mar 2004 17:57:03 GMT Message-ID: <4050A88A.5E36496C@zurich.ibm.com> Date: Thu, 11 Mar 2004 18:57:30 +0100 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: Multi6 List Subject: Re: To multi6 chairs: Date for interim meeting? References: <192334F1-7358-11D8-A780-000393CE1E8C@nomadiclab.com> <40506182.AFAA1FAF@zurich.ibm.com> <40509399.7080904@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Those are good thoughts. Obviously, we will build up an agenda and goals for the meeting as we get closer. Brian Eliot Lear wrote: > > While Brian and Kurt try and sort out the "wheres and whens", perhaps we > should have a discussion of "whats". What do we need to accomplish > before the meeting, and what do we need to accomplish at the meeting? > > We got a pretty good summary of many approaches in Seoul. Maybe the > next step should be authors doing a matrix-like comparison of their > proposals to the others. It would help greatly if there was some > running code, so that people have an idea of implementation complexity. > > In the next few weeks I'll put out a new version of things to think > about. We need someone (Geoff?) to codify Geoff's excellent presentation. > > Other thoughts? > > Eliot -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM From owner-multi6@ops.ietf.org Thu Mar 11 20:58:02 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10544 for ; Thu, 11 Mar 2004 20:58:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B1buH-000ML4-Ej for multi6-data@psg.com; Fri, 12 Mar 2004 01:56:13 +0000 Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B1bu6-000MGY-Rw for multi6@ops.ietf.org; Fri, 12 Mar 2004 01:56:02 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i2C1trex000534; Thu, 11 Mar 2004 18:55:54 -0700 (MST) Received: from bobo (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i2C1tpQ10721; Fri, 12 Mar 2004 02:55:52 +0100 (MET) Date: Thu, 11 Mar 2004 17:55:57 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Source address selection insufficient? To: Iljitsch van Beijnum Cc: Erik Nordmark , multi6@ops.ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk > > Once you modify the hosts at both ends why not also provide connection > > rehoming? > > Sure. But how does this relate to the problem at hand currently? I'm trying to understand whether we need ingress filtering avoidance (such as the general case of source-based routing) even once we have a connection rehoming solution. One reason we might need that is when only one end of the communication implements multi6. > > (There seems to be a large class of connection rehoming mechanisms > > that can live with source locator rewriting instead of ingress > > filtering, > > but that's the subject of a different email.) > > Unfortunately we still have to deal with the packets that can't be > rewritten and I'm not sure if expecting all routers to be upgraded to > support this is reasonable. I guess the question is about timing and transition. It might be reasonable to expect that over time all routers will be upgraded, but we still need some approach to handle the interim. > > I agree that source based routing and relaxed filtering both work. > > What is tricky is the middle between the small and the large; too small > > a site to be able to convince the ISPs to relax ingress filtering > > and too large a site for source based routing to be trivial. > > For mid-sized sites the "use a default only" policy wouldn't be ideal, > but it should at least make sure there is always a working path. For > small sites the default-only policy has the disadvantage that only one > external link will be used for outgoing traffic, but in a site that has > several routers and subnets, different routers/subnets could use > different external connections so rudimentary load balancing would > still happen. But I suspect the mid-size sites would like to benefit from some level of load balancing across their ISPs. Erik From owner-multi6@ops.ietf.org Thu Mar 11 21:21:51 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11714 for ; Thu, 11 Mar 2004 21:21:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B1cI0-000804-QD for multi6-data@psg.com; Fri, 12 Mar 2004 02:20:44 +0000 Received: from [131.107.3.124] (helo=mail2.microsoft.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B1cHq-0007vd-5O for multi6@ops.ietf.org; Fri, 12 Mar 2004 02:20:34 +0000 Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Thu, 11 Mar 2004 18:20:34 -0800 Received: from 157.54.8.23 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 11 Mar 2004 18:20:33 -0800 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 11 Mar 2004 18:19:32 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 11 Mar 2004 18:20:33 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 11 Mar 2004 18:20:13 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7195.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Source address selection insufficient? Date: Thu, 11 Mar 2004 18:20:30 -0800 Message-ID: Thread-Topic: Source address selection insufficient? thread-index: AcQH1cA73p6Zkp/tSmuQDUeWf53TUwAAbaJg From: "Christian Huitema" To: "Erik Nordmark" , "Iljitsch van Beijnum" Cc: X-OriginalArrivalTime: 12 Mar 2004 02:20:13.0852 (UTC) FILETIME=[8D522DC0:01C407D8] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > > > Once you modify the hosts at both ends why not also provide connection > > > rehoming? > > > > Sure. But how does this relate to the problem at hand currently? >=20 > I'm trying to understand whether we need ingress filtering avoidance > (such as the general case of source-based routing) even once we > have a connection rehoming solution. >=20 > One reason we might need that is when only one end of the communication > implements multi6. This is indeed a scenario that we must support!=20 I personally find that a solution to ingress filtering is the necessary first step to multi-homing. The normal approach to multi-homing is multi-addressing: provide each of the site's hosts with the possibility to configure multiple IPv6 addresses, from each of the providers' prefixes. But in the absence of a proper solution to ingress filtering, a site doing that will experience a loss in service: after multi-homing, some connections will mysteriously fail. This is bad.=20 As an industry, we should consider the multi-homing sites as our best customers: they are buying more services from more providers, deploying more equipment, probably running more software. The minimum we can do is, make sure that someone who buys more does not experience a loss in service! -- Christian Huitema From owner-multi6@ops.ietf.org Fri Mar 12 12:27:49 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04688 for ; Fri, 12 Mar 2004 12:27:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B1qOk-000Dd5-2r for multi6-data@psg.com; Fri, 12 Mar 2004 17:24:38 +0000 Received: from [68.6.19.244] (helo=fed1mtao01.cox.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B1qOZ-000DXg-7Z for multi6@ops.ietf.org; Fri, 12 Mar 2004 17:24:27 +0000 Received: from momo ([68.2.220.20]) by fed1mtao01.cox.net (InterMail vM.5.01.06.08 201-253-122-130-108-20031117) with SMTP id <20040312172427.QIJY24651.fed1mtao01.cox.net@momo>; Fri, 12 Mar 2004 12:24:27 -0500 From: "Kanchei Loa" To: "Christian Huitema" Cc: Subject: ingress filteing problem Date: Fri, 12 Mar 2004 10:24:26 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit indeed, the ingress filtering is a separated problem space from other multi6 solutions. No matter what we choose to implement at the host side, when the IP packet with (src/dst) locators is routed to "wrong" exit router, the ISP will drop the packet because of access control policy. The following are solutions that won't break non-multi6 TCP and UDP (only one end of the communication implements multi6): (1) Match the source address to ISP. (1.1) Create or modify IGP to colored default route with a source address prefix and modify each router to forward packets based on matching default route and source address prefix. (1.2) Create and maintain N**2 tunnels among N exit routers. Modify those routers to exchange source address prefix through the tunnel and forward packets through the tunnel to the "correct" ISP (incoming ISP for the return packet) based on matching source address prefix. (1.3) Create and maintain N VLAN for N ISP. Each host create a virtual interface in order to participates in the VLAN where the source address is acquired. The host sends packets to a VLAN based on matching source address prefix. (1.4) Create and maintain N VPN for N ISP. Each host create a virtual interface in order to participates in the VPN where the source address is acquired. The host sends packets to a VPN based on matching source address prefix. (2) Fake the source address to ISP. (2.1) The site is assigned internal address (site-local address or others); create and maintain N**2 tunnels among N NAT for N ISP. The NATs exchange/share mapping state through the tunnel and forward packets through the tunnel to the "correct" ISP (incoming ISP for the return packet) based on matching mapping state. (2.2) The site is assigned internal address (site-local address or others) and combine NAT with (1.3). The host makes sure that the same virtual interface is used by a address pair (src/dst and dst/src). (2.3) The site is assigned internal address (site-local address or others) and combine NAT with (1.4). The host makes sure that the same virtual interface is used by a address pair (src/dst and dst/src). Before we talk about pros, cons and other issues, It is beneficial that we have a complete list of possible solutions for ISP ingress filtering that won't break non-multi6 TCP and UDP (only one end of the communication implements multi6). My opinion is that any multi6 solution that breaks existing non-multi6 TCP and UDP at another end of the connection will face deployment difficulty. Am I missing something? --------------- Kanchei Loa loa@ieee.org > -----Original Message----- > From: owner-multi6@ops.ietf.org > [mailto:owner-multi6@ops.ietf.org]On Behalf Of Christian Huitema > Sent: Thursday, March 11, 2004 7:21 PM > To: Erik Nordmark; Iljitsch van Beijnum > Cc: multi6@ops.ietf.org > Subject: RE: Source address selection insufficient? > > > > > > Once you modify the hosts at both ends why not also provide > connection > > > > rehoming? > > > > > > Sure. But how does this relate to the problem at hand currently? > > > > I'm trying to understand whether we need ingress filtering avoidance > > (such as the general case of source-based routing) even once we > > have a connection rehoming solution. > > > > One reason we might need that is when only one end of the > communication > > implements multi6. > > This is indeed a scenario that we must support! > > I personally find that a solution to ingress filtering is the necessary > first step to multi-homing. > > The normal approach to multi-homing is multi-addressing: provide each of > the site's hosts with the possibility to configure multiple IPv6 > addresses, from each of the providers' prefixes. But in the absence of a > proper solution to ingress filtering, a site doing that will experience > a loss in service: after multi-homing, some connections will > mysteriously fail. This is bad. > > As an industry, we should consider the multi-homing sites as our best > customers: they are buying more services from more providers, deploying > more equipment, probably running more software. The minimum we can do > is, make sure that someone who buys more does not experience a loss in > service! > > -- Christian Huitema > From owner-multi6@ops.ietf.org Fri Mar 12 12:31:20 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05118 for ; Fri, 12 Mar 2004 12:31:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B1qTn-000G9H-Ma for multi6-data@psg.com; Fri, 12 Mar 2004 17:29:51 +0000 Received: from [68.6.19.241] (helo=fed1mtao04.cox.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B1qTd-000G4g-1O for multi6@ops.ietf.org; Fri, 12 Mar 2004 17:29:41 +0000 Received: from momo ([68.2.220.20]) by fed1mtao04.cox.net (InterMail vM.5.01.06.08 201-253-122-130-108-20031117) with SMTP id <20040312172941.QAQS23486.fed1mtao04.cox.net@momo>; Fri, 12 Mar 2004 12:29:41 -0500 From: "Kanchei Loa" To: "Erik Nordmark" Cc: Subject: RE: Source address selection insufficient? Date: Fri, 12 Mar 2004 10:29:40 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Erik Nordmark wrote: > > > Once you modify the hosts at both ends why not also provide connection > > > rehoming? > > > > Sure. But how does this relate to the problem at hand currently? > > I'm trying to understand whether we need ingress filtering avoidance > (such as the general case of source-based routing) even once we > have a connection rehoming solution. > Could you please clarify "connection rehoming solution" ? ------------ Kanchei Loa loa@ieee.org From owner-multi6@ops.ietf.org Fri Mar 12 13:15:46 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08805 for ; Fri, 12 Mar 2004 13:15:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B1rAG-000DCb-RM for multi6-data@psg.com; Fri, 12 Mar 2004 18:13:44 +0000 Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B1rA6-000D78-9R for multi6@ops.ietf.org; Fri, 12 Mar 2004 18:13:34 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i2CIDUex009811; Fri, 12 Mar 2004 11:13:31 -0700 (MST) Received: from bobo (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i2CIDSQ17290; Fri, 12 Mar 2004 19:13:28 +0100 (MET) Date: Fri, 12 Mar 2004 10:13:34 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: Source address selection insufficient? To: Kanchei Loa Cc: Erik Nordmark , multi6@ops.ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk > Could you please clarify "connection rehoming solution" ? This is the component of a multihoming solution that allows the peers in the communication to switch the locators that are used on the wire without impacting anything above the transport layer. Some of these components, for instance the ones in HIP and NOID, base their security of the rehoming on something strong enough so that they do not need to care which of the multiple locators are used even during the initial setup of the communucation. Hence I think they are capable of always allowing locator rewriting. Does that make things more clear? Erik From owner-multi6@ops.ietf.org Fri Mar 12 21:18:59 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07040 for ; Fri, 12 Mar 2004 21:18:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B1ygx-000GUa-M8 for multi6-data@psg.com; Sat, 13 Mar 2004 02:15:59 +0000 Received: from [204.127.198.35] (helo=rwcrmhc11.comcast.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B1ygf-000GKi-8L for multi6@ops.ietf.org; Sat, 13 Mar 2004 02:15:41 +0000 Received: from dfnjgl21 (c-24-1-97-129.client.comcast.net[24.1.97.129]) by comcast.net (rwcrmhc11) with SMTP id <20040313021540013003b3mte> (Authid: sdawkins@comcast.net); Sat, 13 Mar 2004 02:15:40 +0000 Message-ID: <007501c408a1$1797aeb0$0400a8c0@DFNJGL21> Reply-To: "Spencer Dawkins" From: "Spencer Dawkins" To: References: Subject: Re: ingress filteing problem Date: Fri, 12 Mar 2004 20:15:44 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I'm probably late to the party, but don't (1) and (2) break transport-mode IPsec? So IPsec transport mode would be a non-goal? Just curious, Spencer From: "Kanchei Loa" > The following are solutions that won't break non-multi6 TCP and UDP (only > one end of the communication implements multi6): > > (1) Match the source address to ISP. > > (2) Fake the source address to ISP. > > > Before we talk about pros, cons and other issues, It is beneficial that we > have a complete list of possible solutions for ISP ingress filtering that > won't break non-multi6 TCP and UDP (only one end of the communication > implements multi6). My opinion is that any multi6 solution that breaks > existing non-multi6 TCP and UDP at another end of the connection will face > deployment difficulty. > > Am I missing something? From owner-multi6@ops.ietf.org Sun Mar 14 00:03:47 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18711 for ; Sun, 14 Mar 2004 00:03:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B2NjR-0009vD-Ub for multi6-data@psg.com; Sun, 14 Mar 2004 05:00:13 +0000 Received: from [66.92.66.68] (helo=cyteen.hactrn.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B2NjH-0009rF-9h for multi6@ops.ietf.org; Sun, 14 Mar 2004 05:00:03 +0000 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 8E1305C7 for ; Sun, 14 Mar 2004 00:00:02 -0500 (EST) To: multi6@ops.ietf.org Subject: Weekly posting summary for multi6@ops.ietf.org From: Rob Austein Date: Sun, 14 Mar 2004 00:00:02 -0500 Message-Id: <20040314050002.8E1305C7@cyteen.hactrn.net> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Messages | Bytes | Who --------+------+--------+----------+------------------------ 16.33% | 8 | 26.39% | 49008 | loa@ieee.org 18.37% | 9 | 14.86% | 27595 | kurtis@kurtis.pp.se 12.24% | 6 | 17.99% | 33405 | brc@zurich.ibm.com 14.29% | 7 | 9.75% | 18110 | mohta@necom830.hpcl.titech.ac.jp 8.16% | 4 | 7.17% | 13318 | erik.nordmark@sun.com 8.16% | 4 | 6.50% | 12068 | iljitsch@muada.com 6.12% | 3 | 4.22% | 7840 | pekkas@netcore.fi 4.08% | 2 | 3.59% | 6658 | dhc@dcrocker.net 4.08% | 2 | 3.12% | 5801 | lear@cisco.com 2.04% | 1 | 2.12% | 3940 | huitema@windows.microsoft.com 2.04% | 1 | 1.80% | 3343 | sra@hactrn.net 2.04% | 1 | 1.41% | 2611 | spencer@mcsr-labs.org 2.04% | 1 | 1.07% | 1987 | pekka.nikander@nomadiclab.com --------+------+--------+----------+------------------------ 100.00% | 49 |100.00% | 185684 | Total Grunchweather Associates provides this automatic summary on an at-whim basis at the request of the MULTI6 WG chairs. Your mileage may vary. We decline responsibilities, all shapes, all sizes, all colors. If this script produces broken output, you get to keep both pieces. From owner-multi6@ops.ietf.org Sun Mar 14 02:05:41 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28772 for ; Sun, 14 Mar 2004 02:05:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B2Peb-000Bke-19 for multi6-data@psg.com; Sun, 14 Mar 2004 07:03:21 +0000 Received: from [68.6.19.242] (helo=fed1mtao03.cox.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B2PeI-000BcN-A9 for multi6@ops.ietf.org; Sun, 14 Mar 2004 07:03:02 +0000 Received: from momo ([68.2.220.20]) by fed1mtao03.cox.net (InterMail vM.5.01.06.08 201-253-122-130-108-20031117) with SMTP id <20040314070301.HZQU673.fed1mtao03.cox.net@momo>; Sun, 14 Mar 2004 02:03:01 -0500 From: "Kanchei Loa" To: "Spencer Dawkins" Cc: Subject: RE: ingress filteing problem Date: Sun, 14 Mar 2004 00:02:59 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <007501c408a1$1797aeb0$0400a8c0@DFNJGL21> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Spencer Dawkins wrote: > I'm probably late to the party, but don't (1) and (2) break > transport-mode IPsec? > (1) depicts schemes to forward IP packet to the "correct" ISP such that the source address is matching ISP's ingress filter. There is no IP src/dst rewriting during the process. So, transport-mode IPsec won't be affected. (2) use NAT to rewrite the locators (IP src/dst) in order to pass through ISP's ingress filter and provides consistent src/dst address pair for non-multi6 host at another end of the communication. It is no better (or worse) than existing NAT deployments regarding IPsec compatibility issues. > So IPsec transport mode would be a non-goal? > I can't speak for the WG. But I believe one of the goal is not to introduce new threats. This is quote from "Goals for IPv6 Site-Multihoming Architectures (RFC 3582)". 4. Security Considerations A multihomed site should not be more vulnerable to security breaches than a traditionally IPv4-multihomed site. Any changes to routing practices made to accommodate multihomed sites should not cause non-multihomed sites to become more vulnerable to security breaches. -------------- Kanchei Loa loa@ieee.org From owner-multi6@ops.ietf.org Sun Mar 14 02:17:25 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05433 for ; Sun, 14 Mar 2004 02:17:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B2Pqg-000HMj-C5 for multi6-data@psg.com; Sun, 14 Mar 2004 07:15:50 +0000 Received: from [131.107.3.122] (helo=mail4.microsoft.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B2PqV-000HFI-NY for multi6@ops.ietf.org; Sun, 14 Mar 2004 07:15:39 +0000 Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 13 Mar 2004 23:15:35 -0800 Received: from 157.54.8.109 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sat, 13 Mar 2004 23:15:39 -0800 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 13 Mar 2004 23:15:26 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Sat, 13 Mar 2004 23:15:39 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Sat, 13 Mar 2004 23:15:08 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7195.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: ingress filteing problem Date: Sat, 13 Mar 2004 23:15:36 -0800 Message-ID: Thread-Topic: ingress filteing problem thread-index: AcQJky7tBby7W5jTQxWb72ZTj2pwRAAAJTgg From: "Christian Huitema" To: "Kanchei Loa" , "Spencer Dawkins" Cc: X-OriginalArrivalTime: 14 Mar 2004 07:15:08.0973 (UTC) FILETIME=[1542DDD0:01C40994] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > > I'm probably late to the party, but don't (1) and (2) break > > transport-mode IPsec? > > >=20 > (1) depicts schemes to forward IP packet to the "correct" ISP such that > the > source address is matching ISP's ingress filter. There is no IP src/dst > rewriting during the process. So, transport-mode IPsec won't be affected. >=20 > (2) use NAT to rewrite the locators (IP src/dst) in order to pass through > ISP's ingress filter and provides consistent src/dst address pair for > non-multi6 host at another end of the communication. It is no better (or > worse) than existing NAT deployments regarding IPsec compatibility issues. Of course, this can only work if you use NAT fully, i.e. keep state per connection, rewrite the checksums, provide ALG for the protocols that carry addresses in the payload, accept that the ALG will break if one uses IPSEC in transport mode, etc. There must be another way... -- Christian Huitema From owner-multi6@ops.ietf.org Sun Mar 14 10:25:12 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22468 for ; Sun, 14 Mar 2004 10:25:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B2XRE-000Ig3-9R for multi6-data@psg.com; Sun, 14 Mar 2004 15:22:04 +0000 Received: from [195.212.14.170] (helo=mail-gw2.hursley.ibm.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B2XQz-000IZt-SH for multi6@ops.ietf.org; Sun, 14 Mar 2004 15:21:50 +0000 Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw2.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.12) id 1B2XQy-00006h-00; Sun, 14 Mar 2004 15:21:48 +0000 Received: from [9.20.136.27] (helo=sp15en17.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.12) id 1B2XQy-00006c-00; Sun, 14 Mar 2004 15:21:48 +0000 Received: from zurich.ibm.com (sig-9-145-168-107.de.ibm.com [9.145.168.107]) by sp15en17.hursley.ibm.com (AIX5.1/8.11.6p2/8.11.0) with ESMTP id i2EFLkF58804; Sun, 14 Mar 2004 15:21:46 GMT Message-ID: <40546CA4.8E32274B@zurich.ibm.com> Date: Sun, 14 Mar 2004 15:31:00 +0100 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: Christian Huitema CC: Kanchei Loa , Spencer Dawkins , multi6@ops.ietf.org Subject: Re: ingress filteing problem References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Christian Huitema wrote: > > > > I'm probably late to the party, but don't (1) and (2) break > > > transport-mode IPsec? > > > > > > > (1) depicts schemes to forward IP packet to the "correct" ISP such > that > > the > > source address is matching ISP's ingress filter. There is no IP > src/dst > > rewriting during the process. So, transport-mode IPsec won't be > affected. > > > > (2) use NAT to rewrite the locators (IP src/dst) in order to pass > through > > ISP's ingress filter and provides consistent src/dst address pair for > > non-multi6 host at another end of the communication. It is no better > (or > > worse) than existing NAT deployments regarding IPsec compatibility > issues. > > Of course, this can only work if you use NAT fully, i.e. keep state per > connection, rewrite the checksums, provide ALG for the protocols that > carry addresses in the payload, accept that the ALG will break if one > uses IPSEC in transport mode, etc. There must be another way... > > -- Christian Huitema By "NAT" I trust we mean reversible NAT... this WG is not about to suggest traditional NAT for IPv6, I don't think. Solutions that rewrite the locator(s) and then set them back to their original value before final processing at the destination will not break IPSEC and will not require any transport checksums to be recalculated. Of course, how the source knows which rewrite will be accepted by the relevant ingress filters is a little piece of magic TBD. Brian From owner-multi6@ops.ietf.org Sun Mar 14 13:55:33 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01509 for ; Sun, 14 Mar 2004 13:55:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B2aiu-0007kS-B0 for multi6-data@psg.com; Sun, 14 Mar 2004 18:52:32 +0000 Received: from [131.107.3.122] (helo=mail4.microsoft.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B2aij-0007fd-OE for multi6@ops.ietf.org; Sun, 14 Mar 2004 18:52:21 +0000 Received: from mail6.microsoft.com ([157.54.6.196]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 14 Mar 2004 10:52:12 -0800 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Sun, 14 Mar 2004 10:52:40 -0800 Received: from 157.54.5.25 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 14 Mar 2004 10:52:20 -0800 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 14 Mar 2004 10:50:18 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Sun, 14 Mar 2004 10:52:11 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Sun, 14 Mar 2004 10:51:29 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7195.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: ingress filteing problem Date: Sun, 14 Mar 2004 10:52:15 -0800 Message-ID: Thread-Topic: ingress filteing problem thread-index: AcQJ2CNFHzO+rk4vQm6lJY82Du3jrAAG+V2w From: "Christian Huitema" To: "Brian E Carpenter" Cc: "Kanchei Loa" , "Spencer Dawkins" , X-OriginalArrivalTime: 14 Mar 2004 18:51:29.0953 (UTC) FILETIME=[5CAA7910:01C409F5] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > By "NAT" I trust we mean reversible NAT... this WG is not about to > suggest traditional NAT for IPv6, I don't think. Solutions that rewrite > the locator(s) and then set them back to their original value before > final processing at the destination will not break IPSEC and will not > require any transport checksums to be recalculated. What you describe here is "rewrite at both ends", which supposes that both ends are somehow upgraded. My contention is that the solution to ingress filtering should be "single site", i.e., not force any special processing on the other end, which may well be running a non-updated IPv6 network. Single site solutions allow sites to multi-home at will; multi-site solutions create a zero-day issue. Think of the following case: vanilla IPv6 host A sends a TCP/SYN to address B:X of host B, multi-homed to providers X and Y. Host B sends a SYN-ACK back to A, from source B:X. The internal routing is such that the packet is sent through exit Y, and fails ingress filtering at Y. Clearly, in my example, if A retries a TCP connection using address B:Y, the connection will eventually succeed. However, the trial and error has a cost. And some dumb applications do not even retry all addresses. In this example, B is "punished" because its site is multi-homed. =20 > Of course, how the source knows which rewrite will be accepted by > the relevant ingress filters is a little piece of magic TBD. With the same amount of magic, you probably can devise a single site solution. -- Christian Huitema From owner-multi6@ops.ietf.org Mon Mar 15 05:03:44 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18239 for ; Mon, 15 Mar 2004 05:03:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B2ov8-000JyD-Ob for multi6-data@psg.com; Mon, 15 Mar 2004 10:02:06 +0000 Received: from [163.117.136.121] (helo=smtp01.uc3m.es) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B2ouv-000Jmv-Mz for multi6@ops.ietf.org; Mon, 15 Mar 2004 10:01:53 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id DFF4C139BD; Mon, 15 Mar 2004 11:01:52 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.216]) by smtp01.uc3m.es (Postfix) with SMTP id CA7E51397F; Mon, 15 Mar 2004 11:01:52 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Christian Huitema" , "Brian E Carpenter" Cc: Subject: RE: ingress filteing problem Date: Mon, 15 Mar 2004 10:59:30 +0100 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: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > By "NAT" I trust we mean reversible NAT... this WG is not about to > > suggest traditional NAT for IPv6, I don't think. Solutions that > rewrite > > the locator(s) and then set them back to their original value before > > final processing at the destination will not break IPSEC and will not > > require any transport checksums to be recalculated. > > What you describe here is "rewrite at both ends", which supposes that > both ends are somehow upgraded. My contention is that the solution to > ingress filtering should be "single site", i.e., not force any special > processing on the other end, which may well be running a non-updated > IPv6 network. Yes, additionally, a solutions that supports "old" IPv6 hosts (i.e. without any specific multihoming support) within the multihomed site would be preffered, i guess, since it doesn't impose a flag day in the multihomed site when all the internal hosts have to be upgraded. So backward compatibility on external hosts (and sites) and also in internal hosts Regards, marcelo From owner-multi6@ops.ietf.org Mon Mar 15 05:44:19 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20234 for ; Mon, 15 Mar 2004 05:44:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B2pYk-0006Mj-G6 for multi6-data@psg.com; Mon, 15 Mar 2004 10:43:02 +0000 Received: from [195.212.14.170] (helo=mail-gw2.hursley.ibm.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B2pYX-0006D7-It for multi6@ops.ietf.org; Mon, 15 Mar 2004 10:42:49 +0000 Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw2.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.12) id 1B2pYW-00012b-00; Mon, 15 Mar 2004 10:42:48 +0000 Received: from [9.20.136.27] (helo=sp15en17.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.12) id 1B2pYW-00012W-00; Mon, 15 Mar 2004 10:42:48 +0000 Received: from zurich.ibm.com (sig-9-145-174-48.de.ibm.com [9.145.174.48]) by sp15en17.hursley.ibm.com (AIX5.1/8.11.6p2/8.11.0) with ESMTP id i2FAgmF124196; Mon, 15 Mar 2004 10:42:48 GMT Message-ID: <405588C5.3D06FA27@zurich.ibm.com> Date: Mon, 15 Mar 2004 11:43:17 +0100 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: mbagnulo@ing.uc3m.es CC: Christian Huitema , multi6@ops.ietf.org Subject: Re: ingress filteing problem References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit marcelo bagnulo wrote: > > > > By "NAT" I trust we mean reversible NAT... this WG is not about to > > > suggest traditional NAT for IPv6, I don't think. Solutions that > > rewrite > > > the locator(s) and then set them back to their original value before > > > final processing at the destination will not break IPSEC and will not > > > require any transport checksums to be recalculated. > > > > What you describe here is "rewrite at both ends", which supposes that > > both ends are somehow upgraded. My contention is that the solution to > > ingress filtering should be "single site", i.e., not force any special > > processing on the other end, which may well be running a non-updated > > IPv6 network. > > Yes, additionally, a solutions that supports "old" IPv6 hosts (i.e. without > any specific multihoming support) within the multihomed site would be > preffered, i guess, since it doesn't impose a flag day in the multihomed > site when all the internal hosts have to be upgraded. > > So backward compatibility on external hosts (and sites) and also in internal > hosts Of course I agree that the solution should not make things *worse* than today for non-multihoming-aware sites. But the ingress filtering problem that Christian describes surely exists today on such sites, which have no mechanism for choosing the appropriate exit router. Brian From owner-multi6@ops.ietf.org Mon Mar 15 11:47:46 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09378 for ; Mon, 15 Mar 2004 11:47:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B2vE9-000FIr-Et for multi6-data@psg.com; Mon, 15 Mar 2004 16:46:09 +0000 Received: from [131.107.3.123] (helo=mail3.microsoft.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B2vDy-000FH6-Qu for multi6@ops.ietf.org; Mon, 15 Mar 2004 16:45:58 +0000 Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 15 Mar 2004 08:46:00 -0800 Received: from 157.54.8.155 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 15 Mar 2004 08:46:04 -0800 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 15 Mar 2004 08:46:06 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 15 Mar 2004 08:46:05 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Mon, 15 Mar 2004 08:45:48 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7195.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: ingress filteing problem Date: Mon, 15 Mar 2004 08:45:55 -0800 Message-ID: Thread-Topic: ingress filteing problem thread-index: AcQKek4TjM3P9+OnRUK8hZm0fi2FegAMkVdQ From: "Christian Huitema" To: "Brian E Carpenter" , Cc: X-OriginalArrivalTime: 15 Mar 2004 16:45:48.0422 (UTC) FILETIME=[F7F9EA60:01C40AAC] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > > > What you describe here is "rewrite at both ends", which supposes that > > > both ends are somehow upgraded. My contention is that the solution to > > > ingress filtering should be "single site", i.e., not force any special > > > processing on the other end, which may well be running a non-updated > > > IPv6 network. > > > > Yes, additionally, a solutions that supports "old" IPv6 hosts (i.e. > without > > any specific multihoming support) within the multihomed site would be > > preffered, i guess, since it doesn't impose a flag day in the multihomed > > site when all the internal hosts have to be upgraded. > > > > So backward compatibility on external hosts (and sites) and also in > internal > > hosts >=20 > Of course I agree that the solution should not make things *worse* > than today for non-multihoming-aware sites. But the ingress filtering > problem that Christian describes surely exists today on such sites, > which have no mechanism for choosing the appropriate exit router. The current solution, in IPv4, is to allocate a single prefix to the site and to have this prefix announced in BGP by all providers. The solution does meet ingress filtering requirements, and does not impose any constraint to internal hosts or external peers. We can indeed replicate that for IPv6, but I was under the impression that we would rather do without routing table explosion. -- Christian Huitema From owner-multi6@ops.ietf.org Mon Mar 15 12:05:01 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10226 for ; Mon, 15 Mar 2004 12:05:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B2vVx-000M8W-Lf for multi6-data@psg.com; Mon, 15 Mar 2004 17:04:33 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B2vVe-000M2L-55 for multi6@ops.ietf.org; Mon, 15 Mar 2004 17:04:14 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i2FH4Qoq080161 for ; Mon, 15 Mar 2004 18:04:27 +0100 (CET) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v612) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: Multi6 List From: Iljitsch van Beijnum Subject: how to proceed Date: Mon, 15 Mar 2004 18:04:12 +0100 X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit We are once again discussing all kinds of details, which is of course very useful, but I want to take a few moments to look at the big picture, and the relationship between the smaller issues that make up said big picture. This should give us some guidance about how to proceed, as some issues are fundamental and must be resolved in order to arrive at a workable solution, while others (hopefully most) can be pushed back and resolved later as optional mechanisms. All of this is assuming a multiaddress solution. 1. Basic operation and negotiation I think we're beginning to get a pretty good handle on this part. We reached the conclusion that actual identifier/locator separation isn't needed here. There are some details to be worked out, such as when the negotiation happens: always at the beginning, after sessions have been established or both/any. 2. Security association setup As we're not chartered to build a world wide PKI, we must make our mechanisms as secure as possible in the absense of strong authentication. There are some proposals for this (not necessarily in this wg). However, we don't really know yet what we want to do if there IS strong authentication present at some other layer (IPsec, TLS), which should be common enough to make it useful to reuse. 3. Have identifiers anyway Identifiers aren't required, but that doesn't mean they aren't desired. It seems there are at least some people within the IETF who would like to see a real locator/identifier separation. Are we prepared to add identifiers to the mix? And if so, in what way? There are proposals for disjoint identifier/locator spaces, but also for "hiding" identifiers inside locators. The cryptographic nature of some identifiers may be useful in securing negotiations. Do we want to allow identifiers that don't look like IPv6 addresses? 4. Reference Ephemeral locators aren't very suitable for referential purposes. Do we need to make this issue part of the multi6 solution or is it better to create a new protocol for this that is orthogonal to our other efforts? 5. Ingress filtering (and address selection) Need I say more? 6. Address rewriting by routers This can be useful, but what is the right way to handle this? It seems unlikely that this capability will be universally available anytime soon, if ever. On the other hand it would be a shame to have to use complex mechanisms to get around ingress filtering when the rewriting capability is available. 7. Traffic engineering and policy (and address selection) Current proposals are lacking with regard to traffic engineering. We could reuse DNS SRV records for this. There are few provisions for policy enforcement in current proposals, except in NAROS which hasn't been heard from in a while. 8. Failover Still too much handwaving. 9. Interfaces to other layers It is likely higher layers will want to influence certain aspects of multihoming operation. Interfaces between layers and APIs are needed for this. That's it for now. I suggest that we keep this list up to date (feel free to add stuff) and go over it to see how we want to handle the issues at some point. From owner-multi6@ops.ietf.org Tue Mar 16 03:11:44 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17111 for ; Tue, 16 Mar 2004 03:11:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B39dN-00070q-Ai for multi6-data@psg.com; Tue, 16 Mar 2004 08:09:09 +0000 Received: from [195.212.14.170] (helo=mail-gw2.hursley.ibm.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B39dB-000704-My for multi6@ops.ietf.org; Tue, 16 Mar 2004 08:08:57 +0000 Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw2.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.12) id 1B39dA-0002lW-00 for multi6@ops.ietf.org; Tue, 16 Mar 2004 08:08:56 +0000 Received: from [9.20.136.27] (helo=sp15en17.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.12) id 1B39dA-0002lR-00 for multi6@ops.ietf.org; Tue, 16 Mar 2004 08:08:56 +0000 Received: from zurich.ibm.com (sig-9-145-169-66.de.ibm.com [9.145.169.66]) by sp15en17.hursley.ibm.com (AIX5.1/8.11.6p2/8.11.0) with ESMTP id i2G88uF131430 for ; Tue, 16 Mar 2004 08:08:57 GMT Message-ID: <4056B634.1CF64135@zurich.ibm.com> Date: Tue, 16 Mar 2004 09:09:24 +0100 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: Multi6 Subject: Proposed dates and place for multi6 interim meeting Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Folks, We have a proposal for the dates and place for the multi6 interim meeting. This takes into account the travel plans and availability of the co-chairs, the AD, and the two document authors that we absolutely need at the meeting, Eliot Lear and Geoff Huston. The proposal is to co-locate the meeting with ISOC's INET conference in Barcelona, Spain, on Monday May 10 and Tuesday May 11 (exact timing and exact location still TBD). See http://www.isoc.org/inet04/ for the conference itself. We couldn't find any other time and place that works. We'd like a first indication of how many people will be able to participate, before proceeding with the logistics and formalities. A response this week would be very helpful. Please don't cc the list; simply reply to Brian + Kurtis co-chairs From owner-multi6@ops.ietf.org Tue Mar 16 03:30:21 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17789 for ; Tue, 16 Mar 2004 03:30:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B39xT-0009kV-M5 for multi6-data@psg.com; Tue, 16 Mar 2004 08:29:55 +0000 Received: from [195.212.14.170] (helo=mail-gw2.hursley.ibm.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B39x2-0009e4-PM for multi6@ops.ietf.org; Tue, 16 Mar 2004 08:29:28 +0000 Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw2.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.12) id 1B39x2-0003i5-00; Tue, 16 Mar 2004 08:29:28 +0000 Received: from [9.20.136.27] (helo=sp15en17.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.12) id 1B39x1-0003i0-00; Tue, 16 Mar 2004 08:29:27 +0000 Received: from zurich.ibm.com (sig-9-145-169-66.de.ibm.com [9.145.169.66]) by sp15en17.hursley.ibm.com (AIX5.1/8.11.6p2/8.11.0) with ESMTP id i2G8TSF71758; Tue, 16 Mar 2004 08:29:28 GMT Message-ID: <4056BB04.3073BBC8@zurich.ibm.com> Date: Tue, 16 Mar 2004 09:29:56 +0100 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: Iljitsch van Beijnum CC: Multi6 List Subject: Re: how to proceed References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch, We are expecting an architectural draft from Geoff as follow up to his presentation in Seoul, and that should be our record of the big issues. You have provided input for Geoff... thanks. Brian Iljitsch van Beijnum wrote: > > We are once again discussing all kinds of details, which is of course > very useful, but I want to take a few moments to look at the big > picture, and the relationship between the smaller issues that make up > said big picture. This should give us some guidance about how to > proceed, as some issues are fundamental and must be resolved in order > to arrive at a workable solution, while others (hopefully most) can be > pushed back and resolved later as optional mechanisms. > > All of this is assuming a multiaddress solution. > > 1. Basic operation and negotiation > > I think we're beginning to get a pretty good handle on this part. We > reached the conclusion that actual identifier/locator separation isn't > needed here. There are some details to be worked out, such as when the > negotiation happens: always at the beginning, after sessions have been > established or both/any. > > 2. Security association setup > > As we're not chartered to build a world wide PKI, we must make our > mechanisms as secure as possible in the absense of strong > authentication. There are some proposals for this (not necessarily in > this wg). However, we don't really know yet what we want to do if there > IS strong authentication present at some other layer (IPsec, TLS), > which should be common enough to make it useful to reuse. > > 3. Have identifiers anyway > > Identifiers aren't required, but that doesn't mean they aren't desired. > It seems there are at least some people within the IETF who would like > to see a real locator/identifier separation. Are we prepared to add > identifiers to the mix? And if so, in what way? There are proposals for > disjoint identifier/locator spaces, but also for "hiding" identifiers > inside locators. The cryptographic nature of some identifiers may be > useful in securing negotiations. Do we want to allow identifiers that > don't look like IPv6 addresses? > > 4. Reference > > Ephemeral locators aren't very suitable for referential purposes. Do we > need to make this issue part of the multi6 solution or is it better to > create a new protocol for this that is orthogonal to our other efforts? > > 5. Ingress filtering (and address selection) > > Need I say more? > > 6. Address rewriting by routers > > This can be useful, but what is the right way to handle this? It seems > unlikely that this capability will be universally available anytime > soon, if ever. On the other hand it would be a shame to have to use > complex mechanisms to get around ingress filtering when the rewriting > capability is available. > > 7. Traffic engineering and policy (and address selection) > > Current proposals are lacking with regard to traffic engineering. We > could reuse DNS SRV records for this. There are few provisions for > policy enforcement in current proposals, except in NAROS which hasn't > been heard from in a while. > > 8. Failover > > Still too much handwaving. > > 9. Interfaces to other layers > > It is likely higher layers will want to influence certain aspects of > multihoming operation. Interfaces between layers and APIs are needed > for this. > > That's it for now. I suggest that we keep this list up to date (feel > free to add stuff) and go over it to see how we want to handle the > issues at some point. From owner-multi6@ops.ietf.org Tue Mar 16 03:32:56 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17905 for ; Tue, 16 Mar 2004 03:32:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3A0A-000AOL-Ed for multi6-data@psg.com; Tue, 16 Mar 2004 08:32:42 +0000 Received: from [195.212.14.170] (helo=mail-gw2.hursley.ibm.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B39zD-000A8D-Fj for multi6@ops.ietf.org; Tue, 16 Mar 2004 08:31:43 +0000 Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw2.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.12) id 1B39zC-0003qy-00; Tue, 16 Mar 2004 08:31:42 +0000 Received: from [9.20.136.27] (helo=sp15en17.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.12) id 1B39zC-0003qt-00; Tue, 16 Mar 2004 08:31:42 +0000 Received: from zurich.ibm.com (sig-9-145-169-66.de.ibm.com [9.145.169.66]) by sp15en17.hursley.ibm.com (AIX5.1/8.11.6p2/8.11.0) with ESMTP id i2G8VgF122456; Tue, 16 Mar 2004 08:31:43 GMT Message-ID: <4056BB8B.527D676E@zurich.ibm.com> Date: Tue, 16 Mar 2004 09:32:11 +0100 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: Christian Huitema CC: mbagnulo@ing.uc3m.es, multi6@ops.ietf.org Subject: Re: ingress filteing problem References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Christian Huitema wrote: > > > > > What you describe here is "rewrite at both ends", which supposes > that > > > > both ends are somehow upgraded. My contention is that the solution > to > > > > ingress filtering should be "single site", i.e., not force any > special > > > > processing on the other end, which may well be running a > non-updated > > > > IPv6 network. > > > > > > Yes, additionally, a solutions that supports "old" IPv6 hosts (i.e. > > without > > > any specific multihoming support) within the multihomed site would > be > > > preffered, i guess, since it doesn't impose a flag day in the > multihomed > > > site when all the internal hosts have to be upgraded. > > > > > > So backward compatibility on external hosts (and sites) and also in > > internal > > > hosts > > > > Of course I agree that the solution should not make things *worse* > > than today for non-multihoming-aware sites. But the ingress filtering > > problem that Christian describes surely exists today on such sites, > > which have no mechanism for choosing the appropriate exit router. > > The current solution, in IPv4, is to allocate a single prefix to the > site and to have this prefix announced in BGP by all providers. The > solution does meet ingress filtering requirements, and does not impose > any constraint to internal hosts or external peers. We can indeed > replicate that for IPv6, but I was under the impression that we would > rather do without routing table explosion. Indeed. What I was saying (badly) is that today, an IPv6 site which has two prefixes and two ISPs has exactly this problem, even without any multihoming mechanism defined. Brian From owner-multi6@ops.ietf.org Tue Mar 16 04:33:40 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20110 for ; Tue, 16 Mar 2004 04:33:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3Avu-000JwI-4b for multi6-data@psg.com; Tue, 16 Mar 2004 09:32:22 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3Avj-000JvH-3f for multi6@ops.ietf.org; Tue, 16 Mar 2004 09:32:11 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i2G9WNoq093441; Tue, 16 Mar 2004 10:32:23 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <4056B634.1CF64135@zurich.ibm.com> References: <4056B634.1CF64135@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Multi6 From: Iljitsch van Beijnum Subject: Re: Proposed dates and place for multi6 interim meeting Date: Tue, 16 Mar 2004 10:32:09 +0100 To: Brian E Carpenter X-Mailer: Apple Mail (2.613) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 16-mrt-04, at 9:09, Brian E Carpenter wrote: > We'd like a first indication of how many people will be able > to participate, before proceeding with the logistics and > formalities. A response this week would be very helpful. Can you tell us a bit more about the purpose of the meeting, this will help in determining whether it's worth the time and expense to go. Iljitsch From owner-multi6@ops.ietf.org Tue Mar 16 05:28:51 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22505 for ; Tue, 16 Mar 2004 05:28:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3BnW-000283-D5 for multi6-data@psg.com; Tue, 16 Mar 2004 10:27:46 +0000 Received: from [195.212.14.170] (helo=mail-gw2.hursley.ibm.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3BnL-000261-LM for multi6@ops.ietf.org; Tue, 16 Mar 2004 10:27:35 +0000 Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw2.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.12) id 1B3BnL-0002Qd-00; Tue, 16 Mar 2004 10:27:35 +0000 Received: from [9.20.136.27] (helo=sp15en17.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.12) id 1B3BnK-0002QY-00; Tue, 16 Mar 2004 10:27:34 +0000 Received: from zurich.ibm.com (sig-9-145-139-218.de.ibm.com [9.145.139.218]) by sp15en17.hursley.ibm.com (AIX5.1/8.11.6p2/8.11.0) with ESMTP id i2GARYF89466; Tue, 16 Mar 2004 10:27:34 GMT Message-ID: <4056D6B1.338B8604@zurich.ibm.com> Date: Tue, 16 Mar 2004 11:28:01 +0100 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: Iljitsch van Beijnum CC: Multi6 Subject: Re: Proposed dates and place for multi6 interim meeting References: <4056B634.1CF64135@zurich.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch van Beijnum wrote: > > On 16-mrt-04, at 9:09, Brian E Carpenter wrote: > > > We'd like a first indication of how many people will be able > > to participate, before proceeding with the logistics and > > formalities. A response this week would be very helpful. > > Can you tell us a bit more about the purpose of the meeting, this will > help in determining whether it's worth the time and expense to go. We don't have a draft agenda, but I think the main goal is to make progress on the architectural analysis. It is *not* to choose a solution or to discuss solution proposals, except as far as they help the analysis. Brian From owner-multi6@ops.ietf.org Tue Mar 16 05:45:32 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22978 for ; Tue, 16 Mar 2004 05:45:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3C3U-0004vc-Be for multi6-data@psg.com; Tue, 16 Mar 2004 10:44:16 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3C3J-0004uX-LE for multi6@ops.ietf.org; Tue, 16 Mar 2004 10:44:05 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i2GAiIoq094424; Tue, 16 Mar 2004 11:44:18 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <4056D6B1.338B8604@zurich.ibm.com> References: <4056B634.1CF64135@zurich.ibm.com> <4056D6B1.338B8604@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Multi6 From: Iljitsch van Beijnum Subject: Re: Proposed dates and place for multi6 interim meeting Date: Tue, 16 Mar 2004 11:44:04 +0100 To: Brian E Carpenter X-Mailer: Apple Mail (2.613) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 16-mrt-04, at 11:28, Brian E Carpenter wrote: > We don't have a draft agenda, but I think the main goal is to make > progress > on the architectural analysis. It is *not* to choose a solution or to > discuss solution proposals, except as far as they help the analysis. Well, so far there has been little to no architectural analysis, except for Geoff's presentation in Seoul. Now there was nothing wrong with that, but you can do only so much analyzing in 20 minutes. Also, I don't think analysis in itself is or should be a goal, it should be a means to making progress. In this regard it would help if we pose ourselves some questions we want to have answered, and use the architectural analysis to find the answers. BTW, what kind of timeslot are we talking about? From owner-multi6@ops.ietf.org Tue Mar 16 05:52:30 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23336 for ; Tue, 16 Mar 2004 05:52:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3CBB-0006Dl-OD for multi6-data@psg.com; Tue, 16 Mar 2004 10:52:13 +0000 Received: from [195.212.14.170] (helo=mail-gw2.hursley.ibm.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3CB1-0006D5-1t for multi6@ops.ietf.org; Tue, 16 Mar 2004 10:52:03 +0000 Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw2.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.12) id 1B3CB0-0003RA-00; Tue, 16 Mar 2004 10:52:02 +0000 Received: from [9.20.136.27] (helo=sp15en17.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.12) id 1B3CB0-0003R5-00; Tue, 16 Mar 2004 10:52:02 +0000 Received: from zurich.ibm.com (sig-9-145-139-218.de.ibm.com [9.145.139.218]) by sp15en17.hursley.ibm.com (AIX5.1/8.11.6p2/8.11.0) with ESMTP id i2GAq1F120780; Tue, 16 Mar 2004 10:52:01 GMT Message-ID: <4056DC6C.9860C748@zurich.ibm.com> Date: Tue, 16 Mar 2004 11:52:28 +0100 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: Iljitsch van Beijnum CC: Multi6 Subject: Re: Proposed dates and place for multi6 interim meeting References: <4056B634.1CF64135@zurich.ibm.com> <4056D6B1.338B8604@zurich.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch van Beijnum wrote: > > On 16-mrt-04, at 11:28, Brian E Carpenter wrote: > > > We don't have a draft agenda, but I think the main goal is to make > > progress > > on the architectural analysis. It is *not* to choose a solution or to > > discuss solution proposals, except as far as they help the analysis. > > Well, so far there has been little to no architectural analysis, except > for Geoff's presentation in Seoul. Now there was nothing wrong with > that, but you can do only so much analyzing in 20 minutes. Exactly why we need to devote more time to it. > Also, I don't think analysis in itself is or should be a goal, it > should be a means to making progress. In this regard it would help if > we pose ourselves some questions we want to have answered, and use the > architectural analysis to find the answers. Send text :-) > BTW, what kind of timeslot are we talking about? 1.5 days? An overnight break in such a meeting can be very valuable, so that ideas can be sorted out and firmed up. Brian From owner-multi6@ops.ietf.org Tue Mar 16 12:11:25 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11506 for ; Tue, 16 Mar 2004 12:11:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3I3c-000AVn-B7 for multi6-data@psg.com; Tue, 16 Mar 2004 17:08:48 +0000 Received: from [131.107.3.124] (helo=mail2.microsoft.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3I3R-000AV1-QI for multi6@ops.ietf.org; Tue, 16 Mar 2004 17:08:37 +0000 Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Tue, 16 Mar 2004 09:08:28 -0800 Received: from 157.54.8.23 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 16 Mar 2004 09:08:26 -0800 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 16 Mar 2004 09:08:35 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 16 Mar 2004 09:08:43 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 16 Mar 2004 09:07:21 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7195.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: ingress filteing problem Date: Tue, 16 Mar 2004 09:08:32 -0800 Message-ID: Thread-Topic: ingress filteing problem thread-index: AcQLMRGHdqtYCX31REiscs+128XgMAAR8Ykg From: "Christian Huitema" To: "Brian E Carpenter" Cc: , X-OriginalArrivalTime: 16 Mar 2004 17:07:21.0726 (UTC) FILETIME=[254231E0:01C40B79] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > > > Of course I agree that the solution should not make things *worse* > > > than today for non-multihoming-aware sites. But the ingress filtering > > > problem that Christian describes surely exists today on such sites, > > > which have no mechanism for choosing the appropriate exit router. > > > > The current solution, in IPv4, is to allocate a single prefix to the > > site and to have this prefix announced in BGP by all providers. The > > solution does meet ingress filtering requirements, and does not impose > > any constraint to internal hosts or external peers. We can indeed > > replicate that for IPv6, but I was under the impression that we would > > rather do without routing table explosion. >=20 > Indeed. What I was saying (badly) is that today, an IPv6 site which > has two prefixes and two ISPs has exactly this problem, even without > any multihoming mechanism defined. Agreed. For this reason, I believe that there are two tasks ahead of us. The first one is to solve ingress-filtering for the "IPv6 site which has two prefixes and two ISPs", and possibly three or four; the goal here is to make sure that new connections "just work". The second task is to define additional support mechanisms for multi-homing; the emphasis will be on "taking advantage of multi-homing" so things work "better", e.g., ensure that connections survive a re-homing event. -- Christian Huitema From owner-multi6@ops.ietf.org Wed Mar 17 12:11:56 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22591 for ; Wed, 17 Mar 2004 12:11:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3eXx-000Eui-2P for multi6-data@psg.com; Wed, 17 Mar 2004 17:09:37 +0000 Received: from [192.18.42.14] (helo=nwkea-mail-2.sun.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3eXm-000Esr-Fx for multi6@ops.ietf.org; Wed, 17 Mar 2004 17:09:26 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i2HH9Lng002659; Wed, 17 Mar 2004 09:09:22 -0800 (PST) Received: from bobo (bobo.SFBay.Sun.COM [129.146.89.81]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i2HH9JQ07904; Wed, 17 Mar 2004 18:09:19 +0100 (MET) Date: Wed, 17 Mar 2004 09:09:21 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: ingress filteing problem To: Christian Huitema Cc: Brian E Carpenter , mbagnulo@ing.uc3m.es, multi6@ops.ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk > Agreed. For this reason, I believe that there are two tasks ahead of us. > The first one is to solve ingress-filtering for the "IPv6 site which > has two prefixes and two ISPs", and possibly three or four; the goal > here is to make sure that new connections "just work". The second task > is to define additional support mechanisms for multi-homing; the > emphasis will be on "taking advantage of multi-homing" so things work > "better", e.g., ensure that connections survive a re-homing event. Agreed. Perhaps we should add something to think-about and the architectural analysis of that appears to be focused on the second task, to ask what impact different approaches to that task might have on different approaches to the first task. For instance, some approaches to the second task might need a solution to ingress filtering. This prersumably means we want a good, long-term solution for ingress filtering etc. Other approaches to the second task might instead use locator rewriting which probably means we don't need to heavily optimize the ingress filtering solution. Erik From owner-multi6@ops.ietf.org Thu Mar 18 23:57:35 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00457 for ; Thu, 18 Mar 2004 23:57:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B4C2M-000Gdi-Lb for multi6-data@psg.com; Fri, 19 Mar 2004 04:55:14 +0000 Received: from [131.228.20.27] (helo=mgw-x4.nokia.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B4C1v-000GJ1-J1 for multi6@ops.ietf.org; Fri, 19 Mar 2004 04:54:47 +0000 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2J4sh416596; Fri, 19 Mar 2004 06:54:43 +0200 (EET) X-Scanned: Fri, 19 Mar 2004 06:54:28 +0200 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i2J4sS65007766; Fri, 19 Mar 2004 06:54:28 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00gzcoP9; Fri, 19 Mar 2004 06:54:27 EET Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2J4sRF03858; Fri, 19 Mar 2004 06:54:27 +0200 (EET) Received: from dadhcp-172019068136.americas.nokia.com ([172.19.68.140]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 18 Mar 2004 20:54:25 -0800 Received: from dadhcp-172019068136.americas.nokia.com (localhost.localdomain [127.0.0.1]) by dadhcp-172019068136.americas.nokia.com (8.12.8/8.12.8) with ESMTP id i2J4sPdG014062; Thu, 18 Mar 2004 20:54:25 -0800 Received: (from kessens@localhost) by dadhcp-172019068136.americas.nokia.com (8.12.8/8.12.8/Submit) id i2J4sP7B014060; Thu, 18 Mar 2004 20:54:25 -0800 Date: Thu, 18 Mar 2004 20:54:25 -0800 From: David Kessens To: Masataka Ohta Cc: Multi6 List Subject: Re: on the point of mobility & multihoming Message-ID: <20040319045425.GA13955@nokia.com> References: <404D8393.F0C27A2@zurich.ibm.com> <4B016419-7268-11D8-98F5-000A95928574@kurtis.pp.se> <404EF503.4020703@necom830.hpcl.titech.ac.jp> <404FA175.9060708@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <404FA175.9060708@necom830.hpcl.titech.ac.jp> User-Agent: Mutt/1.4.1i X-OriginalArrivalTime: 19 Mar 2004 04:54:26.0100 (UTC) FILETIME=[40FB6F40:01C40D6E] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Ohta-san, On Thu, Mar 11, 2004 at 08:15:01AM +0900, Masataka Ohta wrote: > > As both of you are responsible for choosing Geoff as the > presenter and wasted our time, it is not surprising that you > don't admit your faults and react even against words in Kurt's > own mouth. > > However, with no technical content, your reactions are > no constructive. > > Just admit the technical fact that Geoff's presentation was > technically poor and misdirected, for which both of you > are guilty. The multi6 working group is trying to tackle a very hard problem. The differences between the proposals are huge. Despite all this, we have had very good discussions without any personal attacks except for yours. Due to the diversity of opinions, it is inevitable that there are occasional disagreements. It's ok to disagree. It is not ok to verbally assault the person that you disagree with. It is not necessary to repeat your opinion over and over again in a very aggressive manner while it is clear that there is no significant support for your opinion. Your attacks on the chairpeople, Geoff and many other contributors to this working group are inappropriate and should stop. I think that the whole working group and the chairpeople are doing a great job. We know that you have interesting ideas, please help the group by contributing to the working group in a civil manner so that the working group can focus on the problems that need to be solved. Thanks, David Kessens --- From owner-multi6@ops.ietf.org Sun Mar 21 00:12:35 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11721 for ; Sun, 21 Mar 2004 00:12:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B4v48-0003ZN-9N for multi6-data@psg.com; Sun, 21 Mar 2004 05:00:04 +0000 Received: from [66.92.66.68] (helo=cyteen.hactrn.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B4v47-0003Z7-Dr for multi6@ops.ietf.org; Sun, 21 Mar 2004 05:00:03 +0000 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 685173A6 for ; Sun, 21 Mar 2004 00:00:02 -0500 (EST) To: multi6@ops.ietf.org Subject: Weekly posting summary for multi6@ops.ietf.org From: Rob Austein Date: Sun, 21 Mar 2004 00:00:02 -0500 Message-Id: <20040321050002.685173A6@cyteen.hactrn.net> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Messages | Bytes | Who --------+------+--------+----------+------------------------ 36.84% | 7 | 37.60% | 25003 | brc@zurich.ibm.com 21.05% | 4 | 23.88% | 15883 | huitema@windows.microsoft.com 15.79% | 3 | 14.06% | 9353 | iljitsch@muada.com 5.26% | 1 | 6.86% | 4565 | david@iprg.nokia.com 5.26% | 1 | 4.55% | 3028 | mbagnulo@ing.uc3m.es 5.26% | 1 | 4.53% | 3010 | erik.nordmark@sun.com 5.26% | 1 | 4.50% | 2993 | loa@ieee.org 5.26% | 1 | 4.01% | 2669 | sra@hactrn.net --------+------+--------+----------+------------------------ 100.00% | 19 |100.00% | 66504 | Total Grunchweather Associates provides this automatic summary on an at-whim basis at the request of the MULTI6 WG chairs. Your mileage may vary. We decline responsibilities, all shapes, all sizes, all colors. If this script produces broken output, you get to keep both pieces. From owner-multi6@ops.ietf.org Tue Mar 23 10:25:30 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03021 for ; Tue, 23 Mar 2004 10:25:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B5nk0-000ISt-KM for multi6-data@psg.com; Tue, 23 Mar 2004 15:22:56 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B5njn-000IP8-Al for multi6@ops.ietf.org; Tue, 23 Mar 2004 15:22:43 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i2NFMpI0031001 for ; Tue, 23 Mar 2004 16:22:51 +0100 (CET) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v613) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: Multi6 List From: Iljitsch van Beijnum Subject: Identifiers Date: Tue, 23 Mar 2004 16:22:38 +0100 X-Mailer: Apple Mail (2.613) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Looking at the proposed solutions, it seems that we have been gravitating towards locator agility without explicit identifiers. While that's certainly a valid approach, I think we should take a few moments to consider identifier issues. The main reason to forego having identifiers is that it is hard to determine if a correspondent is rightfully using an identifier. However, this is not the case for two classes of potential identifiers: 1. Identifiers with a cryptographic nature, such as the ones proposed for HIP. Since the identifier is a hash of a public key, proving ownership is trivial given a few round trips and CPU cycles. 2. FQDNs with a certificate that leads back to a trusted authority. These are in relative wide use today for SSL. It stands to reason that future developments will lead to new types of verifyable identifiers. I think this invalidates the assumption that verifying the authenticity of identifiers is too hard a priori. Rather, the question should be whether we are willing to accept the necessary complexity to allow extensible identifier authentication in our multi6 solution of choice. In this regard, it should be interesting to see what the MOBIKE people are up to. Personally, I think the best choice would be to remain agnostic about the identifier issue for now, but build our negotiation protocol such that they can be added easily later. For now, we build a "no identifier" type solution. Solving the problem of how a correspondent proves ownership of an identifier can then be deferred until such time that someone actually wants to extend the multi6 solution to support identifiers. So the only thing we have to do now is make sure the protocols are flexible enough to allow such extensions. Thoughts? From owner-multi6@ops.ietf.org Tue Mar 23 10:48:36 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04726 for ; Tue, 23 Mar 2004 10:48:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B5o7x-000O7U-72 for multi6-data@psg.com; Tue, 23 Mar 2004 15:47:41 +0000 Received: from [163.117.136.121] (helo=smtp01.uc3m.es) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B5o7D-000Nxx-Oq for multi6@ops.ietf.org; Tue, 23 Mar 2004 15:46:55 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id C2B651C438; Tue, 23 Mar 2004 16:46:54 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.216]) by smtp01.uc3m.es (Postfix) with SMTP id AD0B61C428; Tue, 23 Mar 2004 16:46:54 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Iljitsch van Beijnum" , "Multi6 List" Subject: RE: Identifiers Date: Tue, 23 Mar 2004 16:44:19 +0100 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: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Iljitsch, [...] > Personally, I think the best choice would be to remain agnostic about > the identifier issue for now, but build our negotiation protocol such > that they can be added easily later. For now, we build a "no > identifier" type solution. Solving the problem of how a correspondent > proves ownership of an identifier can then be deferred until such time > that someone actually wants to extend the multi6 solution to support > identifiers. So the only thing we have to do now is make sure the > protocols are flexible enough to allow such extensions. > > Thoughts? I am sorry, but i fail to understand what would be usage for such protocol. I mean, until you provide the security features, we cannot deploy the protocol, since it would be unsafe to adopt it, so what's the point on having it defined? Moreover, if you try to define a protocol that is general enough to support all the different authentication mechanisms, i guess it will be more complex that a protocol that actually relies on a defined mechanism. I agree that the issues right now w.r.t. preserving established communications is about choosing a security mechanism, so IMHO if we want to provide a solution for this problem we will have to make our mind and decide something on how to do this. I guess that the architectural analysis is conceived to provide the required background to make such choice. But, perhaps i misunderstood your proposal? Regards, marcelo > > From owner-multi6@ops.ietf.org Tue Mar 23 11:02:36 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06110 for ; Tue, 23 Mar 2004 11:02:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B5oM1-0002QK-2a for multi6-data@psg.com; Tue, 23 Mar 2004 16:02:13 +0000 Received: from [195.212.14.170] (helo=mail-gw2.hursley.ibm.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B5oLm-0002LO-4c for multi6@ops.ietf.org; Tue, 23 Mar 2004 16:01:58 +0000 Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw2.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.12) id 1B5oLj-0002ax-00; Tue, 23 Mar 2004 16:01:55 +0000 Received: from [9.20.136.27] (helo=sp15en17.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.12) id 1B5oLj-0002as-00; Tue, 23 Mar 2004 16:01:55 +0000 Received: from zurich.ibm.com (sig-9-145-240-165.de.ibm.com [9.145.240.165]) by sp15en17.hursley.ibm.com (AIX5.1/8.11.6p2/8.11.0) with ESMTP id i2NG1qF107714; Tue, 23 Mar 2004 16:01:54 GMT Message-ID: <40605F8A.93A388AA@zurich.ibm.com> Date: Tue, 23 Mar 2004 17:02:19 +0100 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: Iljitsch van Beijnum CC: Multi6 List Subject: Re: Identifiers References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch, Good input. We might think in terms of a Level 1 architecture in which the ULP still fondly believes that an IP address is a good identifier, and a Level 2 architecture where something that can be authenticated is used (and the ULP needs to be profoundly modified). Brian Iljitsch van Beijnum wrote: > > Looking at the proposed solutions, it seems that we have been > gravitating towards locator agility without explicit identifiers. While > that's certainly a valid approach, I think we should take a few moments > to consider identifier issues. > > The main reason to forego having identifiers is that it is hard to > determine if a correspondent is rightfully using an identifier. > However, this is not the case for two classes of potential identifiers: > > 1. Identifiers with a cryptographic nature, such as the ones proposed > for HIP. Since the identifier is a hash of a public key, proving > ownership is trivial given a few round trips and CPU cycles. > > 2. FQDNs with a certificate that leads back to a trusted authority. > These are in relative wide use today for SSL. > > It stands to reason that future developments will lead to new types of > verifyable identifiers. I think this invalidates the assumption that > verifying the authenticity of identifiers is too hard a priori. Rather, > the question should be whether we are willing to accept the necessary > complexity to allow extensible identifier authentication in our multi6 > solution of choice. In this regard, it should be interesting to see > what the MOBIKE people are up to. > > Personally, I think the best choice would be to remain agnostic about > the identifier issue for now, but build our negotiation protocol such > that they can be added easily later. For now, we build a "no > identifier" type solution. Solving the problem of how a correspondent > proves ownership of an identifier can then be deferred until such time > that someone actually wants to extend the multi6 solution to support > identifiers. So the only thing we have to do now is make sure the > protocols are flexible enough to allow such extensions. > > Thoughts? -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM From owner-multi6@ops.ietf.org Tue Mar 23 11:23:05 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07692 for ; Tue, 23 Mar 2004 11:23:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B5ofu-000701-Jh for multi6-data@psg.com; Tue, 23 Mar 2004 16:22:46 +0000 Received: from [163.117.136.121] (helo=smtp01.uc3m.es) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B5ofn-0006yt-1n for multi6@ops.ietf.org; Tue, 23 Mar 2004 16:22:39 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 1B9261BA7B; Tue, 23 Mar 2004 17:22:38 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.216]) by smtp01.uc3m.es (Postfix) with SMTP id 05CD6197A9; Tue, 23 Mar 2004 17:22:38 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Brian E Carpenter" , "Iljitsch van Beijnum" Cc: "Multi6 List" Subject: RE: Identifiers Date: Tue, 23 Mar 2004 17:20:02 +0100 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: <40605F8A.93A388AA@zurich.ibm.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Brian, [...] > > Good input. We might think in terms of a Level 1 architecture in which > the ULP still fondly believes that an IP address is a good identifier, By address, do you mean any 128 bit long string or a routable IPv6 address? I guess that ULP protocol can work fine with any identifier whose representation can fit into 128 bits. Regards, marcelo > and a Level 2 architecture where something that can be authenticated > is used (and the ULP needs to be profoundly modified). > > Brian > > Iljitsch van Beijnum wrote: > > > > Looking at the proposed solutions, it seems that we have been > > gravitating towards locator agility without explicit identifiers. While > > that's certainly a valid approach, I think we should take a few moments > > to consider identifier issues. > > > > The main reason to forego having identifiers is that it is hard to > > determine if a correspondent is rightfully using an identifier. > > However, this is not the case for two classes of potential identifiers: > > > > 1. Identifiers with a cryptographic nature, such as the ones proposed > > for HIP. Since the identifier is a hash of a public key, proving > > ownership is trivial given a few round trips and CPU cycles. > > > > 2. FQDNs with a certificate that leads back to a trusted authority. > > These are in relative wide use today for SSL. > > > > It stands to reason that future developments will lead to new types of > > verifyable identifiers. I think this invalidates the assumption that > > verifying the authenticity of identifiers is too hard a priori. Rather, > > the question should be whether we are willing to accept the necessary > > complexity to allow extensible identifier authentication in our multi6 > > solution of choice. In this regard, it should be interesting to see > > what the MOBIKE people are up to. > > > > Personally, I think the best choice would be to remain agnostic about > > the identifier issue for now, but build our negotiation protocol such > > that they can be added easily later. For now, we build a "no > > identifier" type solution. Solving the problem of how a correspondent > > proves ownership of an identifier can then be deferred until such time > > that someone actually wants to extend the multi6 solution to support > > identifiers. So the only thing we have to do now is make sure the > > protocols are flexible enough to allow such extensions. > > > > Thoughts? > > -- > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > Brian E Carpenter > Distinguished Engineer, Internet Standards & Technology, IBM > From owner-multi6@ops.ietf.org Tue Mar 23 11:27:14 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07959 for ; Tue, 23 Mar 2004 11:27:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B5oje-0007s0-Lm for multi6-data@psg.com; Tue, 23 Mar 2004 16:26:38 +0000 Received: from [195.212.14.170] (helo=mail-gw2.hursley.ibm.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B5ojS-0007qX-HL for multi6@ops.ietf.org; Tue, 23 Mar 2004 16:26:27 +0000 Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw2.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.12) id 1B5ojQ-0003zZ-00; Tue, 23 Mar 2004 16:26:24 +0000 Received: from [9.20.136.27] (helo=sp15en17.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.12) id 1B5ojQ-0003zU-00; Tue, 23 Mar 2004 16:26:24 +0000 Received: from zurich.ibm.com (sig-9-145-240-165.de.ibm.com [9.145.240.165]) by sp15en17.hursley.ibm.com (AIX5.1/8.11.6p2/8.11.0) with ESMTP id i2NGQNF129470; Tue, 23 Mar 2004 16:26:23 GMT Message-ID: <40606549.617B2C84@zurich.ibm.com> Date: Tue, 23 Mar 2004 17:26:49 +0100 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: mbagnulo@ing.uc3m.es CC: Iljitsch van Beijnum , Multi6 List Subject: Re: Identifiers References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit marcelo bagnulo wrote: > > Hi Brian, > > [...] > > > > Good input. We might think in terms of a Level 1 architecture in which > > the ULP still fondly believes that an IP address is a good identifier, > > By address, do you mean any 128 bit long string or a routable IPv6 address? > I guess that ULP protocol can work fine with any identifier whose > representation can fit into 128 bits. Exactly. That is all a ULP knows - a binary string shaped like an IPv6 address. It has no knowledge of the locator-like properties. Brian > > Regards, marcelo > > > and a Level 2 architecture where something that can be authenticated > > is used (and the ULP needs to be profoundly modified). > > > > Brian > > > > Iljitsch van Beijnum wrote: > > > > > > Looking at the proposed solutions, it seems that we have been > > > gravitating towards locator agility without explicit identifiers. While > > > that's certainly a valid approach, I think we should take a few moments > > > to consider identifier issues. > > > > > > The main reason to forego having identifiers is that it is hard to > > > determine if a correspondent is rightfully using an identifier. > > > However, this is not the case for two classes of potential identifiers: > > > > > > 1. Identifiers with a cryptographic nature, such as the ones proposed > > > for HIP. Since the identifier is a hash of a public key, proving > > > ownership is trivial given a few round trips and CPU cycles. > > > > > > 2. FQDNs with a certificate that leads back to a trusted authority. > > > These are in relative wide use today for SSL. > > > > > > It stands to reason that future developments will lead to new types of > > > verifyable identifiers. I think this invalidates the assumption that > > > verifying the authenticity of identifiers is too hard a priori. Rather, > > > the question should be whether we are willing to accept the necessary > > > complexity to allow extensible identifier authentication in our multi6 > > > solution of choice. In this regard, it should be interesting to see > > > what the MOBIKE people are up to. > > > > > > Personally, I think the best choice would be to remain agnostic about > > > the identifier issue for now, but build our negotiation protocol such > > > that they can be added easily later. For now, we build a "no > > > identifier" type solution. Solving the problem of how a correspondent > > > proves ownership of an identifier can then be deferred until such time > > > that someone actually wants to extend the multi6 solution to support > > > identifiers. So the only thing we have to do now is make sure the > > > protocols are flexible enough to allow such extensions. > > > > > > Thoughts? > > > > -- > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > Brian E Carpenter > > Distinguished Engineer, Internet Standards & Technology, IBM > > -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM From owner-multi6@ops.ietf.org Tue Mar 23 11:59:46 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10849 for ; Tue, 23 Mar 2004 11:59:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B5pEh-000Ffe-6h for multi6-data@psg.com; Tue, 23 Mar 2004 16:58:43 +0000 Received: from [68.6.19.124] (helo=fed1mtao07.cox.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B5pEc-000Fet-7q for multi6@ops.ietf.org; Tue, 23 Mar 2004 16:58:38 +0000 Received: from momo ([68.2.220.20]) by fed1mtao07.cox.net (InterMail vM.5.01.06.08 201-253-122-130-108-20031117) with SMTP id <20040323165836.QBWO4381.fed1mtao07.cox.net@momo>; Tue, 23 Mar 2004 11:58:36 -0500 From: "Kanchei Loa" To: "Iljitsch van Beijnum" Cc: "Multi6 List" Subject: RE: Identifiers Date: Tue, 23 Mar 2004 09:58:31 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Iljitsch, I personally prefer solutions with identifier or identifier extension as you described. But I thought this WG is still at architecture analysis phase, which is agnostic to all proposals. --------- Kanchei Loa loa@ieee.org > -----Original Message----- > From: owner-multi6@ops.ietf.org > [mailto:owner-multi6@ops.ietf.org]On Behalf Of Iljitsch van Beijnum > Sent: Tuesday, March 23, 2004 8:23 AM > To: Multi6 List > Subject: Identifiers > > > Looking at the proposed solutions, it seems that we have been > gravitating towards locator agility without explicit identifiers. While > that's certainly a valid approach, I think we should take a few moments > to consider identifier issues. > > The main reason to forego having identifiers is that it is hard to > determine if a correspondent is rightfully using an identifier. > However, this is not the case for two classes of potential identifiers: > > 1. Identifiers with a cryptographic nature, such as the ones proposed > for HIP. Since the identifier is a hash of a public key, proving > ownership is trivial given a few round trips and CPU cycles. > > 2. FQDNs with a certificate that leads back to a trusted authority. > These are in relative wide use today for SSL. > > It stands to reason that future developments will lead to new types of > verifyable identifiers. I think this invalidates the assumption that > verifying the authenticity of identifiers is too hard a priori. Rather, > the question should be whether we are willing to accept the necessary > complexity to allow extensible identifier authentication in our multi6 > solution of choice. In this regard, it should be interesting to see > what the MOBIKE people are up to. > > Personally, I think the best choice would be to remain agnostic about > the identifier issue for now, but build our negotiation protocol such > that they can be added easily later. For now, we build a "no > identifier" type solution. Solving the problem of how a correspondent > proves ownership of an identifier can then be deferred until such time > that someone actually wants to extend the multi6 solution to support > identifiers. So the only thing we have to do now is make sure the > protocols are flexible enough to allow such extensions. > > Thoughts? > > From owner-multi6@ops.ietf.org Tue Mar 23 12:18:29 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13158 for ; Tue, 23 Mar 2004 12:18:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B5pXH-000KEi-L5 for multi6-data@psg.com; Tue, 23 Mar 2004 17:17:55 +0000 Received: from [192.44.77.17] (helo=laposte.rennes.enst-bretagne.fr) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B5pXB-000KD4-Rz for multi6@ops.ietf.org; Tue, 23 Mar 2004 17:17:50 +0000 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i2NHHZm09333; Tue, 23 Mar 2004 18:17:35 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i2NHHZSj041614; Tue, 23 Mar 2004 18:17:35 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200403231717.i2NHHZSj041614@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Iljitsch van Beijnum cc: Multi6 List Subject: Re: Identifiers In-reply-to: Your message of Tue, 23 Mar 2004 16:22:38 +0100. Date: Tue, 23 Mar 2004 18:17:35 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk In your previous mail you wrote: The main reason to forego having identifiers is that it is hard to determine if a correspondent is rightfully using an identifier. => can I translate this statement into a generic "authorization" issue. However, this is not the case for two classes of potential identifiers: 1. Identifiers with a cryptographic nature, such as the ones proposed for HIP. Since the identifier is a hash of a public key, proving ownership is trivial given a few round trips and CPU cycles. => note that ownership is not authentication. 2. FQDNs with a certificate that leads back to a trusted authority. These are in relative wide use today for SSL. => this implies some kind of PKI but provides strong authentication. We can get both: in HIP "anonymous identifiers" are 1 and other identifiers are 1+2, at most one identifier (the initiator's one) can be anonymous. It stands to reason that future developments will lead to new types of verifyable identifiers. I think this invalidates the assumption that verifying the authenticity of identifiers is too hard a priori. Rather, the question should be whether we are willing to accept the necessary complexity to allow extensible identifier authentication in our multi6 solution of choice. In this regard, it should be interesting to see what the MOBIKE people are up to. => IPsec/IKE requires strong authentication (i.e., 2) by default. IMHO it can be lowered to what HIP requires, i.e., at least 1 for the initiator and at least 2 for the responder in some contexts. Personally, I think the best choice would be to remain agnostic about the identifier issue for now, but build our negotiation protocol such that they can be added easily later. For now, we build a "no identifier" type solution. Solving the problem of how a correspondent proves ownership of an identifier can then be deferred until such time that someone actually wants to extend the multi6 solution to support identifiers. So the only thing we have to do now is make sure the protocols are flexible enough to allow such extensions. Thoughts? => I disagree because the security, in this case a proper handling of the authorization issue, must be included in the design from the beginning. Regards Francis.Dupont@enst-bretagne.fr From owner-multi6@ops.ietf.org Tue Mar 23 12:18:37 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13185 for ; Tue, 23 Mar 2004 12:18:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B5pXU-000KH8-Mm for multi6-data@psg.com; Tue, 23 Mar 2004 17:18:08 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B5pX8-000KCf-MQ for multi6@ops.ietf.org; Tue, 23 Mar 2004 17:17:46 +0000 Received: from [IPv6:::1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i2NHHmI0032558; Tue, 23 Mar 2004 18:17:51 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: "Multi6 List" From: Iljitsch van Beijnum Subject: Re: Identifiers Date: Tue, 23 Mar 2004 18:17:36 +0100 To: X-Mailer: Apple Mail (2.613) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 23-mrt-04, at 16:44, marcelo bagnulo wrote: >> Thoughts? > I am sorry, but i fail to understand what would be usage for such > protocol. > I mean, until you provide the security features, we cannot deploy the > protocol, since it would be unsafe to adopt it, so what's the point on > having it defined? Well a winter coat isn't much use in the summer but things change. :-) > Moreover, if you try to define a protocol that is general enough to > support > all the different authentication mechanisms, i guess it will be more > complex > that a protocol that actually relies on a defined mechanism. > I agree that the issues right now w.r.t. preserving established > communications is about choosing a security mechanism, so IMHO if we > want to > provide a solution for this problem we will have to make our mind and > decide > something on how to do this. I agree, in order to build something that's usable we need to select one way of doing this, and standardize and implement this way of doing it. And a good way to do this would be taking working sessions and negotiate alternative addresses for them, without the use of an explicit identifier. However... > But, perhaps i misunderstood your proposal? What I'm saying is that even though it may not make sense to have full blown identifiers _today_, it's probably a good idea to recognize that we'll want to have them in the future, and make sure the actual multihoming protocol we're going to build now can be easily adapted to support identifiers. This means that there must be unused or option fields in the messages that can be used to extend the protocol in a backward compatible way. Another important issue is that when identifiers are used, all negotiation must precede the actual communication, so we should build our protocol that it allows this if at all possible. From owner-multi6@ops.ietf.org Tue Mar 23 12:44:08 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14457 for ; Tue, 23 Mar 2004 12:44:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B5pvu-0000go-KU for multi6-data@psg.com; Tue, 23 Mar 2004 17:43:22 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B5pvY-0000bz-Cn for multi6@ops.ietf.org; Tue, 23 Mar 2004 17:43:00 +0000 Received: from [IPv6:::1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i2NHgmI0032915; Tue, 23 Mar 2004 18:42:52 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <78FF9E31-7CF1-11D8-97C7-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: "Multi6 List" From: Iljitsch van Beijnum Subject: Re: Identifiers Date: Tue, 23 Mar 2004 18:42:36 +0100 To: "Kanchei Loa" X-Mailer: Apple Mail (2.613) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 23-mrt-04, at 17:58, Kanchei Loa wrote: > I personally prefer solutions with identifier or identifier extension > as > you described. But I thought this > WG is still at architecture analysis phase, which is agnostic to all > proposals. I was hoping to kickstart some architectural discussion with my original message in order to be able to leave this agnostic phase behind us at some point. :-) Iljitsch From owner-multi6@ops.ietf.org Tue Mar 23 18:30:42 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11849 for ; Tue, 23 Mar 2004 18:30:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B5vKa-0002OX-HR for multi6-data@psg.com; Tue, 23 Mar 2004 23:29:12 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B5vKZ-0002Nz-6t for multi6@ops.ietf.org; Tue, 23 Mar 2004 23:29:11 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i2NNT1I0037647; Wed, 24 Mar 2004 00:29:02 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <200403231717.i2NHHZSj041614@givry.rennes.enst-bretagne.fr> References: <200403231717.i2NHHZSj041614@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Multi6 List From: Iljitsch van Beijnum Subject: Re: Identifiers Date: Wed, 24 Mar 2004 00:28:51 +0100 To: Francis Dupont X-Mailer: Apple Mail (2.613) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 23-mrt-04, at 18:17, Francis Dupont wrote: > The main reason to forego having identifiers is that it is hard to > determine if a correspondent is rightfully using an identifier. > => can I translate this statement into a generic "authorization" issue. > => note that ownership is not authentication. Hm, I was working on the assumption that we only need authentication, as the owner/holder of an identifier or a locator can do with it what he or she pleases. Would it be useful to add an authorization step to this process? I.e., despite the fact that I know you are indeed the legitimate holder of your identifier, I may still refuse to interact with you because you haven't been authorized to use the identifier for this particular purpose. But then the question becomes: who grants authorization? > 2. FQDNs with a certificate that leads back to a trusted authority. > These are in relative wide use today for SSL. > => this implies some kind of PKI Yes. My point is that there is something that can be called a PKI for SSL. > We can get both: in HIP "anonymous identifiers" are 1 and other > identifiers are 1+2, at most one identifier (the initiator's one) > can be anonymous. Indeed. The initiator doesn't even have to use an identifier. > Personally, I think the best choice would be to remain agnostic > about > the identifier issue for now, but build our negotiation protocol > such > that they can be added easily later. For now, we build a "no > identifier" type solution. Solving the problem of how a > correspondent > proves ownership of an identifier can then be deferred until such > time > that someone actually wants to extend the multi6 solution to support > identifiers. So the only thing we have to do now is make sure the > protocols are flexible enough to allow such extensions. > => I disagree because the security, in this case a proper handling of > the authorization issue, must be included in the design from the > beginning. Good point, building something first and then trying to plug the holes doesn't work very well. However, what is "the beginning" here? There are two claims that we want to check when a correspondent claims that it is reachable at additional addresses: the "who" part and the "reachable" part. (We don't want someone else to claim that their addresses belong to our correspondent, but we also don't want our correspondent to claim that someone else's addresses are theirs.) The the "reachable" part is universal: once we create a protocol, this part shouldn't change. However, the "who" part depends on the nature of the identifiers. Without actual identifiers we only check whether we're talking to the same entity, regardless of who this entity is. But with cryptographic identifiers, we can actually check whether someone who claims to be the holder of the identifier has the secret key. With a PKI the procedure is different, with DNSSEC different again. Now what I'm saying is that we should build a "no identifiers" type solution *now* but recognize that we may want to have identifiers later. At some point, the protocol is extended to make it possible to use a certain type of identifiers. Since this is the beginning of the use of these identifiers, this is also the beginning of or security efforts with regards to using these identifiers. In other words, it makes no sense to include X.509 handling _now_ if we are building an identifier-less solution. However, there are some things we can do to make it easier to support X.509 certificates in the future. For instance, use length fields that are more than 8 bits. In practice there may not be a huge difference between building a general purpose system that supports just option X at this time and a special purpose system that only supports option X, but philosophically there is a world of difference. "When the only tool you have is a hammer, every problem looks like a nail." So taking the hammer first and then consider the problem limits our view of the solution space. Considering the problem, then determining that we can solve most of it with a hammer and deciding that we can only afford a toolbox with a hammer in it at this time is very different. From owner-multi6@ops.ietf.org Wed Mar 24 04:33:29 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08809 for ; Wed, 24 Mar 2004 04:33:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B64ja-00055Z-F8 for multi6-data@psg.com; Wed, 24 Mar 2004 09:31:38 +0000 Received: from [192.44.77.17] (helo=laposte.rennes.enst-bretagne.fr) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B64jY-00054o-E4 for multi6@ops.ietf.org; Wed, 24 Mar 2004 09:31:36 +0000 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i2O9VSS19736; Wed, 24 Mar 2004 10:31:28 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i2O9VOSj044764; Wed, 24 Mar 2004 10:31:28 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200403240931.i2O9VOSj044764@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Iljitsch van Beijnum cc: Multi6 List Subject: Re: Identifiers In-reply-to: Your message of Wed, 24 Mar 2004 00:28:51 +0100. Date: Wed, 24 Mar 2004 10:31:24 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk In your previous mail you wrote: > The main reason to forego having identifiers is that it is hard to > determine if a correspondent is rightfully using an identifier. > => can I translate this statement into a generic "authorization" issue. > => note that ownership is not authentication. Hm, I was working on the assumption that we only need authentication, as the owner/holder of an identifier or a locator can do with it what he or she pleases. => obviously we don't share the meaning of the word "authentication" here. Would it be useful to add an authorization step to this process? => yes, and the authorization is the real thing! I.e., despite the fact that I know you are indeed the legitimate holder of your identifier, I may still refuse to interact with you because you haven't been authorized to use the identifier for this particular purpose. => this question is another form of "authentication doesn't imply authorization". But then the question becomes: who grants authorization? => some kind of trust system including local policy, PKIs, ... > 2. FQDNs with a certificate that leads back to a trusted authority. > These are in relative wide use today for SSL. > => this implies some kind of PKI Yes. My point is that there is something that can be called a PKI for SSL. => the current SSL/TLS heavily uses X.509 PKIs. > We can get both: in HIP "anonymous identifiers" are 1 and other > identifiers are 1+2, at most one identifier (the initiator's one) > can be anonymous. Indeed. The initiator doesn't even have to use an identifier. => I disagree: without an identifier remote redirection is insecure. An "anonymous identifier" is an identifier because it has ownership, it is anonymous because it can't be bound to a name. > => I disagree because the security, in this case a proper handling of > the authorization issue, must be included in the design from the > beginning. Good point, building something first and then trying to plug the holes doesn't work very well. However, what is "the beginning" here? => IMHO any kind of proposal which can be implemented (things which can't be implemented can be a waste of time but should not endanger security :-). There are two claims that we want to check when a correspondent claims that it is reachable at additional addresses: the "who" part and the "reachable" part. (We don't want someone else to claim that their addresses belong to our correspondent, but we also don't want our correspondent to claim that someone else's addresses are theirs.) The the "reachable" part is universal: once we create a protocol, this part shouldn't change. However, the "who" part depends on the nature of the identifiers. Without actual identifiers we only check whether we're talking to the same entity, regardless of who this entity is. But with cryptographic identifiers, we can actually check whether someone who claims to be the holder of the identifier has the secret key. With a PKI the procedure is different, with DNSSEC different again. => DNSSEC can be used as a PKI, i.e., some PKIs are not based on X.509. Now what I'm saying is that we should build a "no identifiers" type solution *now* but recognize that we may want to have identifiers later. => perhaps you mean we need only ownership and not strong authentication? In anycase we need identifiers, the question should be about the needed properties of these identifiers. At some point, the protocol is extended to make it possible to use a certain type of identifiers. Since this is the beginning of the use of these identifiers, this is also the beginning of or security efforts with regards to using these identifiers. In other words, it makes no sense to include X.509 handling _now_ if we are building an identifier-less solution. => do I catch your idea? However, there are some things we can do to make it easier to support X.509 certificates in the future. => when I disagree with the "no global PKI" of some people at the IETF, I agree that a global X.509 PKI is not possible and even not desirable. For instance, use length fields that are more than 8 bits. In practice there may not be a huge difference between building a general purpose system that supports just option X at this time and a special purpose system that only supports option X, but philosophically there is a world of difference. "When the only tool you have is a hammer, every problem looks like a nail." So taking the hammer first and then consider the problem limits our view of the solution space. Considering the problem, then determining that we can solve most of it with a hammer and deciding that we can only afford a toolbox with a hammer in it at this time is very different. Thanks Francis.Dupont@enst-bretagne.fr From owner-multi6@ops.ietf.org Wed Mar 24 05:24:10 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11427 for ; Wed, 24 Mar 2004 05:24:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B65XM-000IyE-Ml for multi6-data@psg.com; Wed, 24 Mar 2004 10:23:04 +0000 Received: from [195.212.14.170] (helo=mail-gw2.hursley.ibm.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B65XF-000IwB-9T for multi6@ops.ietf.org; Wed, 24 Mar 2004 10:22:58 +0000 Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw2.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.12) id 1B65XC-00071Y-00; Wed, 24 Mar 2004 10:22:54 +0000 Received: from [9.20.136.27] (helo=sp15en17.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.12) id 1B65XC-00071T-00; Wed, 24 Mar 2004 10:22:54 +0000 Received: from zurich.ibm.com (sig-9-145-137-204.de.ibm.com [9.145.137.204]) by sp15en17.hursley.ibm.com (AIX5.1/8.11.6p2/8.11.0) with ESMTP id i2OAMfF136470; Wed, 24 Mar 2004 10:22:41 GMT Message-ID: <4061618A.14A2F4E6@zurich.ibm.com> Date: Wed, 24 Mar 2004 11:23:06 +0100 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: Iljitsch van Beijnum CC: Francis Dupont , Multi6 List Subject: Re: Identifiers References: <200403231717.i2NHHZSj041614@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Our problem is not ownership. It is surviving changes in existing connectivity without opening the door to hijacking or DoS. All we need to authenticate is that after a multihoming event, we are still talking to the same entity at the other end. Brian Iljitsch van Beijnum wrote: > > On 23-mrt-04, at 18:17, Francis Dupont wrote: > > > The main reason to forego having identifiers is that it is hard to > > determine if a correspondent is rightfully using an identifier. > > > => can I translate this statement into a generic "authorization" issue. > > > => note that ownership is not authentication. > > Hm, I was working on the assumption that we only need authentication, > as the owner/holder of an identifier or a locator can do with it what > he or she pleases. Would it be useful to add an authorization step to > this process? I.e., despite the fact that I know you are indeed the > legitimate holder of your identifier, I may still refuse to interact > with you because you haven't been authorized to use the identifier for > this particular purpose. But then the question becomes: who grants > authorization? > > > 2. FQDNs with a certificate that leads back to a trusted authority. > > These are in relative wide use today for SSL. > > > => this implies some kind of PKI > > Yes. My point is that there is something that can be called a PKI for > SSL. > > > We can get both: in HIP "anonymous identifiers" are 1 and other > > identifiers are 1+2, at most one identifier (the initiator's one) > > can be anonymous. > > Indeed. The initiator doesn't even have to use an identifier. > > > Personally, I think the best choice would be to remain agnostic > > about > > the identifier issue for now, but build our negotiation protocol > > such > > that they can be added easily later. For now, we build a "no > > identifier" type solution. Solving the problem of how a > > correspondent > > proves ownership of an identifier can then be deferred until such > > time > > that someone actually wants to extend the multi6 solution to support > > identifiers. So the only thing we have to do now is make sure the > > protocols are flexible enough to allow such extensions. > > > => I disagree because the security, in this case a proper handling of > > the authorization issue, must be included in the design from the > > beginning. > > Good point, building something first and then trying to plug the holes > doesn't work very well. However, what is "the beginning" here? > > There are two claims that we want to check when a correspondent claims > that it is reachable at additional addresses: the "who" part and the > "reachable" part. (We don't want someone else to claim that their > addresses belong to our correspondent, but we also don't want our > correspondent to claim that someone else's addresses are theirs.) The > the "reachable" part is universal: once we create a protocol, this part > shouldn't change. However, the "who" part depends on the nature of the > identifiers. Without actual identifiers we only check whether we're > talking to the same entity, regardless of who this entity is. But with > cryptographic identifiers, we can actually check whether someone who > claims to be the holder of the identifier has the secret key. With a > PKI the procedure is different, with DNSSEC different again. > > Now what I'm saying is that we should build a "no identifiers" type > solution *now* but recognize that we may want to have identifiers > later. At some point, the protocol is extended to make it possible to > use a certain type of identifiers. Since this is the beginning of the > use of these identifiers, this is also the beginning of or security > efforts with regards to using these identifiers. In other words, it > makes no sense to include X.509 handling _now_ if we are building an > identifier-less solution. > > However, there are some things we can do to make it easier to support > X.509 certificates in the future. For instance, use length fields that > are more than 8 bits. In practice there may not be a huge difference > between building a general purpose system that supports just option X > at this time and a special purpose system that only supports option X, > but philosophically there is a world of difference. "When the only tool > you have is a hammer, every problem looks like a nail." So taking the > hammer first and then consider the problem limits our view of the > solution space. Considering the problem, then determining that we can > solve most of it with a hammer and deciding that we can only afford a > toolbox with a hammer in it at this time is very different. -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM From owner-multi6@ops.ietf.org Wed Mar 24 06:21:09 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14417 for ; Wed, 24 Mar 2004 06:21:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B66QS-0008Af-5V for multi6-data@psg.com; Wed, 24 Mar 2004 11:20:00 +0000 Received: from [163.117.136.121] (helo=smtp01.uc3m.es) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B66QH-00087K-2e for multi6@ops.ietf.org; Wed, 24 Mar 2004 11:19:49 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id E7F571BD9F; Wed, 24 Mar 2004 12:19:47 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.216]) by smtp01.uc3m.es (Postfix) with SMTP id C21DF1BD8E; Wed, 24 Mar 2004 12:19:47 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Iljitsch van Beijnum" Cc: "Multi6 List" Subject: RE: Identifiers Date: Wed, 24 Mar 2004 12:17:12 +0100 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: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > I agree, in order to build something that's usable we need to select > one way of doing this, and standardize and implement this way of doing > it. And a good way to do this would be taking working sessions and > negotiate alternative addresses for them, without the use of an > explicit identifier. However... Ok, basically you are proposing to use one of the available IP addresses as the identifier used by ULP, and then eventually introduce a new namespace for identifiers which may provide with enhanced features. The question now is how do you provide security for this negotiation of alternative addresses in this first stage? Because you will need to provide some sort of security even in this case. The good thing about some other namespaces is that make the security simpler, so when you want to use IP addresses, you need to solve the security issues somehow, without these features provided by the new identifier namespace. So what would you think would be the security tools used for negotiating multiple addresses in a solution that used IP addresses as ULP ids? > > > But, perhaps i misunderstood your proposal? > > What I'm saying is that even though it may not make sense to have full > blown identifiers _today_, it's probably a good idea to recognize that > we'll want to have them in the future, and make sure the actual > multihoming protocol we're going to build now can be easily adapted to > support identifiers. Well, whichever solution we adopt to preserve established communication, i guess that we have consensus that it will imply the upgrading of all the hosts, inside and outside the multihomed site to support it (modulo proxies). So, if we agree that a new id namespace provides value and that should be the final solution, why don't we just go for it and we require only one upgrade to all the hosts in the Internet? (Actually this was your argument a while ago, i am just quoting it because i found it very valuable :-) Regards, marcelo This means that there must be unused or option > fields in the messages that can be used to extend the protocol in a > backward compatible way. Another important issue is that when > identifiers are used, all negotiation must precede the actual > communication, so we should build our protocol that it allows this if > at all possible. > > From owner-multi6@ops.ietf.org Wed Mar 24 07:18:19 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17771 for ; Wed, 24 Mar 2004 07:18:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B67K6-000NON-N8 for multi6-data@psg.com; Wed, 24 Mar 2004 12:17:30 +0000 Received: from [131.160.192.2] (helo=p2.piuha.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B67Jv-000NMC-9T for multi6@ops.ietf.org; Wed, 24 Mar 2004 12:17:19 +0000 Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 2ED3D8996E; Wed, 24 Mar 2004 14:17:18 +0200 (EET) Message-ID: <40617BAF.1090504@piuha.net> Date: Wed, 24 Mar 2004 14:14:39 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian E Carpenter Cc: Iljitsch van Beijnum , Multi6 List Subject: Re: Identifiers References: <200403231717.i2NHHZSj041614@givry.rennes.enst-bretagne.fr> <4061618A.14A2F4E6@zurich.ibm.com> In-Reply-To: <4061618A.14A2F4E6@zurich.ibm.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Brian E Carpenter wrote: > Our problem is not ownership. It is surviving changes in existing connectivity I suspect "ownership" is not defined in the above context well enough to say whether it is or is not a part of our problem. I agree that ownership as in "IANA has allocated this address to me" is not an issue for multi6. On the other hand, address ownership has also been used in other meanings as well, e.g., in SEND its "this address has been created by this node". This might be within multi6 scope. > without opening the door to hijacking or DoS. All we need to authenticate > is that after a multihoming event, we are still talking to the same > entity at the other end. Yes. Quoting a dictionary: Identity From Latin idem, ‘the same’. 1. Sameness ... So I believe the issues of identities and checking the sameness of the entity at the other end are the same thing (no pun intended). Also, someone wrote earlier in the thread: > The main reason to forego having identifiers is that it is hard to > determine if a correspondent is rightfully using an identifier. It is indeed necessary to determine this. But of course its trivial if its a cryptographic identity such as HIT or CGA. If its a human assigned identity, such as jarkko@piuha.net, it would be much more troublesome (I don't recommend this). More importantly, note that even if you don't have identifiers, there's still a need to determine if the correspondent is rightfully claiming a multihoming event. So I believe the rightfullness / sameness check will be needed in any case. Iljitsch wrote: > For now, we build a "no identifier" type solution. Based on the above, I tend to think that we will always have an identifier, the only question is how explicit/implicit it is, and whether the identifier is a new identifier or an existing one (such as FQDNs and IP addresses in NOID). The other differentiator is how good security you get for tying the protocol exchanges to the identifier, e.g., cryptographic signatures vs. relying on DNS. --Jari From owner-multi6@ops.ietf.org Wed Mar 24 07:30:18 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18194 for ; Wed, 24 Mar 2004 07:30:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B67Va-0000FQ-In for multi6-data@psg.com; Wed, 24 Mar 2004 12:29:22 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B67VY-0000Em-Gd for multi6@ops.ietf.org; Wed, 24 Mar 2004 12:29:20 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i2OCTQI0047958; Wed, 24 Mar 2004 13:29:26 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: "Multi6 List" From: Iljitsch van Beijnum Subject: Re: Identifiers Date: Wed, 24 Mar 2004 13:29:16 +0100 To: X-Mailer: Apple Mail (2.613) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 24-mrt-04, at 12:17, marcelo bagnulo wrote: > Ok, basically you are proposing to use one of the available IP > addresses as > the identifier used by ULP, and then eventually introduce a new > namespace > for identifiers which may provide with enhanced features. Yes. (Another way to look at the first part would be not having identifiers at all.) > The question now is how do you provide security for this negotiation of > alternative addresses in this first stage? Since we have return routability there is no need to prove ownership of the first IP address. Additional IP addresses can be checked against information provided over the first one, so we can be sure that all of them are used by the same host. However, a man in the middle between one end and the original address of the other hand can subvert this process in the absense of some kind of out of band security information. My answer to this problem is that there is no need to create such an out of band system (storing info in the DNS, PKI, whatever), as long as we can make use of such a system when it's present. I think this makes sense because if you don't bother to use IPsec or TLS for a session, then the communication is subject to all kinds of nastiness from a man in the middle anyway, so protecting against session stealing isn't worth the trouble. On the other hand, if the communication is sensitive there will be IPsec/TLS anyway so having something in that case is redundant. We just need to make sure we can leverage the security information present in those protocols to secure our multihoming negotiations. > Well, whichever solution we adopt to preserve established > communication, i > guess that we have consensus that it will imply the upgrading of all > the > hosts, inside and outside the multihomed site to support it (modulo > proxies). Do you see any alternatives? I believe geographic aggregation could be one, but I'm pretty much alone in that regard. > So, if we agree that a new id namespace provides value and that should > be > the final solution, why don't we just go for it and we require only one > upgrade to all the hosts in the Internet? (Actually this was your > argument a > while ago, i am just quoting it because i found it very valuable :-) Good point. But I can think of three reasons not to: 1. Without a new namespace we can make sessions compatible with existing TCP as long as no rehoming events are necessary 2. Introducing a new namespace would take much more time 3. We don't know yet what kind of namespace we want, or even how many, so we probably need to keep our options open for adding even more anyway I'm not claiming these arguments are definitive, however. One reason to create a new namespace would be that it should make referencing and then connecting to the entity referred much easier. Iljitsch From owner-multi6@ops.ietf.org Wed Mar 24 10:22:53 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28262 for ; Wed, 24 Mar 2004 10:22:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B6ABM-000FHA-Nl for multi6-data@psg.com; Wed, 24 Mar 2004 15:20:40 +0000 Received: from [192.44.77.17] (helo=laposte.rennes.enst-bretagne.fr) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B6ABF-000FFT-3N for multi6@ops.ietf.org; Wed, 24 Mar 2004 15:20:33 +0000 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i2OFKRC01059; Wed, 24 Mar 2004 16:20:27 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i2OFKOSj046192; Wed, 24 Mar 2004 16:20:26 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200403241520.i2OFKOSj046192@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Brian E Carpenter cc: Iljitsch van Beijnum , Multi6 List Subject: Re: Identifiers In-reply-to: Your message of Wed, 24 Mar 2004 11:23:06 +0100. <4061618A.14A2F4E6@zurich.ibm.com> Date: Wed, 24 Mar 2004 16:20:24 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk In your previous mail you wrote: Our problem is not ownership. It is surviving changes in existing connectivity without opening the door to hijacking or DoS. All we need to authenticate is that after a multihoming event, we are still talking to the same entity at the other end. => this is a different problem: the binding between the identifier and the locators and we can divide it into three parts: - can be the multi-homing signaling modified by an attacker on the path? - have we to trust the peer not to give a fake locator? - have we better properties about locators? As in multi-homing we have static locators even the last part can be a reasonable goal. But the subject of this thread is "Identifiers" so I don't understand your intent... Regards Francis.Dupont@enst-bretagne.fr From owner-multi6@ops.ietf.org Wed Mar 24 10:39:47 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01501 for ; Wed, 24 Mar 2004 10:39:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B6ASN-000IaO-62 for multi6-data@psg.com; Wed, 24 Mar 2004 15:38:15 +0000 Received: from [192.44.77.17] (helo=laposte.rennes.enst-bretagne.fr) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B6ASF-000IVf-Lu for multi6@ops.ietf.org; Wed, 24 Mar 2004 15:38:07 +0000 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i2OFbrC02962; Wed, 24 Mar 2004 16:37:53 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i2OFbrSj046344; Wed, 24 Mar 2004 16:37:53 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200403241537.i2OFbrSj046344@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Iljitsch van Beijnum cc: mbagnulo@ing.uc3m.es, "Multi6 List" Subject: Re: Identifiers In-reply-to: Your message of Wed, 24 Mar 2004 13:29:16 +0100. Date: Wed, 24 Mar 2004 16:37:53 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk In your previous mail you wrote: > The question now is how do you provide security for this negotiation of > alternative addresses in this first stage? Since we have return routability there is no need to prove ownership of the first IP address. => this is highly questionable: - not all transport protocols give a return routability check for free - return routability check only constrains the position of the attacker (it has to be on the path during the attack). + multi-homing can't be less secure than standard Internet for the first IP address. Additional IP addresses can be checked against information provided over the first one, so we can be sure that all of them are used by the same host. However, a man in the middle between one end and the original address of the other hand can subvert this process in the absense of some kind of out of band security information. => this is the mobile IPv6 routing optimization problem. My answer to this problem is that there is no need to create such an out of band system (storing info in the DNS, PKI, whatever), as long as we can make use of such a system when it's present. => the mobile IPv6 answer even if the last part can be considered as dubious, at least in some current implementations... I think this makes sense because if you don't bother to use IPsec or TLS for a session, then the communication is subject to all kinds of nastiness from a man in the middle anyway, so protecting against session stealing isn't worth the trouble. On the other hand, if the communication is sensitive there will be IPsec/TLS anyway so having something in that case is redundant. We just need to make sure we can leverage the security information present in those protocols to secure our multihoming negotiations. => I agree but I am afraid that things are not as simple as you suggest... Regards Francis.Dupont@enst-bretagne.fr From owner-multi6@ops.ietf.org Wed Mar 24 11:14:29 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03670 for ; Wed, 24 Mar 2004 11:14:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B6B0z-000OBv-AI for multi6-data@psg.com; Wed, 24 Mar 2004 16:14:01 +0000 Received: from [163.117.136.121] (helo=smtp01.uc3m.es) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B6B0s-000OAf-Ma for multi6@ops.ietf.org; Wed, 24 Mar 2004 16:13:54 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 902711BED5; Wed, 24 Mar 2004 17:13:53 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.216]) by smtp01.uc3m.es (Postfix) with SMTP id 7A4A01BEA8; Wed, 24 Mar 2004 17:13:53 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: , "Brian E Carpenter" Cc: "Iljitsch van Beijnum" , "Multi6 List" Subject: RE: Identifiers Date: Wed, 24 Mar 2004 17:11:16 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" 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: <40617BAF.1090504@piuha.net> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Jari, > Based on the above, I tend to think that we will always > have an identifier, the only question is how explicit/implicit > it is, and whether the identifier is a new identifier or an > existing one (such as FQDNs and IP addresses in NOID). I guess that another question related to this is at which level the identifier applies. I mean, if you consider a solution that apllies at the transport level, like sctp or address agile TCP, you don't have a IP level identifier. You will have a application level identifier, i guess which will probably be one of the ip addresses. Regards, marcelo > The > other differentiator is how good security you get for > tying the protocol exchanges to the identifier, e.g., > cryptographic signatures vs. relying on DNS. > > --Jari > > From owner-multi6@ops.ietf.org Wed Mar 24 11:47:13 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05683 for ; Wed, 24 Mar 2004 11:47:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B6BWN-00038o-FU for multi6-data@psg.com; Wed, 24 Mar 2004 16:46:27 +0000 Received: from [195.212.14.170] (helo=mail-gw2.hursley.ibm.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B6BW9-00037Y-6P for multi6@ops.ietf.org; Wed, 24 Mar 2004 16:46:13 +0000 Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw2.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.12) id 1B6BW5-0002PA-00; Wed, 24 Mar 2004 16:46:09 +0000 Received: from [9.20.136.27] (helo=sp15en17.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.12) id 1B6BW5-0002P5-00; Wed, 24 Mar 2004 16:46:09 +0000 Received: from zurich.ibm.com (sig-9-145-243-117.de.ibm.com [9.145.243.117]) by sp15en17.hursley.ibm.com (AIX5.1/8.11.6p2/8.11.0) with ESMTP id i2OGk3F69650; Wed, 24 Mar 2004 16:46:05 GMT Message-ID: <4061BB64.CB4DA0E7@zurich.ibm.com> Date: Wed, 24 Mar 2004 17:46:28 +0100 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: Francis Dupont CC: Iljitsch van Beijnum , Multi6 List Subject: Re: Identifiers References: <200403241520.i2OFKOSj046192@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Francis Dupont wrote: > > In your previous mail you wrote: > > Our problem is not ownership. It is surviving changes in existing > connectivity without opening the door to hijacking or DoS. All we need > to authenticate is that after a multihoming event, we are still > talking to the same entity at the other end. > > => this is a different problem: the binding between the identifier and > the locators and we can divide it into three parts: > - can be the multi-homing signaling modified by an attacker on the path? > - have we to trust the peer not to give a fake locator? > - have we better properties about locators? > As in multi-homing we have static locators even the last part can be > a reasonable goal. > But the subject of this thread is "Identifiers" so I don't understand > your intent... My intent is to observe that for the problem this WG is supposed to solve, we don't care whether the claimed identifier at the beginning of a session is genuine. What we care about (rather like TLS) is whether the two communicating entities remain the same even if the session suffers a rehoming event. I don't think we are disagreeing. Brian From owner-multi6@ops.ietf.org Wed Mar 24 13:30:29 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11873 for ; Wed, 24 Mar 2004 13:30:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B6D6a-000Ja3-J1 for multi6-data@psg.com; Wed, 24 Mar 2004 18:27:56 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B6D5q-000JSu-4M for multi6@ops.ietf.org; Wed, 24 Mar 2004 18:27:10 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i2OIRHI0052882; Wed, 24 Mar 2004 19:27:17 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: "Multi6 List" From: Iljitsch van Beijnum Subject: Re: Identifiers Date: Wed, 24 Mar 2004 19:27:06 +0100 To: X-Mailer: Apple Mail (2.613) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 24-mrt-04, at 17:39, marcelo bagnulo wrote: >>> The question now is how do you provide security for this negotiation >>> of >>> alternative addresses in this first stage? >> Since we have return routability there is no need to prove ownership >> of >> the first IP address. > Return routability procedure has an inherent problem when it is > applied to > the multihoming scenario. the problem is that in multihoming, at a > given > moment, the address is no longer reachable, so it is difficult to > distinguish an outage from and attack. Obviously the first phase of the negotiation (where we do RR for the initial address) must be complete before surviving an outage is possible. > Please, note that when using RR it is not enough to verify the initial > address only at the beginning, you need to verify it periodically, if > not, > you are susceptible to time shifted attacks I don't see why this would be necessary. >> I think this makes sense because if you don't bother to use IPsec or >> TLS for a session, then the communication is subject to all kinds of >> nastiness from a man in the middle anyway, so protecting against >> session stealing isn't worth the trouble. > This is where i don't agree. I think we shouldn't do things worse than > what > they already are (or at least not too much worse) Someone who can intercept your communication with Google can already reset the TCP session so you don't get to see your search results. Why would the capability to redirect those search results to another IP address be much worse than this? >> 1. Without a new namespace we can make sessions compatible with >> existing TCP as long as no rehoming events are necessary > Well, i guess that if the other end is upgraded it doesn't matter, and > if it > is not, the only option is to fall back to regular IP and not use the > new > ids. You make it sound so easy. :-) The tricky part here is to make sure that communication between an upgraded host and a non upgraded host always works as before, while communication between two upgraded hosts uses the new capabilities. This makes it necessary to add some magic to determine the capabilities of the remote host, preferably without incurring any delays. Being able to just start a session and then negotiate additional addresses later is a plus here. But we might be able to this by creating identifiers but allow the identifier space to overlap with the locator space. For instance, 2001:345::678 could be such a new identifier. Legacy hosts would simply put this value in the destination address. But upgraded host would execute some TBD id->loc mapping function and receive a set of locators. A further refinement would be for an upgraded host to first try to connect to the address directly in a backward compatible way and then negotiate additional addresses as per NOID/DHT. Only when this fails the id->loc database is consulted. (The id->loc database could also aid in securing the negotiation.) >> 2. Introducing a new namespace would take much more time > Why? I guess that if the id is managed, perhaps, but there are other > options Because it's more work. >> 3. We don't know yet what kind of namespace we want, or even how many, >> so we probably need to keep our options open for adding even more >> anyway > Well, as is said, IMHO this is the problem that we should solve, and we > should make a decision on this. So what kind of identifiers would you like to see? Iljitsch From owner-multi6@ops.ietf.org Wed Mar 24 13:38:38 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12410 for ; Wed, 24 Mar 2004 13:38:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B6DGc-000LNq-6B for multi6-data@psg.com; Wed, 24 Mar 2004 18:38:18 +0000 Received: from [163.117.136.121] (helo=smtp01.uc3m.es) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B6DG8-000LDV-6l for multi6@ops.ietf.org; Wed, 24 Mar 2004 18:37:48 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 932A81BF64; Wed, 24 Mar 2004 19:37:47 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.216]) by smtp01.uc3m.es (Postfix) with SMTP id 7CF871BF47; Wed, 24 Mar 2004 19:37:47 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Brian E Carpenter" , "Francis Dupont" Cc: "Iljitsch van Beijnum" , "Multi6 List" Subject: RE: Identifiers Date: Wed, 24 Mar 2004 19:35:10 +0100 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: <4061BB64.CB4DA0E7@zurich.ibm.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > My intent is to observe that for the problem this WG is supposed to > solve, we don't care whether the claimed identifier at the beginning > of a session is genuine. What we care about (rather like TLS) is whether > the two communicating entities remain the same even if the session suffers > a rehoming event. I don't think we are disagreeing. I think that we may not care if the source address is genuine but we do care that the destiantion address is genuine. I mean, if i know that the address IPA belongs to www.foo.com (suppose that i have learned it through the DNS), i want that when i send packets to IPA they get to www.foo.com. It would be bad that becuase of multihoming mechanisms,when i start sending packets to IPA, they end up in somewhere else. The point is that if we care about destination addresses being genuine, we may also need to care about source addresses being genuine, depending on the sense of direction that the considered solution has. I mean, if the source address of established communications will be used as destiantion address for following communcations, if an attacker succeed in convincing a victim that IPA is one of its source addresses, following communications established by the victim to IPA will be routed to the attacker. Regards, marcelo > > Brian > From owner-multi6@ops.ietf.org Wed Mar 24 15:58:33 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20999 for ; Wed, 24 Mar 2004 15:58:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B6FR1-000Ktg-Un for multi6-data@psg.com; Wed, 24 Mar 2004 20:57:11 +0000 Received: from [130.76.64.48] (helo=slb-smtpout-01.boeing.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B6FQw-000KoB-Dl for multi6@ops.ietf.org; Wed, 24 Mar 2004 20:57:06 +0000 Received: from slb-av-02.boeing.com ([129.172.13.7]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id MAA05636; Wed, 24 Mar 2004 12:56:51 -0800 (PST) Received: from stl-hub-01.boeing.com (localhost [127.0.0.1]) by slb-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-02) with ESMTP id MAA01522; Wed, 24 Mar 2004 12:56:51 -0800 (PST) Received: from XCH-NWBH-01.nw.nos.boeing.com (xch-nwbh-01.nw.nos.boeing.com [192.33.62.231]) by stl-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id i2OKsrQ24828; Wed, 24 Mar 2004 14:54:53 -0600 (CST) Received: from XCH-NW-09.nw.nos.boeing.com ([192.42.226.84]) by XCH-NWBH-01.nw.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.6662); Wed, 24 Mar 2004 12:54:38 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6521.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Identifiers Date: Wed, 24 Mar 2004 12:54:38 -0800 Message-ID: <5B58696DB20B9140AD20E0685C573A6402992F90@xch-nw-09.nw.nos.boeing.com> Thread-Topic: Identifiers Thread-Index: AcQR0J/MVp6J9Wd5QqC9uIY882wJyAABTcig From: "Fleischman, Eric" To: , "Brian E Carpenter" , "Francis Dupont" Cc: "Iljitsch van Beijnum" , "Multi6 List" X-OriginalArrivalTime: 24 Mar 2004 20:54:38.0733 (UTC) FILETIME=[38DA53D0:01C411E2] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo [mailto:mbagnulo@ing.uc3m.es] wrote: >The point is that if we care about destination addresses being genuine, = we >may also need to care about source addresses being genuine, depending = on the >sense of direction that the considered solution has. I mean, if the = source >address of established communications will be used as destiantion = address >for following communcations, if an attacker succeed in convincing a = victim >that IPA is one of its source addresses, following communications >established by the victim to IPA will be routed to the attacker. This point resonates with me.=20 Also, if it were possible today to know that the source IP address were = a=20 genuine IP address, then that would strengthen a deployment's security = posture.=20 That is, today we can't know if many attacks are using spoofed addresses = or not.=20 However, if we could know that the source address was not valid, then we = could=20 identify that packet as being an attack and discard/ignore it (e.g., = during a=20 (D)DoS attack). Our security posture would be further improved if we = could know=20 that the claimed sender did indeed send that packet (i.e., = non-repudiation; i.e.,=20 knowing whether a genuine address was being spoofed or not).=20 Changing topics, I am confused (perhaps because I am a newbie on this = list)=20 by the earlier discussion about authentication and authorization. I would have thought that we would be using IPSec (whether AH or ESP) for=20 situations requiring authentication at the network layer. Is there a = reason why we aren't use IPSec but rather need an alternative network layer = provision? From owner-multi6@ops.ietf.org Wed Mar 24 23:51:41 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13533 for ; Wed, 24 Mar 2004 23:51:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B6MoU-0006qc-41 for multi6-data@psg.com; Thu, 25 Mar 2004 04:49:54 +0000 Received: from [208.184.79.7] (helo=joy.songbird.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B6MoS-0006qB-VR for multi6@ops.ietf.org; Thu, 25 Mar 2004 04:49:53 +0000 Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i2P4nnd08562; Wed, 24 Mar 2004 20:49:49 -0800 Date: Wed, 24 Mar 2004 20:49:36 -0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <405646300.20040324204936@brandenburg.com> To: Brian E Carpenter CC: Multi6 Subject: Re: Proposed dates and place for multi6 interim meeting In-Reply-To: <4056B634.1CF64135@zurich.ibm.com> References: <4056B634.1CF64135@zurich.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.7 required=5.0 tests=AWL,BAYES_00,PRIORITY_NO_NAME autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Brian, BEC> The proposal is to co-locate the meeting with ISOC's INET BEC> conference in Barcelona, Spain, on Monday May 10 and Tuesday BEC> May 11 (exact timing and exact location still TBD). when will the date become firm? d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-multi6@ops.ietf.org Thu Mar 25 02:58:02 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07939 for ; Thu, 25 Mar 2004 02:58:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B6Pij-000AuO-PO for multi6-data@psg.com; Thu, 25 Mar 2004 07:56:09 +0000 Received: from [195.212.14.170] (helo=mail-gw2.hursley.ibm.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B6PiV-000Anf-B6 for multi6@ops.ietf.org; Thu, 25 Mar 2004 07:55:55 +0000 Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw2.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.12) id 1B6PiU-0002t3-00; Thu, 25 Mar 2004 07:55:54 +0000 Received: from [9.20.136.27] (helo=sp15en17.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.12) id 1B6PiT-0002sy-00; Thu, 25 Mar 2004 07:55:53 +0000 Received: from zurich.ibm.com (dyn-9-13-126-72.ge.ch.ibm.com [9.13.126.72]) by sp15en17.hursley.ibm.com (AIX5.1/8.11.6p2/8.11.0) with ESMTP id i2P7trF137594; Thu, 25 Mar 2004 07:55:54 GMT Message-ID: <406290A2.7ECBDFFA@zurich.ibm.com> Date: Thu, 25 Mar 2004 08:56:18 +0100 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: Dave Crocker CC: Multi6 Subject: Re: Proposed dates and place for multi6 interim meeting References: <4056B634.1CF64135@zurich.ibm.com> <405646300.20040324204936@brandenburg.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit A majority of people were OK with the date. We are just waiting for confirmation that we can get a suitable room... the reply on that is overdue... Brian Dave Crocker wrote: > > Brian, > > BEC> The proposal is to co-locate the meeting with ISOC's INET > BEC> conference in Barcelona, Spain, on Monday May 10 and Tuesday > BEC> May 11 (exact timing and exact location still TBD). > > when will the date become firm? > > d/ > -- > Dave Crocker > Brandenburg InternetWorking > Sunnyvale, CA USA -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM From owner-multi6@ops.ietf.org Thu Mar 25 04:08:56 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10078 for ; Thu, 25 Mar 2004 04:08:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B6Qq6-000LNu-1u for multi6-data@psg.com; Thu, 25 Mar 2004 09:07:50 +0000 Received: from [163.117.136.121] (helo=smtp01.uc3m.es) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B6Qq5-000LNi-2S for multi6@ops.ietf.org; Thu, 25 Mar 2004 09:07:49 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 0B21D1A039; Thu, 25 Mar 2004 10:07:48 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.216]) by smtp01.uc3m.es (Postfix) with SMTP id CB8FB19D0D; Thu, 25 Mar 2004 10:07:47 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Fleischman, Eric" , "Brian E Carpenter" , "Francis Dupont" Cc: "Iljitsch van Beijnum" , "Multi6 List" Subject: RE: Identifiers Date: Thu, 25 Mar 2004 10:05:08 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <5B58696DB20B9140AD20E0685C573A6402992F90@xch-nw-09.nw.nos.boeing.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Erik, > Also, if it were possible today to know that the source IP address were a > genuine IP address, then that would strengthen a deployment's > security posture. Well, the multi6 problem is already pretty difficult as it is, so i would say that achieving additional goals like what you are mentioning is a plus but it is not a requirment. > That is, today we can't know if many attacks are using spoofed > addresses or not. > However, if we could know that the source address was not valid, > then we could > identify that packet as being an attack and discard/ignore it > (e.g., during a > (D)DoS attack). Our security posture would be further improved if > we could know > that the claimed sender did indeed send that packet (i.e., > non-repudiation; i.e., > knowing whether a genuine address was being spoofed or not). > > Changing topics, I am confused (perhaps because I am a newbie on > this list) > by the earlier discussion about authentication and authorization. I > would have thought that we would be using IPSec (whether AH or ESP) for > situations requiring authentication at the network layer. Is > there a reason > why we aren't use IPSec but rather need an alternative network > layer provision? HIP uses IPSec ESP headers, but some others solutions use alternative formats, for optimization, for instance Regards, marcelo > From owner-multi6@ops.ietf.org Thu Mar 25 04:45:45 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11336 for ; Thu, 25 Mar 2004 04:45:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B6RQN-0000G7-9w for multi6-data@psg.com; Thu, 25 Mar 2004 09:45:19 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B6RQK-0000Dc-T1 for multi6@ops.ietf.org; Thu, 25 Mar 2004 09:45:17 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i2P9jMI0065037; Thu, 25 Mar 2004 10:45:22 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <5B58696DB20B9140AD20E0685C573A6402992F90@xch-nw-09.nw.nos.boeing.com> References: <5B58696DB20B9140AD20E0685C573A6402992F90@xch-nw-09.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1C8A97E6-7E41-11D8-B3CC-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: Multi6 List From: Iljitsch van Beijnum Subject: Re: Identifiers Date: Thu, 25 Mar 2004 10:45:12 +0100 To: "Fleischman, Eric" X-Mailer: Apple Mail (2.613) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 24-mrt-04, at 21:54, Fleischman, Eric wrote: > Also, if it were possible today to know that the source IP address > were a > genuine IP address, then that would strengthen a deployment's security > posture. So what's a genuine IP address? As opposed to a cheap knockoff? :-) > That is, today we can't know if many attacks are using spoofed > addresses or not. However, if we could know that the source address > was not valid, then we could identify that packet as being an attack > and discard/ignore it (e.g., during a (D)DoS attack). These days people rarely take the trouble to fake the source address in DoS attacks. The real problem here is that sources get to send traffic without any means for the recipient to shut them up. So what we need is a way to determine whether the recipient is prepared to receive certain traffic. I came up with a way to do just that a while ago but I haven't written it down as a draft yet. The quick version: The idea is that a service provider does proxy IPsec AH verification on behalf of the recipient. The key used for computing the AH header is a hash of the SPI, the source and destination addresses and a secret that is known to the service provider and the recipient, but not the sender. The sender only gets to know the key that is particular to the negotiated SPI, but the service provider only has to maintain a relatively small list of recently invalidated SPIs and the shared secret and can check the packets coming in from all senders. The recipient hands out SPIs/keys to senders and invalidates SPIs when senders do stuff they're not supposed to do and then doesn't give them a new one. > Our security posture would be further improved if we could know > that the claimed sender did indeed send that packet (i.e., > non-repudiation; i.e., knowing whether a genuine address was being > spoofed or not). Sounds like a job for IPsec. > I would have thought that we would be using IPSec (whether AH or ESP) > for > situations requiring authentication at the network layer. Is there a > reason > why we aren't use IPSec but rather need an alternative network layer > provision? We don't want to have AH or ESP headers in all packets because of the overhead. This is something like 24 bytes per packet minimum, making the overhead of our multihoming scheme + IPv6 more than double that of IPv4 (multihomed or otherwise). There are also deployment issues: how many people are talking IPsec to strangers today? From owner-multi6@ops.ietf.org Thu Mar 25 04:51:31 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11496 for ; Thu, 25 Mar 2004 04:51:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B6RWE-0001Jo-UM for multi6-data@psg.com; Thu, 25 Mar 2004 09:51:22 +0000 Received: from [195.212.14.170] (helo=mail-gw2.hursley.ibm.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B6RWC-0001JV-Fm for multi6@ops.ietf.org; Thu, 25 Mar 2004 09:51:21 +0000 Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw2.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.12) id 1B6RW8-0002zt-00; Thu, 25 Mar 2004 09:51:16 +0000 Received: from [9.20.136.27] (helo=sp15en17.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.12) id 1B6RW8-0002zo-00; Thu, 25 Mar 2004 09:51:16 +0000 Received: from zurich.ibm.com (dyn-9-13-126-72.ge.ch.ibm.com [9.13.126.72]) by sp15en17.hursley.ibm.com (AIX5.1/8.11.6p2/8.11.0) with ESMTP id i2P9pDF134734; Thu, 25 Mar 2004 09:51:14 GMT Message-ID: <4062ABAA.172A35D4@zurich.ibm.com> Date: Thu, 25 Mar 2004 10:51:38 +0100 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: mbagnulo@ing.uc3m.es CC: Francis Dupont , Iljitsch van Beijnum , Multi6 List Subject: Re: Identifiers References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit marcelo bagnulo wrote: > > > My intent is to observe that for the problem this WG is supposed to > > solve, we don't care whether the claimed identifier at the beginning > > of a session is genuine. What we care about (rather like TLS) is whether > > the two communicating entities remain the same even if the session suffers > > a rehoming event. I don't think we are disagreeing. > > I think that we may not care if the source address is genuine but we do care > that the destiantion address is genuine. I mean, if i know that the address > IPA belongs to www.foo.com (suppose that i have learned it through the DNS), > i want that when i send packets to IPA they get to www.foo.com. It would be > bad that becuase of multihoming mechanisms,when i start sending packets to > IPA, they end up in somewhere else. > > The point is that if we care about destination addresses being genuine, we > may also need to care about source addresses being genuine, depending on the > sense of direction that the considered solution has. I mean, if the source > address of established communications will be used as destiantion address > for following communcations, if an attacker succeed in convincing a victim > that IPA is one of its source addresses, following communications > established by the victim to IPA will be routed to the attacker. My assumption is certainly that we can trust the first address pair, to exactly the extent that we can trust it in a non-multihomed case. Is that a wrong assumption? This should be made explicit one way or the other in the threats draft. Brian From owner-multi6@ops.ietf.org Thu Mar 25 04:55:18 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11635 for ; Thu, 25 Mar 2004 04:55:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B6RZz-00023b-GS for multi6-data@psg.com; Thu, 25 Mar 2004 09:55:15 +0000 Received: from [195.212.14.170] (helo=mail-gw2.hursley.ibm.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B6RZx-00022s-Qn for multi6@ops.ietf.org; Thu, 25 Mar 2004 09:55:14 +0000 Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw2.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.12) id 1B6RZu-00035T-00; Thu, 25 Mar 2004 09:55:10 +0000 Received: from [9.20.136.27] (helo=sp15en17.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.12) id 1B6RZu-00035O-00; Thu, 25 Mar 2004 09:55:10 +0000 Received: from zurich.ibm.com (dyn-9-13-126-72.ge.ch.ibm.com [9.13.126.72]) by sp15en17.hursley.ibm.com (AIX5.1/8.11.6p2/8.11.0) with ESMTP id i2P9t9F134768; Thu, 25 Mar 2004 09:55:09 GMT Message-ID: <4062AC96.9B1362B3@zurich.ibm.com> Date: Thu, 25 Mar 2004 10:55:34 +0100 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: mbagnulo@ing.uc3m.es CC: "Fleischman, Eric" , Francis Dupont , Iljitsch van Beijnum , Multi6 List Subject: IPSEC or not [Re: Identifiers] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit marcelo bagnulo wrote: > > Hi Erik, ... > > Changing topics, I am confused (perhaps because I am a newbie on > > this list) > > by the earlier discussion about authentication and authorization. I > > would have thought that we would be using IPSec (whether AH or ESP) for > > situations requiring authentication at the network layer. Is > > there a reason > > why we aren't use IPSec but rather need an alternative network > > layer provision? > > HIP uses IPSec ESP headers, but some others solutions use alternative > formats, for optimization, for instance At the moment we are trying to reach an architectural view - i.e. what do we need to authenticate, if anything? Whether we use HIP or IPSEC is a solution-space choice, for a little bit later. Brian From owner-multi6@ops.ietf.org Thu Mar 25 05:39:20 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14072 for ; Thu, 25 Mar 2004 05:39:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B6SFb-0007pC-3F for multi6-data@psg.com; Thu, 25 Mar 2004 10:38:15 +0000 Received: from [163.117.136.121] (helo=smtp01.uc3m.es) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B6SFZ-0007ow-MO for multi6@ops.ietf.org; Thu, 25 Mar 2004 10:38:13 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 24B2F1BCD9; Thu, 25 Mar 2004 11:38:13 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.216]) by smtp01.uc3m.es (Postfix) with SMTP id 0E6811BC2E; Thu, 25 Mar 2004 11:38:13 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Brian E Carpenter" Cc: "Francis Dupont" , "Iljitsch van Beijnum" , "Multi6 List" Subject: RE: Identifiers Date: Thu, 25 Mar 2004 11:35:33 +0100 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: <4062ABAA.172A35D4@zurich.ibm.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > My assumption is certainly that we can trust the first address pair, to > exactly the extent that we can trust it in a non-multihomed case. Is > that a wrong assumption? IMHO it is a bit more tricky. First of all, the initial comment was about general identifiers, not restricted to addresses. Depending on the nature of the identifier it is more or less easier to steal a given identifier. In the case of using addresses, return routabilibity i.e. the capability of sending and receiving packets from/to the identifier (address) provides you a little level of trust that the other ends owns the address (identifier). If other identifiers are used, this level of trust may disappear (or improve) In the particular case of addresses, the problem with multihoming is that verifying the addresses at the initial stage through return routability only provides proof of ownership at this moment in time. It does not guarantee it in the future. That is the attacker may be intercepting the packets only at the initial stage, and then move somewhere else. If you trust an IP address that you have only verified at the setup stage, you are exposed to this attacks called time shifted attacks (P. Nikander et al.) Finally, it seems that it is accepted that source addresses cannot be trusted, but we do trust destination addresses, since we expect that packets are delivered to that destination. However, in multihoming, the sense of direction of source and destination may change in time. I mean, suppose that i don't really verify a source address (or a source identifier in general) and i just accept (without further verification) that a certain identifier I has initiated a communication with me and it is reachable at the locators L1,..,Ln. This may be ok, since it is not good in the current Internet to trust the source address (source identifier) the problem is that if i keep this state binding the identifier I with locators L1,...,Ln as valid, i will use if in the future when i try to initiate a communication with identifier I. Now this is problem, because i want to communicate with I and i am trusting an unverified state linking I to a set of locators to reach it. > > This should be made explicit one way or the other in the threats draft. Well, some of this issues are already in the draft, and some others have been discussed with Erik and the list. Let?s wait for the next version and see Regards, marcelo > > Brian > From owner-multi6@ops.ietf.org Thu Mar 25 06:03:02 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14800 for ; Thu, 25 Mar 2004 06:03:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B6SdA-000Cqd-Qm for multi6-data@psg.com; Thu, 25 Mar 2004 11:02:36 +0000 Received: from [163.117.136.121] (helo=smtp01.uc3m.es) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B6Sd9-000CqO-CK for multi6@ops.ietf.org; Thu, 25 Mar 2004 11:02:35 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 8F33F1BCD9; Thu, 25 Mar 2004 12:02:34 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.216]) by smtp01.uc3m.es (Postfix) with SMTP id 798451BC2C; Thu, 25 Mar 2004 12:02:34 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Iljitsch van Beijnum" Cc: "Multi6 List" Subject: RE: Identifiers Date: Thu, 25 Mar 2004 11:59:55 +0100 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: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.6 required=5.0 tests=AWL,BAYES_00, NEW_DOMAIN_EXTENSIONS autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > Return routability procedure has an inherent problem when it is > > applied to > > the multihoming scenario. the problem is that in multihoming, at a > > given > > moment, the address is no longer reachable, so it is difficult to > > distinguish an outage from and attack. > > Obviously the first phase of the negotiation (where we do RR for the > initial address) must be complete before surviving an outage is > possible. Agree > > > Please, note that when using RR it is not enough to verify the initial > > address only at the beginning, you need to verify it periodically, if > > not, > > you are susceptible to time shifted attacks > > I don't see why this would be necessary. Please see my reply to Brian about time shifted attacks an other similar attacks. > > >> I think this makes sense because if you don't bother to use IPsec or > >> TLS for a session, then the communication is subject to all kinds of > >> nastiness from a man in the middle anyway, so protecting against > >> session stealing isn't worth the trouble. > > > This is where i don't agree. I think we shouldn't do things worse than > > what > > they already are (or at least not too much worse) > > Someone who can intercept your communication with Google can already > reset the TCP session so you don't get to see your search results. Why > would the capability to redirect those search results to another IP > address be much worse than this? well, this would be something like a DoS attack. i think that thinking that you are communicating with google but in fact being in communication with another malicious party is worse than DoS. Some will claim that you can already do this by intercepting DNS queries, but the point is that this sort of issues are being worked on, so we better off if we don't add vulnerabilities, i guess. > > >> 1. Without a new namespace we can make sessions compatible with > >> existing TCP as long as no rehoming events are necessary > > > Well, i guess that if the other end is upgraded it doesn't matter, and > > if it > > is not, the only option is to fall back to regular IP and not use the > > new > > ids. > > You make it sound so easy. :-) Sorry, i didn't wanted to sound as if i was over simplifying the issue that you were cosnidering, it is just that i didn't understand it properly. > The tricky part here is to make sure > that communication between an upgraded host and a non upgraded host > always works as before, while communication between two upgraded hosts > uses the new capabilities. This makes it necessary to add some magic to > determine the capabilities of the remote host, preferably without > incurring any delays. Agree. How does the current proposals deal with this? I guess that you can carry the new id in an extension header (optional destiantion option for instance) and if the host is upgraded it will process it and if not will just discard it and use the IP address. The cost of this is the bit of the extension header in the first packet > > Being able to just start a session and then negotiate additional > addresses later is a plus here. I fully agree with this, but for other reasons, i guess. I think this is a plus basically because you can avoid the additional cost of negotiating and validating additional locators when you will not need them, i think this was called delayed setup. this is good for upgraded hosts. > But we might be able to this by > creating identifiers but allow the identifier space to overlap with the > locator space. For instance, 2001:345::678 could be such a new > identifier. Legacy hosts would simply put this value in the destination > address. But upgraded host would execute some TBD id->loc mapping > function and receive a set of locators. A further refinement would be > for an upgraded host to first try to connect to the address directly in > a backward compatible way and then negotiate additional addresses as > per NOID/DHT. Only when this fails the id->loc database is consulted. > (The id->loc database could also aid in securing the negotiation.) This will depend on the nature of the id space that you use. Some identifiers name space cannot be delegated in blocks like addresses (for instance CBIDs) > > >> 2. Introducing a new namespace would take much more time > > > Why? I guess that if the id is managed, perhaps, but there are other > > options > > Because it's more work. I mean, which is the additional work related to the namespace when you are using a self generated statically unique CBID? > > >> 3. We don't know yet what kind of namespace we want, or even how many, > >> so we probably need to keep our options open for adding even more > >> anyway > > > Well, as is said, IMHO this is the problem that we should solve, and we > > should make a decision on this. > > So what kind of identifiers would you like to see? I think that CBIDs provide value to the architecture and enable clean solutions for multiple problems. I also think that any solution for preserving established communication will imply the modification of all the hosts. So if the solution requires such a high cost, it would be good to take the most out of it. I mean, i would rather add a functionality in all the hosts that is useful in a general way, not just a patch to solve this particular problem. Regards, marcelo > > Iljitsch > From owner-multi6@ops.ietf.org Thu Mar 25 09:09:19 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21490 for ; Thu, 25 Mar 2004 09:09:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B6VVb-000DZV-HS for multi6-data@psg.com; Thu, 25 Mar 2004 14:06:59 +0000 Received: from [163.117.136.121] (helo=smtp01.uc3m.es) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B6BS3-0002ER-DV for multi6@ops.ietf.org; Wed, 24 Mar 2004 16:41:59 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 901571BF01; Wed, 24 Mar 2004 17:41:58 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.216]) by smtp01.uc3m.es (Postfix) with SMTP id 7A8C71BF00; Wed, 24 Mar 2004 17:41:58 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Iljitsch van Beijnum" Cc: "Multi6 List" Subject: RE: Identifiers Date: Wed, 24 Mar 2004 17:39:21 +0100 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: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Yes. (Another way to look at the first part would be not having > identifiers at all.) Well, i subscribe more to Jari's view, where in this case one of the IP addresses is the id, but never mind, i guess we understand what we are talking about. > > > The question now is how do you provide security for this negotiation of > > alternative addresses in this first stage? > > Since we have return routability there is no need to prove ownership of > the first IP address. I am afraid not. If there any value in the exercise of trying to use MIP for multihoming, is that you can clearly understand the limitations of the return routability check for the multihoming case. Return routability procedure has an inherent problem when it is applied to the multihoming scenario. the problem is that in multihoming, at a given moment, the address is no longer reachable, so it is difficult to distinguish an outage from and attack. I mean, you the verification with RR is that you get there, but when an outage occurs, by definition you can't get there, so RR seems a poor choice when you will have to deal with outages. Some patches can be made, as we have discussed with you regarding ODT, but i am afraid that you end up with a fragile solution or with a not very secure solution. Please, note that when using RR it is not enough to verify the initial address only at the beginning, you need to verify it periodically, if not, you are susceptible to time shifted attacks > Additional IP addresses can be checked against > information provided over the first one, so we can be sure that all of > them are used by the same host. However, a man in the middle between > one end and the original address of the other hand can subvert this > process in the absense of some kind of out of band security > information. Yes, i don't think that securing from MitM attacks is a requirement. > My answer to this problem is that there is no need to > create such an out of band system (storing info in the DNS, PKI, > whatever), as long as we can make use of such a system when it's > present. > > I think this makes sense because if you don't bother to use IPsec or > TLS for a session, then the communication is subject to all kinds of > nastiness from a man in the middle anyway, so protecting against > session stealing isn't worth the trouble. This is where i don't agree. I think we shouldn't do things worse than what they already are (or at least not too much worse) > On the other hand, if the > communication is sensitive there will be IPsec/TLS anyway so having > something in that case is redundant. We just need to make sure we can > leverage the security information present in those protocols to secure > our multihoming negotiations. > > > Well, whichever solution we adopt to preserve established > > communication, i > > guess that we have consensus that it will imply the upgrading of all > > the > > hosts, inside and outside the multihomed site to support it (modulo > > proxies). > > Do you see any alternatives? No,no. I was just highlighting one of the few points where i think we have cancerous. > I believe geographic aggregation could be > one, but I'm pretty much alone in that regard. > > > So, if we agree that a new id namespace provides value and that should > > be > > the final solution, why don't we just go for it and we require only one > > upgrade to all the hosts in the Internet? (Actually this was your > > argument a > > while ago, i am just quoting it because i found it very valuable :-) > > Good point. But I can think of three reasons not to: > > 1. Without a new namespace we can make sessions compatible with > existing TCP as long as no rehoming events are necessary Well, i guess that if the other end is upgraded it doesn't matter, and if it is not, the only option is to fall back to regular IP and not use the new ids. > 2. Introducing a new namespace would take much more time Why? I guess that if the id is managed, perhaps, but there are other options > 3. We don't know yet what kind of namespace we want, or even how many, > so we probably need to keep our options open for adding even more > anyway Well, as is said, IMHO this is the problem that we should solve, and we should make a decision on this. Regards, marcelo > > I'm not claiming these arguments are definitive, however. One reason to > create a new namespace would be that it should make referencing and > then connecting to the entity referred much easier. > > Iljitsch > > From owner-multi6@ops.ietf.org Fri Mar 26 09:06:47 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20552 for ; Fri, 26 Mar 2004 09:06:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B6rx2-000JO9-5C for multi6-data@psg.com; Fri, 26 Mar 2004 14:04:48 +0000 Received: from [195.212.14.170] (helo=mail-gw2.hursley.ibm.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B6rwy-000JNM-U7 for multi6@ops.ietf.org; Fri, 26 Mar 2004 14:04:45 +0000 Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw2.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.12) id 1B6rwy-0003RS-00 for multi6@ops.ietf.org; Fri, 26 Mar 2004 14:04:44 +0000 Received: from [9.20.136.27] (helo=sp15en17.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.12) id 1B6rwx-0003RN-00 for multi6@ops.ietf.org; Fri, 26 Mar 2004 14:04:43 +0000 Received: from zurich.ibm.com (sig-9-145-246-252.de.ibm.com [9.145.246.252]) by sp15en17.hursley.ibm.com (AIX5.1/8.11.6p2/8.11.0) with ESMTP id i2QE4hF126482 for ; Fri, 26 Mar 2004 14:04:43 GMT Message-ID: <40643893.76C612A5@zurich.ibm.com> Date: Fri, 26 Mar 2004 15:05:07 +0100 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: Multi6 Subject: Change of plan [Re: Proposed dates and place for multi6 interim meeting] References: <4056B634.1CF64135@zurich.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Unfortunately we can't hold the interim meeting in Barcelona. While it was OK for a majority of the people who responded, the local organizers have been unable to find a room and the situation for hotel rooms that week is terrible (except for those who book through the INET conference). So we now have to repeat the poll. We are thinking about holding the meeting for two days in the period June 7 through 18, either in Europe or the US. Please send me (not the list) a *short* note indicating the days between June 7 and June 18 that would be OK for you, your preference between Europe and the US, or a NO if that time period is excluded for you. We will consider responses that arrive by next Wednesday (March 31). And please consider going to INET anyway: http://www.isoc.org/inet04/ Brian co-chair Brian E Carpenter wrote: > > Folks, > > We have a proposal for the dates and place for the multi6 > interim meeting. This takes into account the travel plans > and availability of the co-chairs, the AD, and the two document > authors that we absolutely need at the meeting, Eliot Lear > and Geoff Huston. > > The proposal is to co-locate the meeting with ISOC's INET > conference in Barcelona, Spain, on Monday May 10 and Tuesday > May 11 (exact timing and exact location still TBD). > > See http://www.isoc.org/inet04/ for the conference itself. > > We couldn't find any other time and place that works. > > We'd like a first indication of how many people will be able > to participate, before proceeding with the logistics and > formalities. A response this week would be very helpful. > > Please don't cc the list; simply reply to > > Brian + Kurtis > co-chairs -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM From owner-multi6@ops.ietf.org Fri Mar 26 17:59:46 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22695 for ; Fri, 26 Mar 2004 17:59:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B70Hr-000JP4-LE for multi6-data@psg.com; Fri, 26 Mar 2004 22:58:51 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B70Hq-000JOr-NZ for multi6@ops.ietf.org; Fri, 26 Mar 2004 22:58:50 +0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 26 Mar 2004 15:05:31 +0000 Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2QMwkUe009855; Fri, 26 Mar 2004 14:58:47 -0800 (PST) Received: from cisco.com (sjc-vpn1-436.cisco.com [10.21.97.180]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id OAA25201; Fri, 26 Mar 2004 14:58:42 -0800 (PST) Message-ID: <4064A90D.90708@cisco.com> Date: Fri, 26 Mar 2004 14:05:01 -0800 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mbagnulo@ing.uc3m.es CC: Brian E Carpenter , Francis Dupont , Iljitsch van Beijnum , Multi6 List Subject: Re: Identifiers References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Marcelo & all, It sounds like Brian started pretty darn close to where I would be: > My assumption is certainly that we can trust the first address pair, > to exactly the extent that we can trust it in a non-multihomed case. > Is that a wrong assumption? I think a good solution in this space would not weaken the authenticity of any existing identifiers. And this is why I liked NOID. You want strong security? The claim is that it will work with DNSSEC for verification. Beyond that, if you have an existing line of communication between you and a host, wouldn't PBKs provide a secure means by which one could privately pass additional information? If it does, it provides some really nice generality for the above. For instance, if you use some very secure mechanism to establish connectivity then PBKs could provide continued assurance. And if you were out in the open, PBKs provide less assurance (e.g., you still end up with potential MITM attacks). Regards, Eliot From owner-multi6@ops.ietf.org Sun Mar 28 00:03:08 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16094 for ; Sun, 28 Mar 2004 00:03:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B7SP6-000Ixn-Ep for multi6-data@psg.com; Sun, 28 Mar 2004 06:00:12 +0100 Received: from [66.92.66.68] (helo=cyteen.hactrn.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B7SP5-000IxR-4n for multi6@ops.ietf.org; Sun, 28 Mar 2004 06:00:11 +0100 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id D9DD21A3 for ; Sun, 28 Mar 2004 00:00:02 -0500 (EST) To: multi6@ops.ietf.org Subject: Weekly posting summary for multi6@ops.ietf.org From: Rob Austein Date: Sun, 28 Mar 2004 00:00:02 -0500 Message-Id: <20040328050002.D9DD21A3@cyteen.hactrn.net> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Messages | Bytes | Who --------+------+--------+----------+------------------------ 26.47% | 9 | 28.39% | 39470 | mbagnulo@ing.uc3m.es 23.53% | 8 | 23.54% | 32717 | brc@zurich.ibm.com 20.59% | 7 | 20.70% | 28777 | iljitsch@muada.com 11.76% | 4 | 13.17% | 18307 | francis.dupont@enst-bretagne.fr 2.94% | 1 | 2.99% | 4150 | eric.fleischman@boeing.com 2.94% | 1 | 2.92% | 4060 | loa@ieee.org 2.94% | 1 | 2.86% | 3979 | jari.arkko@piuha.net 2.94% | 1 | 2.24% | 3119 | lear@cisco.com 2.94% | 1 | 1.69% | 2355 | sra@hactrn.net 2.94% | 1 | 1.49% | 2072 | dhc@dcrocker.net --------+------+--------+----------+------------------------ 100.00% | 34 |100.00% | 139006 | Total Grunchweather Associates provides this automatic summary on an at-whim basis at the request of the MULTI6 WG chairs. Your mileage may vary. We decline responsibilities, all shapes, all sizes, all colors. If this script produces broken output, you get to keep both pieces. From owner-multi6@ops.ietf.org Sun Mar 28 07:08:19 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13464 for ; Sun, 28 Mar 2004 07:08:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B7Z3N-000ACQ-8M for multi6-data@psg.com; Sun, 28 Mar 2004 12:06:13 +0000 Received: from [163.117.136.122] (helo=smtp02.uc3m.es) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B7Z3L-000ACA-GV for multi6@ops.ietf.org; Sun, 28 Mar 2004 13:06:11 +0100 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 74EC11774E; Sun, 28 Mar 2004 14:06:10 +0200 (CEST) Received: from lolo (vpn-252-234.uc3m.es [163.117.252.234]) by smtp02.uc3m.es (Postfix) with SMTP id 3EB7C1774A; Sun, 28 Mar 2004 14:06:07 +0200 (CEST) Reply-To: From: "marcelo bagnulo" To: "Eliot Lear" Cc: "Brian E Carpenter" , "Francis Dupont" , "Iljitsch van Beijnum" , "Multi6 List" Subject: RE: Identifiers Date: Sun, 28 Mar 2004 14:03:25 +0200 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: <4064A90D.90708@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Elliot, > It sounds like Brian started pretty darn close to where I would be: > > > My assumption is certainly that we can trust the first address pair, > > to exactly the extent that we can trust it in a non-multihomed case. > > Is that a wrong assumption? > > I think a good solution in this space would not weaken the authenticity > of any existing identifiers. I guess that i don't understand Brian statement, then. I mean, suppose that you have host A that uses IPA to initiate a communication with host B sending packets to IPB. So, Host B receives packets coming from IPA and it sends replies to IPA. So far so good, Host B doesn't have a strong confirmation that IPA is really the genuine identifier of HostA, but Host B knows that Host A can receive packets addressed to IPA. That is they way it works for fixed hosts and that is the level of security we should preserve i guess. Now the problem how do we translate this requirement to a multihomed environment. Suppose the same scenario where HostA initiates a communication with HostB using IPA and IPB respectively. They exchange some packets, so Host B knows that Host A is reachable at IPA. Moreover, HostB is using as a ULP identifier IPA. Now, using some kind of multihoming mechanism, Host A tells HostB that he is also reachable at IPC. Moreover, Host A can strongly prove that he is the same that initiated the communication using IPA (i.e. that the same entity who was at IPA is also at IPC) Finally, HostA start using IPC as source address in its packets, so HostB starts preferring IPC over IPA to use as destination address to reach HostA (instead of changing the IP address an alternative signaling mechanisms can be used to switch addresses) So my question now is: do you think that HostB, once that is sending packets only to IPC and knowing that it is same entity that initiated the communication using IPA, should still believe that he is communicating with IPA? Regards, marcelo And this is why I liked NOID. You want > strong security? The claim is that it will work with DNSSEC for > verification. > > Beyond that, if you have an existing line of communication between you > and a host, wouldn't PBKs provide a secure means by which one could > privately pass additional information? If it does, it provides some > really nice generality for the above. For instance, if you use some > very secure mechanism to establish connectivity then PBKs could provide > continued assurance. And if you were out in the open, PBKs provide less > assurance (e.g., you still end up with potential MITM attacks). > > Regards, > > Eliot > > > From owner-multi6@ops.ietf.org Sun Mar 28 08:19:11 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16690 for ; Sun, 28 Mar 2004 08:19:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B7aAl-000M7x-Jq for multi6-data@psg.com; Sun, 28 Mar 2004 13:17:55 +0000 Received: from [195.212.14.170] (helo=mail-gw2.hursley.ibm.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B7aAk-000M7a-CW for multi6@ops.ietf.org; Sun, 28 Mar 2004 14:17:54 +0100 Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw2.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.12) id 1B7aAj-0005Yd-00; Sun, 28 Mar 2004 14:17:53 +0100 Received: from [9.20.136.27] (helo=sp15en17.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.12) id 1B7aAj-0005YY-00; Sun, 28 Mar 2004 14:17:53 +0100 Received: from zurich.ibm.com (sig-9-145-226-149.de.ibm.com [9.145.226.149]) by sp15en17.hursley.ibm.com (AIX5.1/8.11.6p2/8.11.0) with ESMTP id i2SDHpF124596; Sun, 28 Mar 2004 14:17:51 +0100 Message-ID: <4066D097.340CF82D@zurich.ibm.com> Date: Sun, 28 Mar 2004 15:18:15 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: mbagnulo@ing.uc3m.es CC: Eliot Lear , Francis Dupont , Iljitsch van Beijnum , Multi6 List Subject: Re: Identifiers References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit marcelo bagnulo wrote: > > Hi Elliot, > > > It sounds like Brian started pretty darn close to where I would be: > > > > > My assumption is certainly that we can trust the first address pair, > > > to exactly the extent that we can trust it in a non-multihomed case. > > > Is that a wrong assumption? > > > > I think a good solution in this space would not weaken the authenticity > > of any existing identifiers. > > I guess that i don't understand Brian statement, then. > > I mean, suppose that you have host A that uses IPA to initiate a > communication with host B sending packets to IPB. > So, Host B receives packets coming from IPA and it sends replies to IPA. > So far so good, Host B doesn't have a strong confirmation that IPA is really > the genuine identifier of HostA, Correct. That is how the Internet works. Multi6 doesn't have to fix that. We have to make sure that *if* the host we contact using IPA subsequently asserts that it can also be contacted using IPZ, that assertion is true. The analogy with TLS is very strong - whoever we started talking to, we continue to talk to. If we start talking to a bogus host, we continue talking to the same bogus host when multihoming occurs. Brian > but Host B knows that Host A can receive > packets addressed to IPA. That is they way it works for fixed hosts and that > is the level of security we should preserve i guess. > > Now the problem how do we translate this requirement to a multihomed > environment. > > Suppose the same scenario where HostA initiates a communication with HostB > using IPA and IPB respectively. They exchange some packets, so Host B knows > that Host A is reachable at IPA. > > Moreover, HostB is using as a ULP identifier IPA. > > Now, using some kind of multihoming mechanism, Host A tells HostB that he is > also reachable at IPC. Moreover, Host A can strongly prove that he is the > same that initiated the communication using IPA (i.e. that the same entity > who was at IPA is also at IPC) > > Finally, HostA start using IPC as source address in its packets, so HostB > starts preferring IPC over IPA to use as destination address to reach HostA > (instead of changing the IP address an alternative signaling mechanisms can > be used to switch addresses) > > So my question now is: do you think that HostB, once that is sending packets > only to IPC and knowing that it is same entity that initiated the > communication using IPA, should still believe that he is communicating with > IPA? > > Regards, marcelo > > And this is why I liked NOID. You want > > strong security? The claim is that it will work with DNSSEC for > > verification. > > > > Beyond that, if you have an existing line of communication between you > > and a host, wouldn't PBKs provide a secure means by which one could > > privately pass additional information? If it does, it provides some > > really nice generality for the above. For instance, if you use some > > very secure mechanism to establish connectivity then PBKs could provide > > continued assurance. And if you were out in the open, PBKs provide less > > assurance (e.g., you still end up with potential MITM attacks). > > > > Regards, > > > > Eliot > > > > > > -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM From owner-multi6@ops.ietf.org Sun Mar 28 12:23:47 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24877 for ; Sun, 28 Mar 2004 12:23:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B7dzO-000BeF-0H for multi6-data@psg.com; Sun, 28 Mar 2004 17:22:26 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B7dzM-000Be0-P7 for multi6@ops.ietf.org; Sun, 28 Mar 2004 18:22:24 +0100 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 28 Mar 2004 09:29:26 +0000 Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2SHMKUe029631; Sun, 28 Mar 2004 09:22:21 -0800 (PST) Received: from cisco.com (sjc-vpn1-550.cisco.com [10.21.98.38]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA16672; Sun, 28 Mar 2004 09:22:19 -0800 (PST) Message-ID: <406709CA.3000105@cisco.com> Date: Sun, 28 Mar 2004 09:22:18 -0800 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mbagnulo@ing.uc3m.es CC: Brian E Carpenter , Francis Dupont , Iljitsch van Beijnum , Multi6 List Subject: Re: Identifiers References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Marcelo, Brian responded precisely as I would have. I believe it's a substantial effort simply to maintain what level of one had in the first place. Consider the following case: -- One address (IPA) is protected with DNSSEC and the other (IPA') is not. What do you do? Regards, Eliot marcelo bagnulo wrote: > Hi Elliot, > > >>It sounds like Brian started pretty darn close to where I would be: >> >> > My assumption is certainly that we can trust the first address pair, >> > to exactly the extent that we can trust it in a non-multihomed case. >> > Is that a wrong assumption? >> >>I think a good solution in this space would not weaken the authenticity >>of any existing identifiers. > > > I guess that i don't understand Brian statement, then. > > I mean, suppose that you have host A that uses IPA to initiate a > communication with host B sending packets to IPB. > So, Host B receives packets coming from IPA and it sends replies to IPA. > So far so good, Host B doesn't have a strong confirmation that IPA is really > the genuine identifier of HostA, but Host B knows that Host A can receive > packets addressed to IPA. That is they way it works for fixed hosts and that > is the level of security we should preserve i guess. > > Now the problem how do we translate this requirement to a multihomed > environment. > > Suppose the same scenario where HostA initiates a communication with HostB > using IPA and IPB respectively. They exchange some packets, so Host B knows > that Host A is reachable at IPA. > > Moreover, HostB is using as a ULP identifier IPA. > > Now, using some kind of multihoming mechanism, Host A tells HostB that he is > also reachable at IPC. Moreover, Host A can strongly prove that he is the > same that initiated the communication using IPA (i.e. that the same entity > who was at IPA is also at IPC) > > Finally, HostA start using IPC as source address in its packets, so HostB > starts preferring IPC over IPA to use as destination address to reach HostA > (instead of changing the IP address an alternative signaling mechanisms can > be used to switch addresses) > > So my question now is: do you think that HostB, once that is sending packets > only to IPC and knowing that it is same entity that initiated the > communication using IPA, should still believe that he is communicating with > IPA? > > Regards, marcelo > > > > > And this is why I liked NOID. You want > >>strong security? The claim is that it will work with DNSSEC for >>verification. >> >>Beyond that, if you have an existing line of communication between you >>and a host, wouldn't PBKs provide a secure means by which one could >>privately pass additional information? If it does, it provides some >>really nice generality for the above. For instance, if you use some >>very secure mechanism to establish connectivity then PBKs could provide >>continued assurance. And if you were out in the open, PBKs provide less >>assurance (e.g., you still end up with potential MITM attacks). >> >>Regards, >> >>Eliot >> >> >> > > > > > From owner-multi6@ops.ietf.org Sun Mar 28 19:25:38 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13603 for ; Sun, 28 Mar 2004 19:25:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B7kZJ-00073Z-UY for multi6-data@psg.com; Mon, 29 Mar 2004 00:23:57 +0000 Received: from [163.117.136.122] (helo=smtp02.uc3m.es) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B7kZI-00073J-M6 for multi6@ops.ietf.org; Mon, 29 Mar 2004 01:23:56 +0100 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 9E0E517B15; Mon, 29 Mar 2004 02:23:55 +0200 (CEST) Received: from lolo (vpn-252-208.uc3m.es [163.117.252.208]) by smtp02.uc3m.es (Postfix) with SMTP id 5276217B13; Mon, 29 Mar 2004 02:23:52 +0200 (CEST) Reply-To: From: "marcelo bagnulo" To: "Brian E Carpenter" Cc: "Eliot Lear" , "Francis Dupont" , "Iljitsch van Beijnum" , "Multi6 List" Subject: Time shifitng/future redirection attacks (was RE: Identifiers Date: Mon, 29 Mar 2004 02:21:09 +0200 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: <4066D097.340CF82D@zurich.ibm.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Correct. That is how the Internet works. Multi6 doesn't have to fix that. > We have to make sure that *if* the host we contact using IPA subsequently > asserts that it can also be contacted using IPZ, that assertion is true. If i understand what you are saying correctly, this approach wouldn't really prevent the attacks presented in section 4.1.2 Premiditated redirection of draft-nordmark-multi6-threats-00.txt, right? Or in more general terms, this would allow time shifting attacks as presented in section 2.2. Timing in draft-nikander-mobileip-v6-ro-sec-02. Note that MIP design especially limited BCE entries lifetime to a few minutes to deal with this type of attacks. > > The analogy with TLS is very strong - whoever we started talking to, > we continue to talk to. If we start talking to a bogus host, we continue > talking to the same bogus host when multihoming occurs. Yes, but now, the attacker must be on the path to achieve the attack while multihoming may allow the attacker to move from the path and continue to perform the attack So, allowing this type of attack adds vulnerabilities to the current internet, AFAICS Clearly, if the addition of these vulnerabilities is acceptable, the solutions would be much simpler, indeed. I just want to make sure that we agree that we are adding vulnerabilities here, so we can make a choice then. But i am not a security expert and i may be missing something, it would be nice to have an experts opinion to clarify Regards, marcelo > > Brian > > but Host B knows that Host A can receive > > packets addressed to IPA. That is they way it works for fixed > hosts and that > > is the level of security we should preserve i guess. > > > > Now the problem how do we translate this requirement to a multihomed > > environment. > > > > Suppose the same scenario where HostA initiates a communication > with HostB > > using IPA and IPB respectively. They exchange some packets, so > Host B knows > > that Host A is reachable at IPA. > > > > Moreover, HostB is using as a ULP identifier IPA. > > > > Now, using some kind of multihoming mechanism, Host A tells > HostB that he is > > also reachable at IPC. Moreover, Host A can strongly prove that > he is the > > same that initiated the communication using IPA (i.e. that the > same entity > > who was at IPA is also at IPC) > > > > Finally, HostA start using IPC as source address in its > packets, so HostB > > starts preferring IPC over IPA to use as destination address to > reach HostA > > (instead of changing the IP address an alternative signaling > mechanisms can > > be used to switch addresses) > > > > So my question now is: do you think that HostB, once that is > sending packets > > only to IPC and knowing that it is same entity that initiated the > > communication using IPA, should still believe that he is > communicating with > > IPA? > > > > Regards, marcelo > > > > And this is why I liked NOID. You want > > > strong security? The claim is that it will work with DNSSEC for > > > verification. > > > > > > Beyond that, if you have an existing line of communication between you > > > and a host, wouldn't PBKs provide a secure means by which one could > > > privately pass additional information? If it does, it provides some > > > really nice generality for the above. For instance, if you use some > > > very secure mechanism to establish connectivity then PBKs > could provide > > > continued assurance. And if you were out in the open, PBKs > provide less > > > assurance (e.g., you still end up with potential MITM attacks). > > > > > > Regards, > > > > > > Eliot > > > > > > > > > > > -- > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > Brian E Carpenter > Distinguished Engineer, Internet Standards & Technology, IBM > From owner-multi6@ops.ietf.org Mon Mar 29 03:41:40 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18679 for ; Mon, 29 Mar 2004 03:41:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B7sIO-000ECi-Cx for multi6-data@psg.com; Mon, 29 Mar 2004 08:39:00 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B7sII-000E7y-DQ for multi6@ops.ietf.org; Mon, 29 Mar 2004 09:38:54 +0100 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i2T8cxI0039876 for ; Mon, 29 Mar 2004 10:39:00 +0200 (CEST) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v613) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <81EEA39C-815C-11D8-8C85-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: Time shifitng/future redirection attacks (was RE: Identifiers Date: Mon, 29 Mar 2004 10:38:52 +0200 To: Multi6 List X-Mailer: Apple Mail (2.613) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [People, why are we CC'ing everyone and their little sister?] On 29-mrt-04, at 2:21, marcelo bagnulo wrote: >> Correct. That is how the Internet works. Multi6 doesn't have to fix >> that. >> We have to make sure that *if* the host we contact using IPA >> subsequently >> asserts that it can also be contacted using IPZ, that assertion is >> true. > If i understand what you are saying correctly, this approach wouldn't > really > prevent the attacks presented in section 4.1.2 Premiditated > redirection of > draft-nordmark-multi6-threats-00.txt, right? > Or in more general terms, this would allow time shifting attacks as > presented in section 2.2. Timing in > draft-nikander-mobileip-v6-ro-sec-02. > Note that MIP design especially limited BCE entries lifetime to a few > minutes to deal with this type of attacks. Which is of course something we can't do. As I said before, if someone in the middle can redirect an ongoing session, I don't consider this materially worse than what can happen today (disrupt the session). However, redirecting not only the current session but also future ones would be unacceptable. It doesn't seem too hard to avoid this, though: new sessions can be forced through a "real" address rather than a negotiated backup address. Unfortunately, in a NOID/DHT-like scheme this probably means the application needs to be involved with this. Example: X publishes addresses A and B in the DNS. Y contacts X on A X negotiates C as an additional address A dies the session from Y to X starts flowing over C Y wants to set up a new session to X Y tries address A address A times out Y tries address B And this is without adding crypto-based identifiers to the mix. Making all of this more flexible and more secure can be done using crypto-based 64 bit identifiers. I think those are a great idea, but so far there has been very little discussion on this topic. From owner-multi6@ops.ietf.org Mon Mar 29 04:30:59 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21389 for ; Mon, 29 Mar 2004 04:30:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B7t6A-000MdS-7q for multi6-data@psg.com; Mon, 29 Mar 2004 09:30:26 +0000 Received: from [131.160.192.2] (helo=p2.piuha.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B7t66-000McK-RG for multi6@ops.ietf.org; Mon, 29 Mar 2004 10:30:23 +0100 Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 23EBB898BC; Mon, 29 Mar 2004 12:30:21 +0300 (EEST) Message-ID: <4067EC10.5080206@piuha.net> Date: Mon, 29 Mar 2004 12:27:44 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mbagnulo@ing.uc3m.es Cc: Multi6 List Subject: Re: Time shifitng/future redirection attacks (was RE: Identifiers References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit In my opinion, we need to worry about the time shifting and future redirection attacks. We also need to worry about denial-of-service through "hijacking" some of the used identifiers in some permanent fashion (e.g. leap of faith after just one return routability test at the beginning of time) and preventing the legitimate nodes from establishing their sessions using their identifiers after the hijack has occurred. --Jari From owner-multi6@ops.ietf.org Mon Mar 29 04:54:35 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22519 for ; Mon, 29 Mar 2004 04:54:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B7tSb-0000Ka-1A for multi6-data@psg.com; Mon, 29 Mar 2004 09:53:37 +0000 Received: from [63.103.94.23] (helo=ftmailgfi.HQ.Flarion.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B7tSW-0000Iv-0C for multi6@ops.ietf.org; Mon, 29 Mar 2004 10:53:32 +0100 Received: from ftmail2000.HQ.Flarion.com ([10.10.1.120]) by ftmailgfi.HQ.Flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 29 Mar 2004 04:53:30 -0500 Subject: RE: Time shifitng/future redirection attacks (was RE: Identifiers Date: Mon, 29 Mar 2004 04:53:30 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Thread-Topic: Time shifitng/future redirection attacks (was RE: Identifiers Thread-Index: AcQVcf1/YW9+UqGlQS24UgHHNFEbUQAAHuYg Content-Class: urn:content-classes:message X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 From: "Soliman Hesham" To: CC: "Multi6 List" X-OriginalArrivalTime: 29 Mar 2004 09:53:30.0788 (UTC) FILETIME=[B0FB0640:01C41573] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Agreed. Hesham > -----Original Message----- > From: owner-multi6@ops.ietf.org [mailto:owner-multi6@ops.ietf.org]On > Behalf Of Jari Arkko > Sent: Monday, March 29, 2004 4:28 AM > To: mbagnulo@ing.uc3m.es > Cc: Multi6 List > Subject: Re: Time shifitng/future redirection attacks (was RE: > Identifiers > > > > In my opinion, we need to worry about the time shifting > and future redirection attacks. We also need to worry > about denial-of-service through "hijacking" some of the > used identifiers in some permanent fashion (e.g. leap of > faith after just one return routability test at the beginning > of time) and preventing the legitimate nodes from establishing > their sessions using their identifiers after the hijack has > occurred. > > --Jari > > ======================================================== This email may contain confidential and privileged material for the sole use of the intended recipient. Any review or distribution by other is strictly prohibited. If you are not the inteded recipient please contact the sender and delete all copies. ======================================================== From owner-multi6@ops.ietf.org Mon Mar 29 08:37:44 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01708 for ; Mon, 29 Mar 2004 08:37:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B7wvD-00085f-OU for multi6-data@psg.com; Mon, 29 Mar 2004 13:35:23 +0000 Received: from [163.117.136.122] (helo=smtp02.uc3m.es) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B7wv4-000841-GM for multi6@ops.ietf.org; Mon, 29 Mar 2004 14:35:14 +0100 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 16F7E1741B; Mon, 29 Mar 2004 15:35:13 +0200 (CEST) Received: from lolo (vpn-252-208.uc3m.es [163.117.252.208]) by smtp02.uc3m.es (Postfix) with SMTP id 6BDD317405; Mon, 29 Mar 2004 15:35:11 +0200 (CEST) Reply-To: From: "marcelo bagnulo" To: "Iljitsch van Beijnum" , "Multi6 List" Subject: RE: Time shifitng/future redirection attacks (was RE: Identifiers Date: Mon, 29 Mar 2004 15:32:28 +0200 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: <81EEA39C-815C-11D8-8C85-000A95CD987A@muada.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > Or in more general terms, this would allow time shifting attacks as > > presented in section 2.2. Timing in > > draft-nikander-mobileip-v6-ro-sec-02. > > Note that MIP design especially limited BCE entries lifetime to a few > > minutes to deal with this type of attacks. > > Which is of course something we can't do. As I said before, if someone > in the middle can redirect an ongoing session, I don't consider this > materially worse than what can happen today (disrupt the session). > However, redirecting not only the current session but also future ones > would be unacceptable. I agree with this criteria. The protection for a connection can be done once in the connection lifetime. The problem here, then is at which layer your solution is working. If you adopt a transport layer solution which the locator set exchanged only applies to that particular connection, the security checks can be simplified, IMHO like one RR check. However, if you adopt a shim layer or IP layer solution, the solution has no knowledge about connections, so the exchanged locator set will apply to all connections, present and future, incoming and outgoing. That is why IMHO we have to take care of time shifting attacks when considering shim/IP layer solutions which may require additional mechanisms > It doesn't seem too hard to avoid this, though: > new sessions can be forced through a "real" address rather than a > negotiated backup address. Unfortunately, in a NOID/DHT-like scheme > this probably means the application needs to be involved with this. > Example: > > X publishes addresses A and B in the DNS. > Y contacts X on A > X negotiates C as an additional address > A dies > the session from Y to X starts flowing over C > Y wants to set up a new session to X > Y tries address A > address A times out > Y tries address B Yes, this kind of approach can deal with these attacks. There are other options, also. But i guess we agree that we have to provide protection against this type of attacks (which is good :-) > > And this is without adding crypto-based identifiers to the mix. Making > all of this more flexible and more secure can be done using > crypto-based 64 bit identifiers. I think those are a great idea, but so > far there has been very little discussion on this topic. as i said in previous mails, i think CBID add value and are a good option and of course the provide protection from this attacks. Regards, marcelo > > From owner-multi6@ops.ietf.org Mon Mar 29 10:34:23 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08363 for ; Mon, 29 Mar 2004 10:34:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B7ykB-0000RW-U4 for multi6-data@psg.com; Mon, 29 Mar 2004 15:32:07 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B7yk7-0000R4-7Q for multi6@ops.ietf.org; Mon, 29 Mar 2004 16:32:03 +0100 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i2TFW6Qs002125; Mon, 29 Mar 2004 17:32:07 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <37E1EABE-8196-11D8-8C85-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: "Multi6 List" From: Iljitsch van Beijnum Subject: Re: Time shifitng/future redirection attacks (was RE: Identifiers Date: Mon, 29 Mar 2004 17:31:59 +0200 To: X-Mailer: Apple Mail (2.613) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 29-mrt-04, at 15:32, marcelo bagnulo wrote: > The protection for a connection can be done once in the connection > lifetime. > The problem here, then is at which layer your solution is working. > If you adopt a transport layer solution which the locator set > exchanged only > applies to that particular connection, the security checks can be > simplified, IMHO like one RR check. > However, if you adopt a shim layer or IP layer solution, the solution > has no > knowledge about > connections, so the exchanged locator set will apply to all > connections, > present and future, incoming and outgoing. That is why IMHO we have to > take > care of time shifting attacks when considering shim/IP layer solutions > which > may require additional mechanisms Ok, this is a useful constraint: either our mechanisms must work per-session (or group of sessions created within a short timeframe) or we need strong(er) authentication than just return routability. > as i said in previous mails, i think CBID add value and are a good > option > and of course the provide protection from this attacks. Yes. The nice thing about 64 bit CBIDs is that you can just put them in the bottom 64 bits and they're not in the way. This allows being backward compatible as long as there are no outages. It's not even necessary to negotiate additional addresses at this point if good hints towards available addresses for the correspondent are available at at least one end. However, in this case the upper layers must still be aware of the locator bits. Having ULPs work with identifiers exclusively would be cooler but more complex. From owner-multi6@ops.ietf.org Mon Mar 29 14:03:57 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17932 for ; Mon, 29 Mar 2004 14:03:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B821e-000COg-2C for multi6-data@psg.com; Mon, 29 Mar 2004 19:02:22 +0000 Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B821b-000COS-Ho for multi6@ops.ietf.org; Mon, 29 Mar 2004 20:02:19 +0100 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i2TJ2Cp9024526; Mon, 29 Mar 2004 12:02:13 -0700 (MST) Received: from bobo (bobo.SFBay.Sun.COM [129.146.89.81]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i2TJ2AQ04223; Mon, 29 Mar 2004 21:02:10 +0200 (MEST) Date: Mon, 29 Mar 2004 11:02:11 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Time shifitng/future redirection attacks To: Brian E Carpenter Cc: Multi6 List , erik.nordmark@sun.com In-Reply-To: "Your message with ID" <4066D097.340CF82D@zurich.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk > Correct. That is how the Internet works. Multi6 doesn't have to fix that. > We have to make sure that *if* the host we contact using IPA subsequently > asserts that it can also be contacted using IPZ, that assertion is true. I sense folks talking a bit past eachother on the mailing list so let me try to help. In the case when nothing moves around I think we understand the requirements quite well. Something that is on the path can be a MiTM today and multi6 doesn't need to make that aspect any more secure. But it is more difficult to undersyand the requirements when nodes are moving around; a node might be on the path for a short instance (driving by the 802.11 coffeeshop). Would we or would we not be concerned if such a drive-by (which many call a "time-shifting" attack) would result in the temporarily on-path node can be a MiTM for future communication? (e.g. by creating/installing multi6 related state in various peer nodes while it was on the path) I actually don't think the answer is obvious; we don't have much experience with nodes moving around being able to attack things as they move. In Mobile IPv6 a conservative approach was taken which limits such drive-by attacks to the maximum lifetime of the binding, which is set to a few minutes. Note that the range of solutions that has been discussed in multi6 go from such drive-bys being impossible (because of a strong binding to a separate identifier in HIP, or because of relying on the relative security of the DNS for forward+reverse lookups in NOID), to systems that are first-come/first-serve (WIMP being an example with a separate ID space, a MAST approach with a PBK being an example without a separate ID space) that allow the first host which is using an ID/address to claim that without any time limit. The threats draft talks about pre-mediated attacks which is a particular aspect of "drive-bys"; things that are different because nodes move around. Based on the mailing list discussion I suspect we need to flush out the this whole area of nodes moving around a bit more in the draft. Erik From owner-multi6@ops.ietf.org Mon Mar 29 14:14:35 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18570 for ; Mon, 29 Mar 2004 14:14:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B82DI-000EHD-0a for multi6-data@psg.com; Mon, 29 Mar 2004 19:14:24 +0000 Received: from [192.18.42.13] (helo=nwkea-mail-1.sun.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B82DH-000EH0-0k for multi6@ops.ietf.org; Mon, 29 Mar 2004 20:14:23 +0100 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i2TJEBWA017081; Mon, 29 Mar 2004 11:14:12 -0800 (PST) Received: from bobo (bobo.SFBay.Sun.COM [129.146.89.81]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i2TJEAQ04417; Mon, 29 Mar 2004 21:14:10 +0200 (MEST) Date: Mon, 29 Mar 2004 11:14:11 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Identifiers To: Iljitsch van Beijnum Cc: Multi6 List In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk [Catching up] > Personally, I think the best choice would be to remain agnostic about > the identifier issue for now, but build our negotiation protocol such > that they can be added easily later. For now, we build a "no > identifier" type solution. Solving the problem of how a correspondent > proves ownership of an identifier can then be deferred until such time > that someone actually wants to extend the multi6 solution to support > identifiers. So the only thing we have to do now is make sure the > protocols are flexible enough to allow such extensions. Thanks for bringing up this topic. It definitely makes sense to think about it a bit. I can see the feasibility of constructing a protocol which can carry sets of locators and an identifier (which might be just the designated locator the ULP is viewing as an identifier - what I called AID in some drafts), with messages to change the set of locators over time. What concerns me so far are two things: implications on the initial setup and implications of different security mechanisms. If a separate identifier is used this means that the initial setup must appear before (or at the same time) as the first ULP packets are exchanged. But if we just have a locator-agile mechanism without a new identifier space it makes sense to allow a deferred exchange (and verification) of the locator sets e.g. to avoid this cost when the connections are very short. I don't have a good feeling for how complex it would be to design a protocol which can do both immediate and deferred setup. We've seen quite a range of security approaches proposed so far, and with different approaches to prevent using the verification of the locators as a new avenue for DoS attacks. Will a scheme which introduces a new ID name space by necessity need different security mechanisms? Will be immediate vs. deferred state setup have implications on this? Is there a common "message sequence" which can apply independently of the actual security mechanism being used? (The good news is that the notion of a lazy-evaluation of the locators and ID->loc bindings seems to become common across the proposals. So perhaps there is a common theme to be able to verify a peer locator before it is used which might mean a more common "message sequence"?) Erik From owner-multi6@ops.ietf.org Mon Mar 29 16:44:30 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28452 for ; Mon, 29 Mar 2004 16:44:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B84Xg-000Clv-Ej for multi6-data@psg.com; Mon, 29 Mar 2004 21:43:36 +0000 Received: from [163.117.136.122] (helo=smtp02.uc3m.es) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B84Xe-000ClZ-Kf for multi6@ops.ietf.org; Mon, 29 Mar 2004 22:43:34 +0100 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 8CDEE1791D; Mon, 29 Mar 2004 23:43:33 +0200 (CEST) Received: from lolo (vpn-252-208.uc3m.es [163.117.252.208]) by smtp02.uc3m.es (Postfix) with SMTP id 1E143178FA; Mon, 29 Mar 2004 23:43:31 +0200 (CEST) Reply-To: From: "marcelo bagnulo" To: "Erik Nordmark" , "Brian E Carpenter" Cc: "Multi6 List" Subject: RE: Time shifitng/future redirection attacks Date: Mon, 29 Mar 2004 23:40:47 +0200 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: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Erik, > > Correct. That is how the Internet works. Multi6 doesn't have to > fix that. > > We have to make sure that *if* the host we contact using IPA > subsequently > > asserts that it can also be contacted using IPZ, that assertion is true. > > I sense folks talking a bit past eachother on the mailing list so let > me try to help. Thanks > > In the case when nothing moves around I think we understand the > requirements > quite well. Something that is on the path can be a MiTM today and > multi6 doesn't need to make that aspect any more secure. > > But it is more difficult to undersyand the requirements when > nodes are moving > around; a node might be on the path for a short instance (driving by > the 802.11 coffeeshop). > Would we or would we not be concerned if such a drive-by (which many call > a "time-shifting" attack) would result in the temporarily on-path > node can > be a MiTM for future communication? (e.g. by creating/installing > multi6 related state in various peer nodes while it was on the path) > > I actually don't think the answer is obvious; we don't have much > experience > with nodes moving around being able to attack things as they move. I don't think that the decision is obvious but I think it is very importatn ti understand the additional vulnerabilities that we are introducing. It may be acceptable to introduce them, though. > > In Mobile IPv6 a conservative approach was taken which limits such > drive-by attacks to the maximum lifetime of the binding, which is set to > a few minutes. > > Note that the range of solutions that has been discussed in multi6 > go from such drive-bys being impossible (because of a strong binding to > a separate identifier in HIP, or because of relying on the > relative security > of the DNS for forward+reverse lookups in NOID), to > systems that are first-come/first-serve (WIMP being an example with > a separate ID space, a MAST approach with a PBK being an example without > a separate ID space) that allow the first host which is using an > ID/address > to claim that without any time limit. > > The threats draft talks about pre-mediated attacks which is a particular > aspect of "drive-bys"; things that are different because nodes > move around. > Based on the mailing list discussion I suspect we need to flush out the > this whole area of nodes moving around a bit more in the draft. Agree. I think that the section of future attacks considers this issue but perhaps adding some more examples to understand the full range of time shifting attacks would be fine. Additionally, perhaps it makes sense to explicitly note that the direction of communications. I mean, the threats when you allow that the state created by an incoming connection is shared with future outgoing communications. So, there is state created at a moment in time, a time shifted attack is about using this (false) state in future communications, but additionally, IMHO it is also important to note whether this communication are in the same direction of the communication that created the state. finally, i think that explicitly noting that there is a difference level of threat when the state affects only a connection or it refers to the complete identity of the host. Regards, marcelo > > Erik > > From owner-multi6@ops.ietf.org Mon Mar 29 18:15:27 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03010 for ; Mon, 29 Mar 2004 18:15:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B85v9-0005SJ-RE for multi6-data@psg.com; Mon, 29 Mar 2004 23:11:55 +0000 Received: from [192.18.42.14] (helo=nwkea-mail-2.sun.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B85v9-0005S5-1T for multi6@ops.ietf.org; Tue, 30 Mar 2004 00:11:55 +0100 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i2TNBong017215; Mon, 29 Mar 2004 15:11:51 -0800 (PST) Received: from bobo (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i2TNBlQ27564; Tue, 30 Mar 2004 01:11:48 +0200 (MEST) Date: Mon, 29 Mar 2004 15:11:48 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: Time shifitng/future redirection attacks To: mbagnulo@ing.uc3m.es Cc: Erik Nordmark , Brian E Carpenter , Multi6 List In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk > I think that the section of future attacks considers this issue but perhaps > adding some more examples to understand the full range of time shifting > attacks would be fine. > Additionally, perhaps it makes sense to explicitly note that the direction > of communications. I mean, the threats when you allow that the state created > by an incoming connection is shared with future outgoing communications. Yes, it is already on my todo list to add text about this to the threats draft. > So, there is state created at a moment in time, a time shifted attack is > about using this (false) state in future communications, but additionally, > IMHO it is also important to note whether this communication are in the same > direction of the communication that created the state. > > finally, i think that explicitly noting that there is a difference level of > threat when the state affects only a connection or it refers to the complete > identity of the host. Having text in the threats draft that points out this concern makes sense. I don't feel we can say much more about the "granularity" of the redirection attacks - because I don't think we understand the tradeoffs in terms of granularity yet. Erik From owner-multi6@ops.ietf.org Wed Mar 31 03:44:33 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06323 for ; Wed, 31 Mar 2004 03:44:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B8bIw-000HfE-9E for multi6-data@psg.com; Wed, 31 Mar 2004 08:42:34 +0000 Received: from [192.71.13.243] (helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B8bIn-000HcM-1A for multi6@ops.ietf.org; Wed, 31 Mar 2004 09:42:25 +0100 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id 4C89F35842D for ; Wed, 31 Mar 2004 10:43:14 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v613) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=fixed To: Multi6 List From: Kurt Erik Lindqvist Subject: Bouncing users Date: Wed, 31 Mar 2004 10:03:36 +0200 X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.613) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00,UPPERCASE_25_50 autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The following subscribers have been bouncing enough and will be de-subscribed later this week : Tony.Li@procket.com gblock@telnic.org sola@jet.es - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQGp7X6arNKXTPFCVEQIJLACg/Lj75OTi3PAvSdaGjxgijqwOSBIAnR6Y b6B/fQ2j280RJ90DdTBryPuz =dFkS -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Wed Mar 31 12:09:12 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02057 for ; Wed, 31 Mar 2004 12:09:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B8jBc-0007vD-8f for multi6-data@psg.com; Wed, 31 Mar 2004 17:07:32 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B8jAr-0007oo-Os for multi6@ops.ietf.org; Wed, 31 Mar 2004 18:06:45 +0100 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i2VH6mQs041436; Wed, 31 Mar 2004 19:06:49 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Multi6 List From: Iljitsch van Beijnum Subject: Re: Identifiers Date: Wed, 31 Mar 2004 19:06:41 +0200 To: Erik Nordmark X-Mailer: Apple Mail (2.613) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 29-mrt-04, at 21:14, Erik Nordmark wrote: > If a separate identifier is used this means that the initial setup must > appear before (or at the same time) as the first ULP packets are > exchanged. Yes. This also means the negotiation protocol must be able to get through in order for anything to work, piggybacking will be very hard here. (Aside: I always thought it was a big flaw in the IKE design that the negotiation is done with the target host. Maybe it's too hard to make this work safely with a third party host, but it would have some nice security benefits and solve rendezvous for mobility.) > But if we just have a locator-agile mechanism without a new identifier > space > it makes sense to allow a deferred exchange (and verification) of the > locator > sets e.g. to avoid this cost when the connections are very short. Right. > I don't have a good feeling for how complex it would be to design > a protocol which can do both immediate and deferred setup. I'd think it wouldn't really matter. Immediate setup can be viewed as deferred after 0 bytes of data have crossed the line. The only difference is that with deferred negotiation some information we need (locators) is by definition available, while with immediate negotiation we may need to go look for it ourselves. Or am I missing something? > Will a scheme which introduces a new ID name space by necessity need > different security mechanisms? Not by definition. But some types of identifiers could support security mechanisms that others can't. For instance, with crypto based identifiers it is possible to find out whether the other side is the real holder of the identifier with nothing more than information received from the correspondent. With non-crypto IDs you need some chain or web of trust if the identifier is cryptographically protected. Alternatively, the information may not be learned from the correspondent but rather from a mapping service. The way such a mapping service works depends on the nature of the identifiers (hierarchical or otherwise). So basically we have four permutations of identifiers: - non-crypto, non-hierarchical - crypto, non-hierarchical - non-crypto, hierarchical - crypto, hierarchical We probably don't need four different security mechanisms, but more than one is likely if we're going to use identifiers from more than one category. > Will be immediate vs. deferred state setup have implications on this? I don't see how we can defer state setup for identifiers that aren't reachable locators. And identifiers that ARE locators aren't always reachable, placing part of the multihoming burden on applications. > Is there a common "message sequence" which can apply independently of > the actual security mechanism being used? Does it matter? The messages are presumably passed back and forth transparently. The only important part is that we have some well-defined state transitions, and the security mechanism triggers the right one at the right time. BTW, without knowing the details, I think 802.1x, PPP and EAP solve a fairly similar problem. Iljitsch